1 什么是功能安全？
在这里仅从功能安全的定义出发，帮助建立对功能安全的浅显易懂的初印象。
ISO 26262对功能安全的定义为：
Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.国标GB/T 34590对这一定义的翻译为：不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险。从定义展开强调几个关键词。
1.“E/E system”，电子电器架构
功能安全要讨论的对象是E/E架构设计，因此机械/液压/化学等设计都不在ISO 26262的研究范围。换句话说，功能安全只是产品安全的一部分。
2.“hazard”，危害
危害有很多类型，如人身伤害或者财产损失等等。功能安全里的危害仅仅指因为E/E系统的故障行为而引起的对驾驶员或者路人或周边车辆内人员（注意：不仅仅是驾驶员）造成的健康伤害。换句话说，功能安全开发目的是避免伤人，而不是避免你的损伤你的豪车，也不是避免你的豪车被偷。
3.“unreasonable”，不合理的
就像世界上没有永动机一样，世界上也没有100%安全的系统，因此功能安全追求的是将风险控制在合理的范围内，或者说可被接受的范围内。如下图所示。判定风险是否可被接受，需要从两个维度去衡量：危害的严重性和危害发生的频率。举例来说，飞机失事几乎无人生还，但是正因为飞机失事的概率非常低，所以飞机依然是最重要和最受欢迎的交通工具之一。如果汽车上的空调开关出现故障的频率比较高，但故障只会影响驾驶员或乘客舒适性体验，不会造成人员受伤，你很可能等到下个月去4S店时才想起来维修它；但是，如果你的车突然在高速上自动加速，估计你马上停在紧急带弃车而逃，喊着要退车了，因为这种原本可以通过设计规避的故障是不可接受的。这也正是功能安全开发期望避免的故障。
在此补充一下，图中提到两个维度，危害的严重度和危害发生的频率。对功能安全有一些了解的朋友可能会疑惑 ：不是有三个参数评价，S（severity 严重度），E（Exposure 曝光度），C（controllability 可控度）来定义ASIL等级吗？其实不冲突，图中的第二个维度频率综合了E值和C值。怎么理解呢？因为“频率”指的是危害发生的频率，而“曝光度”指的是场景的曝光度。驾驶员的可控度是可以将高曝光度的场景下造成危害的频率降低的。举例来说，开高速的场景在日常生活中曝光度比较高，但是如果高速时发生意外加速，有些情况下通过驾驶员的制动干预是可以避免危害的，因此降低了危害发生的频率。
2 功能安全如何在企业落地？
由于ISO 26262的覆盖范围非常广，对整车完整生命周期都进行了功能安全的指导，除了我们熟知的V模型开发过程外，就连生产和报废阶段都考虑在内；再加上各个企业开发流程中存在的的差异性，所有针对“功能安全如何在企业落地”这一问题，很难进行全面的回答。在这里仅谈两点功能安全落地的先决条件。
“安全文化”这个词乍一听很虚，感觉像是喊组织口号。但实际上，安全文化体现在很多看得见的方面，比如：
从这些方面可以看出，安全文化并不只是空虚的口号，而是实实在在地体现在公司的开发流程中的。优秀的安全文化一定意味着企业有非常完善的开发流程。否则功能安全只是空中楼阁，落地无从谈起。于此同时，完善的流程也意味着要增加相应的岗位和工程师们的工作量，甚至是升级开发工具，开发成本也随之上升。
针对这一点，不同的企业也有一些出入，但是，功能安全开发比较成熟的企业间至少有一点是能达成一致的，那就是不可能是由一个功能安全开发工程师同时负责系统/软件/硬件所有的功能安全开发。就算有这种万里挑一的全才，也得考虑如此庞大的工作量会不会把人才赶跑了。
一个完善的功能安全开发团队通常定义三个角色：
每个角色负责下图中的一个V模型开发活动。
对于后两个角色，如果是开发一个全新的产品，由于工作量大，人员配置比较充足的企业会独立于软/硬件开发工程师之外再指派两个工程师担任；如果是基于企业已经量产的产品，根据不同客户的需求做修改，由于工作量相对减少很多，那么软/硬件功能安全工程师通常由软/硬件开发工程师兼任。但是不论是开发全新产品还是基于已有产品修改，系统功能安全工程师一般是专门的岗位。在很多企业系统功能安全工程师也称为功能安全经理，负责统筹协调整个产品的功能安全开发工作。
3 功能安全经理的工作定义
也正是由于上文提到的原因，市场上功能安全岗位的招聘绝大多数都是系统功能安全工程师，也就是功能安全经理。这里从网上分别选择一个较为典型的OEM和供应商的招聘信息，由此来窥见一些功能安全经理的工作内容。
可以看出，主机厂和供应商对功能安全经理的职责定义侧重点有一些不同，这也是主机厂和供应商之间的合作模式决定的。另外，相信大家也可以理解，为什么系统层的功能安全开发需要专门的人负责了，因为工作量实在有点大。尤其是现阶段国内功能安全开发的理念和方法论还没有到深入人心的程度，如果遇到客户不懂，软硬件工程师也不懂，那么光是对外交流和对内沟通就需要花大量的时间。如果一个项目足够大，客户新需求足够多，可能不止一个系统功能安全工程师。
4 主机厂和供应商功能安全合作
主机厂和供应商共同遵守ISO 26262中定义的要求，合作完成某个产品的开发，这一合作模式被称为“分布式开发（Distributed Development）”。而分布式开发的前提则是明确双方的责任范围和边界，这部分内容最终以双方共同商议并签署的DIA (开发接口协议，development interface agreement) 呈现，后续双方在功能安全开发过程中的协作将完全依照DIA为指南进行。
DIA模板一般都是由主机厂提供给供应商。虽然各个厂家的DIA模板不尽相同，但是大同小异，主要内容都是ISO 26262中各个章节要求的产出物的集合，而DIA的主要目的则可以概括为：
某客户提供给供应商的DIA模板截图
因为DIA的内容是供应商对功能安全开发的报价依据，所以在项目报价阶段就需要完成DIA。这里顺便提一句，主机厂和供应商间签订DIA是一个漫长的谈判过程，原因是主机厂和供应商各自打的算盘正好是对立的：主机厂希望在预算范围内尽可能要求供应商提供更多的递交物；而供应商则出于保密考虑尽可能拒绝客户的递交物要求。在DIA的谈判过程中，理论上供应商的整个项目团队都需要参与其中。功能安全经理起到协调作用，负责对主机厂解释功能安全开发流程，对内部解释DIA各项条目的含义；各个环节的开发人员需要基于功能安全经理的解释确定他所涉及的条目能否满足主机厂要求以及如何满足；项目经理则负责最终拍板，拍板的依据则主要考量开发经费和开发资源的对等性。
当主机厂和供应商明确了功能安全的合作范围和内容之后，功能安全开发工作将由双方的功能安全经理作为接口来统筹和协调，保障功能安全需求在主机厂和供应商之间被正确传递与执行。
同时，对于主机厂或供应商各自内部的功能安全开发来说，正如前面提到，功能安全经理通常也就是系统功能安全工程师，他将作为系统层的接口协调系统与软硬件团队的功能安全工作，保证系统层和软/硬件层功能安全需求的互相传递和执行。
功能安全开发过程交流示意图
5 系统/软件/硬件功能安全工程师的日常工作
不管对主机厂还是供应商，在一个客户项目中，很少遇到要从零开始开发一个全新的产品，一般都是基于现有的产品作为base进行开发，以满足新的项目需求，功能安全也是如此。围绕项目需求与平台Base不同的部分进行功能安全开发，识别不同点的活动称作FSIA（functional safety impact analysis）。我们前面提到，一个完善的功能安全开发团队通常定义三个角色：
每个角色负责下图中的一个V模型开发活动。
功能安全开发中的三个V模型 （截图来自GB/T 34590）
当功能安全是基于base来开发时，不管是对主机厂或供应商来说，这三个角色并不需要定义三个独立的工程师来做，这未免太奢侈，实际上也没必要。通常软/硬件功能安全工程师由软/硬件工程师兼任。
对软件功能安全开发而言，在软件开发流程完善和开发工具满足要求的前提下，在软件设计和验证过程中，功能安全需求和功能需求无需过分区别对待，有很多公司的软件开发流程本身就能保证符合ISO 26262中ASIL D的要求。因此功能安全对软件工程师增加的工作量主要体现在需求分析和输出文档，包括：
对硬件功能安全开发而言，通常一款硬件的设计周期很长，而且设计好后很多年不会更新，所以几乎不会在客户项目中重新开发硬件。基于此，项目中硬件功能安全开发就可以完全沿用base既有的开发，功能安全对硬件工程师增加的工作量主要是：
只有系统功能安全开发需要定义一个专门的岗位：功能安全经理。主机厂和供应商对功能安全经理的职责定义侧重点有一些不同，这也是主机厂和供应商之间的合作模式决定的。主机厂侧重于定义安全需求并分配给供应商，供应商则侧重于实现安全需求。
主机厂端功能安全经理的工作职责一般包括但不限于：
供应商端功能安全经理的工作职责一般包括但不限于：
计划和协调系统安全开发活动
基于HARA分析，根据安全需求和系统架构定义功能安全概念（functional safety concept）和技术安全概念（technical safety concept），对系统架构设计提出要求或建议
将安全需求分配给对应的软件工程师（和硬件工程师）
完成系统功能安全设计的定量分析和定性分析，通常分别使用FTA和FMEA
协助功能安全验证，如创建整车test case和测试结果评估
作为客户功能安全团队和功能安全审核团队的接口
对软/硬件工程师提供功能安全开发建议和指导
一般来说，生产和报废阶段的功能安全活动不在系统功能安全工程师的职责范围内。比如生产阶段的功能安全通常是由工厂经理来执行，执行的依据则是已经包含了功能安全需求的生产流程。当产品release后交到工厂，就意味着功能安全工程师的工作完成了。
相信大家可以看出，功能安全经理这个岗位对工程师的专业素质要求也很高，原则上需要有足够的软/硬件开发经验，这样才能胜任上到客户或供应商，下到软硬件工程师的交流工作。但是目前鉴于功能安全在企业还比较新，这方面的能力要求有适当放宽。
在这里也纠正一些同行对系统功能安全工作的误解。认为既然不用写代码，也不用画板子，那功能安全经理就只剩下流程和文档工作了。这话被功能安全经理听到他会伤心的，仿佛当年不被女神认可的感觉又回来了。诚然，功能安全的落地需要流程和文档来保证，但是功能安全开发的核心却是技术层面的东西而非流程。而功能安全的技术核心，体现在概念设计/系统分析/系统验证阶段对功能安全开发方法论的运用。
6 功能安全的前景及一些建议
就目前的现状来看，随着ADAS功能的普及和自动驾驶研究的热门，功能安全越来越被重视，市场需求量很大。猎头在挖人时开出的价码往往非常诱人。与此同时，目前国内功能安全做的成熟的企业不多，尚处于边做边摸索的阶段，所以目前挖人时并不很挑剔，对系统/软/硬件开发经验的要求有放宽。
相对于本土OEM，外企或者合资Tier1的know-how更高，比如博世，大陆，联电等等。合资OEM中泛亚的功能安全团队已经很成熟，因此在和这些供应商合作时很强势也有底气；而本土OEM在和这些供应商合作的同时也抱着花钱学习怎么做功能安全的目的。换句话说，OEM的态度从“你觉得怎么做？”到“我要你这么做！”还有些距离。但是，这种状况在将来一定会得到改变，因为本土主流的几家OEM的功能安全团队在以肉眼可见的速度壮大，大家越来越舍得在功能安全开发上投入成本（好多外国专家也因此体会到了社会主义高薪的诱惑力）。可以预见的是，自动驾驶的驱动会加速功能安全的落地，这会大大加速行业整体水平的提高。届时，国内市场对功能安全工程师的专业素养的要求也会越来越高；另一方面，ISO 26262在自动驾驶开发中的局限性也日益凸显，由此也催生了新的标准SOTIF的诞生，功能安全工程师需要掌握的知识越来越多。
正应了那句话：学无止境。
最后，考虑到市场上功能安全岗位的招聘绝大多数都是系统功能安全工程师，也就是功能安全经理，在说了这么多后，想给正在考虑这个岗位的工程师罗列几条个人建议，一家之言，仅供参考。
（1） 一定要明确功能安全是一个技术岗位而不是流程管理的岗位。既然是技术岗位，那么都对软/硬件开发经验有一定的要求。
（2） 如果你已经有软件和硬件开发经验，那么你已经有很好的技术功底，功能安全队伍很需要你这样的全才，做功能安全的上限也很高。
（3） 如果你只做过软件或者只做过硬件开发，依然能够从事功能安全开发。一方面毕竟软硬件都懂的全才很少，另一方面如前面提到，功能安全经理的工作内容聚焦在系统层，懂一些软/硬件开发的基本内容也可以把工作完成。但是建议在工作中多留心弥补自己不足的部分。
（4） 如果你既没有软件开发经验也没有硬件开发经验，如果单考虑薪水的话，机会摆在面前也可以把握。但是个人建议先找软件开发相关的岗位积累开发经验，否则可能在对内对外的沟通中不免有纸上谈兵之嫌而难以服众，而且在功能安全领域的职业发展后期容易遇到瓶颈。
（5） 如果有选择的话，最好去功能安全团队成熟的大公司做功能安全，比如上面提到的这些公司。这些公司的功能安全开发早已落地，也积累了很多自己的理解和经验，这对于一个小白来说无疑是站在巨人的肩膀上学习。而小公司可能还苦于如何把功能安全纳入开发流程，去了可能就是自己摸索着钻研和天书一样的ISO 26262标准，很难高效地提高自己的能力。
