广告
做功能安全需要对ISO26262理解到什么程度？干这一行前景怎么样？
2021-12-31 07:48:47· 来源：汽车ECU开发
写在最前面：作为一名功能安全工程师，刚从事这份工作时浏览这个问题还带着很多入门前的疑惑，如今再次浏览时，自认为可以根据自己的工作经验输出一些浅见了。借
写在最前面：
作为一名功能安全工程师，刚从事这份工作时浏览这个问题还带着很多入门前的疑惑，如今再次浏览时，自认为可以根据自己的工作经验输出一些浅见了。借着回答这个问题也希望能抛砖引玉，和各位前辈们做进一步探讨。
根据我的经验，探索某一事物的过程也是否定自己认知的过程，所以只能说现在的回答代表自己当前的理解，后续如果有新理解会更新这个答案
本文试图回答以下问题：
• 什么是功能安全？
• 功能安全在企业怎么落地？
• 功能安全工程师的工作内容
• 入门时如何对待ISO 26262文档？
• 功能安全工程师的前景
01. 什么是功能安全（Functional Safety）？
在这里先引用ISO 26262和GB/T 34590中的定义，从定义展开强调几个关键词。ISO 26262：absence of unreasonable risk due to hazards caused by malfunctioningbehavior of E/E systems.
GB/T 34590：不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险。
1. “E/E system”，电子电器架构
功能安全要讨论的对象是E/E架构设计，因此机械/液压/化学等设计都不在ISO 26262的研究范围。
2. “hazard”，危害
危害有很多类型，如人身伤害或者财产损失等等。功能安全里的危害仅仅指对驾驶员或者路人或周边车辆内人员（注意：不仅仅是驾驶员）造成的健康伤害。换句话说，功能安全开发目的是避免伤人，而不是避免你的损伤你的豪车，也不是避免你的豪车被偷。
3. “unreasonable”，不合理的
即“不可被接受的”。就像世界上没有永动机一样,世界上也没有100%安全的系统,因此功能安全追求的是将危害控制在可被接受的范围。而是否可被接受,需要从两个维度去衡量:危害的严重性和危害发生的频率。举例来说,飞机失事几乎无人生还,但是正因为飞机失事的概率非常低,所以不影响它成为最重要的交通工具之一;电动车窗发生卡滞故障的频率比较高,但是故障不会让人受伤,因此很多司机甚至只有等到下个月去4S店时才想起来维修它。但是,如果你的车突然在高速上自动加速,估计你马上停在紧急带,惊魂未定便马上打电话给4S店骂娘了，因为这种原本可以通过设计规避的故障是不可接受的。这也正是功能安全开发期望避免的故障。
补充一下，这里提到两个维度，危害的严重度和危害发生的频率。对功能安全有了解的朋友可能会疑惑 ：不是有三个参数评价，S（severity 严重度），E（Exposure 曝光度 ），C（controllability 可控度）吗？
其实不冲突，第二个维度频率综合了E值和C值。怎么理解呢？“频率”指的是危害发生的频率，而“曝光度”指的是场景的曝光度。驾驶员的可控度是可以将高曝光度的场景下造成危害的频率降低的。举例来说，开高速的场景在日常生活中曝光度比较高，但是如果高速时发生意外加速，有些情况下通过驾驶员的制动干预是可以避免危害的，因此降低了危害发生的频率。
02. 功能安全怎么在企业落地？
这个问题很大，无法进行全面的回答。一个原因是各个公司间的差异性，二是ISO 26262的范围太广，对整车完整生命周期都进行了功能安全的指导，除了我们熟知的V模型开发过程外，就连生产和报废阶段都考虑在内。在这里仅仅谈几点认识。
1. 安全文化（safety culture）
这个词初一听很虚，感觉像是喊口号。实际上安全文化体现在很多看得见的方面，比如：• 成本和进度总是优先于安全和质量，还是安全是最高优先级？
• 是否确保了与功能安全相关的决策责任是可追溯的？
• 在所有层面（管理/开发/验证/审核）执行是否有明确的、可追踪的和受控的流程？
安全文化体现在公司的开发流程中。优秀的安全文化一定意味着企业有非常完善的开发流程。否则功能安全只是空中楼阁，落地无从谈起。同时，完善的流程也意味着要增加相应的岗位和工程师们的工作量，甚至是升级开发工具，开发成本也随之上升。
在这里强调一点，企业一定是将ISO 26262中对功能安全的需求融入公司已有的开发流程，而不是单独为功能安全开发制定一套开发流程。换句话说，功能安全需求是功能需求的一部分，和其他功能需求一样用同一套的开发流程来实现。
2. 人员配置
首先说明,几乎不可能是由一个功能安全开发工程师同时负责系统/软件/硬件所有的功能安全开发,就算有这种万里挑一的全才,也得考虑如此庞大的工作量会不会把人才赶跑了。
一个完善的开发团队中通常定义三个角色：• 系统功能安全工程师
• 软件功能安全工程师
• 硬件功能安全工程师
每个人负责下图中的一个V模型开发活动。
需要说明，这里的“系统”指的是某个E/E产品，比如转向控制系统EPS，稳定性控制系统ESP，电机控制系统MCU等。
功能安全工程师角色分工不管对主机厂还是供应商，在一个客户项目中，很少说要从零开始开发一个全新的产品，一般都是基于现有的产品作为base进行开发，以满足新的项目需求，功能安全也是如此。围绕项目需求与base不同的部分进行功能安全开发，识别不同点的活动称作FSIA（functional safety impactanalysis）。当功能安全是基于base来开发时，不管是对主机厂或供应商来说，这三个角色并不需要定义三个独立的工程师来做，这未免太奢侈，实际上也没必要。通常软/硬件功能安全工程师 由软/硬件工程师兼任。
对软件功能安全开发而言，在软件开发流程完善和开发工具满足要求的前提下，在软件设计和验证过程中，功能安全需求和功能需求无需过分区别对待，有很多公司的软件开发流程本身就能保证符合ISO 26262中ASIL D的要求。因此功能安全对软件工程师增加的工作量主要体现在需求分析和输出文档，包括：
1. 对系统层分配下来的安全需求进行可行性分析
2. 对输入信号提安全需求
3. 满足系统层或客户的文档需求
对硬件功能安全开发而言，通常一款硬件的设计周期很长，而且设计好后很多年不会更新，所以几乎不会在客户项目中重新开发硬件。基于此，项目中硬件功能安全开发就可以完全沿用base既有的开发，功能安全对硬件工程师增加的工作量主要是：
1. 为系统安全工程师提供FTA分析需要的硬件component失效率数据（FMEDA）
2. 满足系统层或客户的文档需求（如ECU FMEA分析报告）
只有系统功能安全开发需要定义一个专门的岗位，有些公司也称为“功能安全经理（productsafety manager, PSM）”。主机厂和供应商对功能安全经理的职责定义侧重点有一些不同，这也是主机厂和供应商之间的合作模式决定的。主机厂侧重于定义需求并分配给供应商，供应商则侧重于实现需求。
主机厂端功能安全经理的工作职责一般包括但不限于：
1.计划和协调系统安全开发活动
2.进行HARA分析,并结合HARA分析和系统架构定义功能安全概念(functional safety concept)和技术安全概念(technical safety concept)
3. 将安全需求分配给对应的子系统，或者说分配给子系统的供应商
4. 负责协调子系统相互之间的功能安全需求的传递与澄清
5. 协助功能安全验证，比如创建整车test case和测试结果评估
6. 对子系统功能安全开发进行审核
供应商端功能安全经理的工作职责一般包括但不限于：
1. 计划和协调系统安全开发活动
2. 基于HARA分析，根据安全需求和系统架构定义功能安全概念（functional safety concept）和技术安全概念（technical safety concept），对系统架构设计提出要求或建议
3. 将安全需求分配给对应的软件工程师 （和硬件工程师）
4. 完成系统功能安全设计的定量分析 和定性分析，通常分别使用FTA和FMEA
5. 协助功能安全验证，比如创建整车test case和测试结果评估
6. 作为客户功能安全团队和功能安全审核团队的接口
7. 对软/硬件工程师提供功能安全开发建议和指导
一般来说，生产和报废阶段的功能安全活动不在系统功能安全工程师的职责范围内。比如生产阶段的功能安全通常是由plant manager（工厂经理）来执行，执行的依据则是已经包含了功能安全需求的生产流程。当产品release后交到工厂，就意味着功能安全工程师的工作完成了。
相信大家可以理解，为什么系统层的功能安全开发需要专门的人负责了，因为工作量实在有点大。尤其是现阶段国内功能安全开发的理念和方法论还没有到深入人心的程度，如果遇到客户不懂，软硬件工程师也不懂，那么光是对外交流和对内沟通就需要花大量的时间。如果一个项目足够大，客户新需求足够多，可能不止一个系统功能安全工程师。
于此同时，功能安全经理这个岗位对工程师的专业素质要求也很高，原则上需要有足够的软/硬件开发经验，这样才能胜任上到客户或供应商，下到软硬件工程师的交流工作。但是目前鉴于功能安全在企业还比较新，这方面的能力要求有适当放宽。
在这里也纠正一些同行对系统功能安全工作的误解。认为既然不用写代码，也不用画板子，那功能安全经理就只剩下流程和文档工作了。这话被功能安全经理听到他会伤心的，仿佛当年不被女神认可的感觉又回来了。诚然，功能安全的落地需要流程和文档来保证，但是功能安全开发的核心却是技术层面的东西而非流程。而功能安全的技术核心，体现在概念设计/系统分析/系统验证阶段对功能安全开发方法论的运用。
03. 如何看待ISO26262
上面提到“方法论”，一说到方法论，这玩意儿一听就很抽象，这也无外乎我们初看ISO 26262的时候不知所云，昏昏欲睡，完全不像看一个软件开发手册那样即看即用。但个人认为ISO 26262的精髓恰恰是在对这个方法论的解释。
因此，个人认为，入门时可以这样对待ISO 26262文档：
1. 首先不要期待脱离实操就看懂ISO 26262。最好的方法是有项目练手，在做项目的过程中体会ISO 26262中的需求。
2. 如果你是功能安全经理，那没什么说的，除了第7部分，其他部分都需要熟悉。但还是那句话，必须结合项目开发过程和公司的开发流程来理解ISO 26262。多问自己：流程中XX为什么这样规定？对应ISO 26262哪条需求？
3. 如果你是软/硬件开发工程师兼任功能安全工作，那么重点关注第3（概念）/5（硬件）/6（软件）部分，另外还有第9部分对的ASIL等级分解的说明。
基于这些内容如果你能够回答下面的问题，那么我觉得你至少知道自己在做什么和为什么这么做了，这样一来，在和别人交流的过程会更加专业和顺畅。
• 什么是safety goal?
• 如何做Hazard analysis and risk assessment?• ASIL 等级怎么评定?
• ASIL 等级达不到要求用什么方法解决?
04. 功能安全工程师的前景
就我目前的所见所闻来看，目前随着ADAS功能的普及和自动驾驶研究的热门，功能安全越来越被重视，市场需求量很大。猎头在挖人时开出的价码往往非常诱人。与此同时，目前国内功能安全做的成熟的企业不多，尚处于边做边摸索的阶段，所以目前挖人时并不很挑剔，对系统/软/硬件开发经验的要求有放宽。
就我个人感觉而言，相对于本土OEM，外企或者合资Tier1的know-how更高，比如博世，大陆，联电等等。合资OEM中泛亚 的功能安全团队已经很成熟，因此在和这些供应商合作时很强势也有底气；而本土OEM在和这些供应商合作的同时也抱着花钱学习怎么做功能安全的目的。换句话说，OEM的态度从“你觉得怎么做？”到“我要你这么做！”还有些距离。但是，这种状况在将来一定会得到改变，因为本土主流的几家OEM的功能安全团队在以肉眼可见的速度壮大，大家越来越舍得在功能安全开发上投入成本（好多外国专家也因此体会到了社会主义高薪的诱惑力）。可以预见的是，自动驾驶的驱动会加速功能安全的落地，这会大大加速行业整体水平的提高。届时，国内市场对功能安全工程师的专业素养的要求也会越来越高；另一方面，ISO 26262在自动驾驶开发中的局限性也日益凸显，由此也催生了新的标准SOTIF的诞生，功能安全工程师需要掌握的知识越来越多。
正应了那句话：学无止境。
- 下一篇：电动汽车高压电气安全
- 上一篇：现代汽车集团E-GMP架构技术解析
广告
最新资讯
-
一氧化碳对膜电极性能的影响
2024-05-15 17:54
-
上海市智能网联汽车封闭式测试场又添新选项
2024-05-15 17:53
-
中国汽研助力某乘用车企业获得CSMS/SUMS体
2024-05-15 16:33
-
Coral-data开源计划:SimScenario-AEB 仿真
2024-05-15 16:17
-
车轮上的巨变，生成式 AI 正在重新定义自动
2024-05-15 14:54
广告
广告
