汽车安全之声 | 专职功能安全人员的职业瓶颈

01 和各位小伙伴 Say Hi

大家好，我叫Kevin，是SASETECH的会员。

我于2016年接触功能安全，开始时主要从事BMS、MCU、DCDC等新能源产品的系统及软件层面的功能安全设计，最近3年主要从事自动驾驶产品及传感器的功能安全开发就管理工作。

随着汽车电动化、智能化、网联化的持续推进，汽车上的电子电器设备越来越多，这为功能安全人员提供了充足的岗位需求，从近几年功能安全岗位的招聘热度就可见一斑，但同时也看到各位小伙伴普遍抱怨公司安全文化不足，项目推进困难，个人职业发展受限等各种问题，今天我们就一起来聊聊专职功能安全人员的职业瓶颈，粗浅的给出了一些原因分析，但由于个人认知的局限，对这个话题的思考有诸多不妥之处，还望轻拍。

 02 为什么说专职功能安全人员的职业瓶颈会越来越紧迫？

1.  控制器硬件趋同，标准化、模块化设计的持续推进会导致功能安全岗位需求减少

随着电子电气架构的发展，电气架构从分布式向集中式发展，中央计算单元+区域控制器的电子电气架构越来越被大家采用，这直接导致车上的参与车辆控制的ECU数量减少，控制器数量的减少最直接的体现就是Tire1数量的减少，这会导致功能安全岗位的减少；

通过OTA升级来提升用户体验被越来越多的主机厂使用，通过硬件更新创造新的用户体验的迭代周期会放缓，当体验需求的改善不通过硬件设计来提升，也就会导致硬件在项目中的话语权减弱，这又将进一步减少单位时间内新硬件控制器的数量；

软件定义汽车的持续推荐，软件和硬件的解耦会越来越彻底，当硬件贡献的差异性越来越少时，最终会变成一个标准化产品，在电脑行业和手机行业已经看到这种趋势，汽车电子是不是也会遵守电脑和手机的这种趋势了？我想这个回答时确定的，随着标准化硬件的推出，而真正有能力提供物美价廉硬件产品的供应商会被高度集中在某几家供应商手里，供应商数量的减少也将进一步降低对功能安全岗位的需求（以上硬件指代硬件PCBA和底层软件）

图1：Bosch 电子电气架构的发展趋势

2.  软件复杂性猛增，功能安全规则的可操作性差，安全人员不被信赖。

自动驾驶技术和电动化技术的发展，导致现有软件的复杂程度正在快速的增加，有数据表明高端新能源汽车已经成为最复杂的软件产品，如此复杂的软件，开发人员也很难捋清楚软件之间的相互的关系，或者说试图对复杂软件进行完整的安全分析本身就是不划算的，同时在敏捷和OTA的开发策略下，软件版本的变更已经非常快，如何在这种环境下进行功能安全的设计对安全人员有不小的挑战；

软件功能安全开发的本质就是找到Bug/防止Bug、防止失效。专职的功能安全人员如何指导或顶替研发人员找到Bug，这都需要建立在对软件足够熟悉的情况下，否则更多的只能提出一些编程规则、检查清单和安全分析的流程要求；在防止软件失效方面，我们是将软件当作黑盒或灰盒，使用一些容错、纠错机制进行故障的检测，当软件故障的情况下不让其产生失效，这也是部分安全人员的核心工作，但面对AI算法、高度复杂的软件程序时，很难找到行之有效的安全机制，这就像你让一个小学生去审核大学生的论文，当然有些时候是可以诊断到一些错误的，但更多的时候是无法诊断到错误的，所以不建议在端到端的诊断机制上花费太多时间；

图2：软件故障的演进图

既然在设计时如何杜绝安全风险不好量化和评估，那通过对测试结果来进行量化从而评估安全风险，这种方法被自动驾驶行业越来越多的使用，通过建立庞大的回归测试库，持续积累各种特殊场景数据，不断发展回归测试库，同时借助自动化的工具，加快软件自动化测试的效率，每次版本释放时先通过该回归测试库，随着闭环数据的积累，从而实现正向的安全迭代，可是专职的安全人员如何在这个过程中找准自己的定位了？这即使挑战也是机遇，为安全设计打开了另外一扇窗。

图3：Momenta的数据驱动流程

功能安全、信息安全、SOTIF和AI等失效风险确实实实在在的存在，但很难被量化，相信大家也经常被问道：按照你这套流程和需求做了是不是就安全了，不安全的风险到底还有多大，如何衡量？作为公司，我如何持续考核安全人员的工作产出？同一个产品，为啥找A公司可以拿到产品认证证书，而找B公司却不可以，认证公司的判断标准为何这么多变？特斯拉之前几年也没做功能安全，26262是不是欧洲老牌车厂有意设置的一个准入门槛而已？这些问题确实很难回答，但是不说清楚这些问题，在面对互联网背景的领导时，当资源受限时，功能安全开发总是那个被后置的选项。

3.  功能安全的入门门槛低，安全方法论易于掌握，专职功能安全岗位越来越不被认可

功能安全岗位上限高，真正做好非常不容易，对人的综合素质要求非常高，但是功能安全岗位的入门门槛确实不高，平时小伙伴们开玩笑时常说，一个软件硬件的设计人员转型功能安全，经过一定的培训与项目历练，差不多大半年就可以对功能的开发流程和方法论进行掌握；

随着功能安全知识的普及，系统、软件和硬件工程师很多也接受到良好的安全培训，对于功能安全的方法论和常用手段也非常熟悉，那是否需要一些专职的功能安全人员来主导安全事宜了，会不会遇到外行指导内行的困境了？

4.  安全收益不易见，权衡决策时多被后置

功能安全投入大，周期长，结果不易量化，现在有不少公司采用唯快不破的迭代策略，在项目按时交付的要求下，人员和时间资源总是不够的，短期结果的KPI紧紧的压在领导身上，当资源受限时，功能安全的优先级往往是被后置，这是安全岗位面对的最本质的问题，相信大家深有感受，就不再这里详细说了。

专职安全人员的职业发展遇到这样和那样的问题，但安全会被越来越重视这个趋势是明确的，将来研发人员需要将更多的时间放在安全设计上，但是我们也必须跳出现有的功能安全标准，ISO26262参考的是IEC61508，但IEC61508已经是20多年前的技术标准，当时的产品复杂度远远低于现在自动驾驶汽车的复杂程度，我们照本宣科的依照老标准来指导一个充满朝气和活力的行业必然会遇到强大阻力，应该跳出功能安全标准的限制，借鉴标准中的安全思想，成为安全问题实际的解决者，而不是安全问题的提出者。随着自动驾驶和网联技术的发展，必然会产生很多新的岗位，这些新的岗位对现有人员来说都是新的，都没有成熟的经验可以参考，只能是基于之前的认知体系，在问题中进行学习，我相信功能安全这套成体系的思维方式，必然能为大家提供助力。

03  最后有什么想对大家说的

功能安全的设计工作充满挑战，绝不能唯标准论，按图索骥的套用标准，而应该结合公司实际，从实用出来推进安全设计，同时也应该加强自身的能力建设，熟悉产品的工作原理，对产品中使用的新技术抱以宽容，拥抱变化，终身成长。