1
什么是功能安全？
ISO 26262对功能安全的定义为：
2
由于ISO 26262的覆盖范围非常广，对整车完整生命周期都进行了功能安全的指导，除了我们熟知的V模型开发过程外，就连生产和报废阶段都考虑在内；再加上各个企业开发流程中存在的的差异性，所有针对“功能安全如何在企业落地”这一问题，很难进行全面的回答。在这里仅谈两点功能安全落地的先决条件。
功能安全在各个开发阶段的主要活动 （截图来自GB/T 34590）
“安全文化”这个词乍一听很虚，感觉像是喊组织口号。但实际上，安全文化体现在很多看得见的方面，比如：
在所有层面（管理/开发/验证/审核）执行是否有明确的、可追踪的和受控的流程？
安全文化举例 （截图来自GB/T 34590）
从这些方面可以看出，安全文化并不只是空虚的口号，而是实实在在地体现在公司的开发流程中的。优秀的安全文化一定意味着企业有非常完善的开发流程。否则功能安全只是空中楼阁，落地无从谈起。于此同时，完善的流程也意味着要增加相应的岗位和工程师们的工作量，甚至是升级开发工具，开发成本也随之上升。
针对这一点，不同的企业也有一些出入，但是，功能安全开发比较成熟的企业间至少有一点是能达成一致的，那就是不可能是由一个功能安全开发工程师同时负责系统/软件/硬件所有的功能安全开发。就算有这种万里挑一的全才，也得考虑如此庞大的工作量会不会把人才赶跑了。
一个完善的功能安全开发团队通常定义三个角色：
系统功能安全工程师
软件功能安全工程师
硬件功能安全工程师
每个角色负责下图中的一个V模型开发活动。
功能安全开发中的三个V模型 （截图来自GB/T 34590）
对于后两个角色，如果是开发一个全新的产品，由于工作量大，人员配置比较充足的企业会独立于软/硬件开发工程师之外再指派两个工程师担任；如果是基于企业已经量产的产品，根据不同客户的需求做修改，由于工作量相对减少很多，那么软/硬件功能安全工程师通常由软/硬件开发工程师兼任。但是不论是开发全新产品还是基于已有产品修改，系统功能安全工程师一般是专门的岗位。在很多企业系统功能安全工程师也称为功能安全经理，负责统筹协调整个产品的功能安全开发工作。
3
某供应商的功能安全经理招聘信息 （截图来自猎聘网）
4
主机厂和供应商共同遵守ISO 26262中定义的要求，合作完成某个产品的开发，这一合作模式被称为“分布式开发（Distributed Development）”。而分布式开发的前提则是明确双方的责任范围和边界，这部分内容最终以双方共同商议并签署的DIA (开发接口协议，development interface agreement) 呈现，后续双方在功能安全开发过程中的协作将完全依照DIA为指南进行。
DIA模板一般都是由主机厂提供给供应商。虽然各个厂家的DIA模板不尽相同，但是大同小异，主要内容都是ISO 26262中各个章节要求的产出物的集合，而DIA的主要目的则可以概括为：
明确主机厂对供应商功能安全开发阶段评估的方式（如评估次数和具体内容）
某客户提供给供应商的DIA模板截图
因为DIA的内容是供应商对功能安全开发的报价依据，所以在项目报价阶段就需要完成DIA。这里顺便提一句，主机厂和供应商间签订DIA是一个漫长的谈判过程，原因是主机厂和供应商各自打的算盘正好是对立的：主机厂希望在预算范围内尽可能要求供应商提供更多的递交物；而供应商则出于保密考虑尽可能拒绝客户的递交物要求。在DIA的谈判过程中，理论上供应商的整个项目团队都需要参与其中。功能安全经理起到协调作用，负责对主机厂解释功能安全开发流程，对内部解释DIA各项条目的含义；各个环节的开发人员需要基于功能安全经理的解释确定他所涉及的条目能否满足主机厂要求以及如何满足；项目经理则负责最终拍板，拍板的依据则主要考量开发经费和开发资源的对等性。
当主机厂和供应商明确了功能安全的合作范围和内容之后，功能安全开发工作将由双方的功能安全经理作为接口来统筹和协调，保障功能安全需求在主机厂和供应商之间被正确传递与执行。
5
硬件功能安全工程师
当功能安全是基于base来开发时，不管是对主机厂或供应商来说，这三个角色并不需要定义三个独立的工程师来做，这未免太奢侈，实际上也没必要。通常软/硬件功能安全工程师由软/硬件工程师兼任。
对软件功能安全开发而言，在软件开发流程完善和开发工具满足要求的前提下，在软件设计和验证过程中，功能安全需求和功能需求无需过分区别对待，有很多公司的软件开发流程本身就能保证符合ISO 26262中ASIL D的要求。因此功能安全对软件工程师增加的工作量主要体现在需求分析和输出文档，包括：
满足系统层或客户的文档需求。
对硬件功能安全开发而言，通常一款硬件的设计周期很长，而且设计好后很多年不会更新，所以几乎不会在客户项目中重新开发硬件。基于此，项目中硬件功能安全开发就可以完全沿用base既有的开发，功能安全对硬件工程师增加的工作量主要是：
满足系统层或客户的文档需求（如ECU FMEA分析报告）。
只有系统功能安全开发需要定义一个专门的岗位：功能安全经理。主机厂和供应商对功能安全经理的职责定义侧重点有一些不同，这也是主机厂和供应商之间的合作模式决定的。主机厂侧重于定义安全需求并分配给供应商，供应商则侧重于实现安全需求。
对子系统功能安全开发进行审核
对软/硬件工程师提供功能安全开发建议和指导
一般来说，生产和报废阶段的功能安全活动不在系统功能安全工程师的职责范围内。比如生产阶段的功能安全通常是由工厂经理来执行，执行的依据则是已经包含了功能安全需求的生产流程。当产品release后交到工厂，就意味着功能安全工程师的工作完成了。
相信大家可以看出，功能安全经理这个岗位对工程师的专业素质要求也很高，原则上需要有足够的软/硬件开发经验，这样才能胜任上到客户或供应商，下到软硬件工程师的交流工作。但是目前鉴于功能安全在企业还比较新，这方面的能力要求有适当放宽。
在这里也纠正一些同行对系统功能安全工作的误解。认为既然不用写代码，也不用画板子，那功能安全经理就只剩下流程和文档工作了。这话被功能安全经理听到他会伤心的，仿佛当年不被女神认可的感觉又回来了。诚然，功能安全的落地需要流程和文档来保证，但是功能安全开发的核心却是技术层面的东西而非流程。而功能安全的技术核心，体现在概念设计/系统分析/系统验证阶段对功能安全开发方法论的运用。
6
就目前的现状来看，随着ADAS功能的普及和自动驾驶研究的热门，功能安全越来越被重视，市场需求量很大。猎头在挖人时开出的价码往往非常诱人。与此同时，目前国内功能安全做的成熟的企业不多，尚处于边做边摸索的阶段，所以目前挖人时并不很挑剔，对系统/软/硬件开发经验的要求有放宽。
相对于本土OEM，外企或者合资Tier1的know-how更高，比如博世，大陆，联电等等。合资OEM中泛亚的功能安全团队已经很成熟，因此在和这些供应商合作时很强势也有底气；而本土OEM在和这些供应商合作的同时也抱着花钱学习怎么做功能安全的目的。换句话说，OEM的态度从“你觉得怎么做？”到“我要你这么做！”还有些距离。但是，这种状况在将来一定会得到改变，因为本土主流的几家OEM的功能安全团队在以肉眼可见的速度壮大，大家越来越舍得在功能安全开发上投入成本（好多外国专家也因此体会到了社会主义高薪的诱惑力）。可以预见的是，自动驾驶的驱动会加速功能安全的落地，这会大大加速行业整体水平的提高。届时，国内市场对功能安全工程师的专业素养的要求也会越来越高；另一方面，ISO 26262在自动驾驶开发中的局限性也日益凸显，由此也催生了新的标准SOTIF的诞生，功能安全工程师需要掌握的知识越来越多。
正应了那句话：学无止境。
最后，考虑到市场上功能安全岗位的招聘绝大多数都是系统功能安全工程师，也就是功能安全经理，在说了这么多后，想给正在考虑这个岗位的工程师罗列几条个人建议，一家之言，仅供参考。
（1） 一定要明确功能安全是一个技术岗位而不是流程管理的岗位。既然是技术岗位，那么都对软/硬件开发经验有一定的要求。
（2） 如果你已经有软件和硬件开发经验，那么你已经有很好的技术功底，功能安全队伍很需要你这样的全才，做功能安全的上限也很高。
文章来源：牛喀网，侵删
推荐阅读
基于UDS的Bootloder详解
关于整车上下电流程的理解
OEM：与软件供应商合作的六个经验总结
关于车载以太网 Switch Vlan的理解
2018版IS026262与2011版有哪些差异？
Adaptive AUTOSAR 学习笔记 - AP 背景、技术及特征
AURIX TC3XX系列的SOTA机制详解
一文详解奥迪e-tron内部系统 |附下载
ID.3 和大众的电气化平台 |附下载
一文详解CAN总线错误帧|附下载
DoIP协议介绍，资料分享！
详解车载网络 OTA系统的开发|文末附下载
一文了解汽车嵌入式AUTOSAR架构|附下载
特斯拉Autopilot系统安全研究|附dbc下载
