李洪超 硬件工程师_听说你想做功能安全工程师？（下篇）

上篇回顾

在《听说你想做功能安全工程师？（上篇）》（注：此处添加上篇文章链接）中解释了以下三点：

• 什么是功能安全？
• 功能安全如何在企业落地？
• 功能安全经理的工作定义

本文将继续围绕以下三点展开，对‘功能安全工程师’这一岗位进行进一步的说明。

• 主机厂和供应商功能安全合作
• 系统/软件/硬件功能安全工程师的工作日常
• 功能安全的前景及一些建议

主机厂和供应商功能安全合作

主机厂和供应商共同遵守ISO 26262中定义的要求，合作完成某个产品的开发，这一合作模式被称为“分布式开发（Distributed Development）”。而分布式开发的前提则是明确双方的责任范围和边界，这部分内容最终以双方共同商议并签署的DIA (开发接口协议，development interface agreement) 呈现，后续双方在功能安全开发过程中的协作将完全依照DIA为指南进行。

DIA模板一般都是由主机厂提供给供应商。虽然各个厂家的DIA模板不尽相同，但是大同小异，主要内容都是ISO 26262中各个章节要求的产出物的集合，而DIA的主要目的则可以概括为：

• 明确主机厂和供应商在开发过程中各自的责任范围
• 明确供应商提交给主机厂的的递交物内容
• 明确供应商提供给主机厂的递交物形式（如文档或者现场展示）
• 明确主机厂对供应商功能安全开发阶段评估的方式（如评估次数和具体内容）

某客户提供给供应商的DIA模板截图

因为DIA的内容是供应商对功能安全开发的报价依据，所以在项目报价阶段就需要完成DIA。这里顺便提一句，主机厂和供应商间签订DIA是一个漫长的谈判过程，原因是主机厂和供应商各自打的算盘正好是对立的：主机厂希望在预算范围内尽可能要求供应商提供更多的递交物；而供应商则出于保密考虑尽可能拒绝客户的递交物要求。在DIA的谈判过程中，理论上供应商的整个项目团队都需要参与其中。功能安全经理起到协调作用，负责对主机厂解释功能安全开发流程，对内部解释DIA各项条目的含义；各个环节的开发人员需要基于功能安全经理的解释确定他所涉及的条目能否满足主机厂要求以及如何满足；项目经理则负责最终拍板，拍板的依据则主要考量开发经费和开发资源的对等性。

当主机厂和供应商明确了功能安全的合作范围和内容之后，功能安全开发工作将由双方的功能安全经理作为接口来统筹和协调，保障功能安全需求在主机厂和供应商之间被正确传递与执行。

同时，对于主机厂或供应商各自内部的功能安全开发来说，正如前面提到，功能安全经理通常也就是系统功能安全工程师，他将作为系统层的接口协调系统与软硬件团队的功能安全工作，保证系统层和软/硬件层功能安全需求的互相传递和执行。

功能安全开发过程交流示意图

系统/软件/硬件功能安全工程师的工作日常

不管对主机厂还是供应商，在一个客户项目中，很少遇到要从零开始开发一个全新的产品，一般都是基于现有的产品作为base进行开发，以满足新的项目需求，功能安全也是如此。围绕项目需求与平台Base不同的部分进行功能安全开发，识别不同点的活动称作FSIA（functional safety impact analysis）。

我们前面提到，一个完善的功能安全开发团队通常定义三个角色：

• 系统功能安全工程师
• 软件功能安全工程师
• 硬件功能安全工程师

每个角色负责下图中的一个V模型开发活动。

功能安全开发中的三个V模型 （截图来自GB/T 34590）

当功能安全是基于base来开发时，不管是对主机厂或供应商来说，这三个角色并不需要定义三个独立的工程师来做，这未免太奢侈，实际上也没必要。通常软/硬件功能安全工程师由软/硬件工程师兼任。

对软件功能安全开发而言，在软件开发流程完善和开发工具满足要求的前提下，在软件设计和验证过程中，功能安全需求和功能需求无需过分区别对待，有很多公司的软件开发流程本身就能保证符合ISO 26262中ASIL D的要求。因此功能安全对软件工程师增加的工作量主要体现在需求分析和输出文档，包括：

• 对系统层分配下来的安全需求进行可行性分析；
• 对输入信号提安全需求；
• 满足系统层或客户的文档需求。

对硬件功能安全开发而言，通常一款硬件的设计周期很长，而且设计好后很多年不会更新，所以几乎不会在客户项目中重新开发硬件。基于此，项目中硬件功能安全开发就可以完全沿用base既有的开发，功能安全对硬件工程师增加的工作量主要是：

• 为系统安全工程师提供FTA分析需要的硬件component失效率数据（FMEDA）；
• 满足系统层或客户的文档需求（如ECU FMEA分析报告）。

只有系统功能安全开发需要定义一个专门的岗位：功能安全经理。主机厂和供应商对功能安全经理的职责定义侧重点有一些不同，这也是主机厂和供应商之间的合作模式决定的。主机厂侧重于定义安全需求并分配给供应商，供应商则侧重于实现安全需求。

主机厂端功能安全经理的工作职责一般包括但不限于：

• 计划和协调系统安全开发活动
• 进行HARA分析，并结合分析结果和系统架构定义功能安全概念（functional safety concept）和技术安全概念（technical safety concept）
• 将安全需求分配给对应的子系统，或者说分配给子系统的供应商
• 负责协调子系统相互之间的功能安全需求的传递与澄清
• 协助内部功能安全验证，如创建整车test case和测试结果评估
• 对子系统功能安全开发进行审核

供应商端功能安全经理的工作职责一般包括但不限于：

• 计划和协调系统安全开发活动
• 基于HARA分析，根据安全需求和系统架构定义功能安全概念（functional safety concept）和技术安全概念（technical safety concept），对系统架构设计提出要求或建议
• 将安全需求分配给对应的软件工程师（和硬件工程师）
• 完成系统功能安全设计的定量分析和定性分析，通常分别使用FTA和FMEA
• 协助功能安全验证，如创建整车test case和测试结果评估
• 作为客户功能安全团队和功能安全审核团队的接口
• 对软/硬件工程师提供功能安全开发建议和指导

一般来说，生产和报废阶段的功能安全活动不在系统功能安全工程师的职责范围内。比如生产阶段的功能安全通常是由工厂经理来执行，执行的依据则是已经包含了功能安全需求的生产流程。当产品release后交到工厂，就意味着功能安全工程师的工作完成了。

相信大家可以看出，功能安全经理这个岗位对工程师的专业素质要求也很高，原则上需要有足够的软/硬件开发经验，这样才能胜任上到客户或供应商，下到软硬件工程师的交流工作。但是目前鉴于功能安全在企业还比较新，这方面的能力要求有适当放宽。

在这里也纠正一些同行对系统功能安全工作的误解。认为既然不用写代码，也不用画板子，那功能安全经理就只剩下流程和文档工作了。这话被功能安全经理听到他会伤心的，仿佛当年不被女神认可的感觉又回来了。诚然，功能安全的落地需要流程和文档来保证，但是功能安全开发的核心却是技术层面的东西而非流程。而功能安全的技术核心，体现在概念设计/系统分析/系统验证阶段对功能安全开发方法论的运用。

功能安全的前景及一些建议

就目前的现状来看，随着ADAS功能的普及和自动驾驶研究的热门，功能安全越来越被重视，市场需求量很大。猎头在挖人时开出的价码往往非常诱人。与此同时，目前国内功能安全做的成熟的企业不多，尚处于边做边摸索的阶段，所以目前挖人时并不很挑剔，对系统/软/硬件开发经验的要求有放宽。

相对于本土OEM，外企或者合资Tier1的know-how更高，比如博世，大陆，联电等等。合资OEM中泛亚的功能安全团队已经很成熟，因此在和这些供应商合作时很强势也有底气；而本土OEM在和这些供应商合作的同时也抱着花钱学习怎么做功能安全的目的。换句话说，OEM的态度从“你觉得怎么做？”到“我要你这么做！”还有些距离。但是，这种状况在将来一定会得到改变，因为本土主流的几家OEM的功能安全团队在以肉眼可见的速度壮大，大家越来越舍得在功能安全开发上投入成本（好多外国专家也因此体会到了社会主义高薪的诱惑力）。可以预见的是，自动驾驶的驱动会加速功能安全的落地，这会大大加速行业整体水平的提高。届时，国内市场对功能安全工程师的专业素养的要求也会越来越高；另一方面，ISO 26262在自动驾驶开发中的局限性也日益凸显，由此也催生了新的标准SOTIF的诞生，功能安全工程师需要掌握的知识越来越多。

正应了那句话：学无止境。

最后，考虑到市场上功能安全岗位的招聘绝大多数都是系统功能安全工程师，也就是功能安全经理，在说了这么多后，想给正在考虑这个岗位的工程师罗列几条个人建议，一家之言，仅供参考。

1. 首先，一定要明确功能安全是一个技术岗位而不是流程管理的岗位。既然是技术岗位，那么都对软/硬件开发经验有一定的要求。
2. 如果你已经有软件和硬件开发经验，那么你已经有很好的技术功底，功能安全队伍很需要你这样的全才，做功能安全的上限也很高。
3. 如果你只做过软件或者只做过硬件开发，依然能够从事功能安全开发。一方面毕竟软硬件都懂的全才很少，另一方面如前面提到，功能安全经理的工作内容聚焦在系统层，懂一些软/硬件开发的基本内容也可以把工作完成。但是建议在工作中多留心弥补自己不足的部分。
4. 如果你既没有软件开发经验也没有硬件开发经验，如果单考虑薪水的话，机会摆在面前也可以把握。但是个人建议先找软件开发相关的岗位积累开发经验，否则可能在对内对外的沟通中不免有纸上谈兵之嫌而难以服众，而且在功能安全领域的职业发展后期容易遇到瓶颈。
5. 如果有选择的话，最好去功能安全团队成熟的大公司做功能安全，比如上面提到的这些公司。这些公司的功能安全开发早已落地，也积累了很多自己的理解和经验，这对于一个小白来说无疑是站在巨人的肩膀上学习。而小公司可能还苦于如何把功能安全纳入开发流程，去了可能就是自己摸索着钻研和天书一样的ISO 26262标准，很难高效地提高自己的能力。

作者：小青的风筝，未经许可，谢绝转载，转载请联系小编13636581676（微信同）