登陆

万字长文：功能安全量产落地的三座大山

来源：公众号“ 汽车电子与软件”

2021-01-15

导读：

如果说实践是检验真理的唯一标准，那么量产是检验功能安全落地的唯一标准。基于此，笔者根据以往的项目经验，总结了现阶段功能安全量产落地的三大主要困难，取名为“三座大山”。它们是：

融合与平衡
周期与成本
理论与实践

笔者将详细描述这“三座大山”，希望能抛砖引玉，促进国内同行之间的交流讨论，为功能安全在国内推广普及贡献一丝力量。

序言

功能安全在汽车行业突然走红可以追溯到2016年。当时，大大小小的造车新势力如雨后春笋般层出不穷，汽车行业在技术革命的浪潮中呈现出一派欣欣向荣景象，也带红了实际上早在2011年就发布的ISO 26262标准。功能安全一时间风头无两，谈新能源、谈智能网联就必谈功能安全。

经过17、18、19三年，国内各大主机厂和零部件供应商基本上都试着进行了功能安全的引进和导入。即便没有完整的走完一轮，但起码都或多或少的试过水。然而到了2020年，能够真正实现功能安全量产落地的国内企业却寥寥无几。

大家对功能安全的普遍反映包括：

“太虚了。”
“流程太复杂，做起来很麻烦。”
“项目太紧，没有资源去做。”
“技术指标要求太高，做不到。”
“动不动就进安全状态，车没法开了。”
……

作为一名从2012年开始担任功能安全岗位的老兵，笔者先后待过两个不同的行业。坦率的说，有国家/政府/行业强制要求的话，功能安全更容易推动一些。比如说在欧洲、尤其是在德国，所有产品都受到《产品责任法》管辖。该法规定，产品的销售和展示，不管是被预期使用，还是被可预见的误用，都不能损害个人安全、健康以及其它公众利益，否则就是违法行为。零部件制造商、供应商必须向OEM和监管机构证明其产品满足所要求的安全功能，不存在由于产品缺陷而引起的失效风险，并且在设计研发过程中使用了最先进的技术。也就是说，产品制造商负有举证责任。在这种大环境下，功能安全非常普及。

但国家/政府/行业强制并不是功能安全量产落地的根本原因，这只是表象。笔者认为，起源于欧洲、尤其是德、法等发达国家的功能安全，是建立在其国家发展实际情况基础之上的，这包括社会文化、经济水平、工业基础等各个方面。事实上，发达国家已经针对工业控制的各个子行业，建立了完善的功能安全标准体系。这说明了什么？这说明，功能安全标准本质上其实是一种生产关系的反映，它必须与生产力相匹配才能落地生根。所以，功能安全在不同国家的推广进程肯定是不一样的，每个国家都有自己的国情。功能安全想要在国内企业落地，就必须适配国内企业的实际情况，同时国内企业也有一些方面需要调整，双方都往中间靠拢，最终才可能汇合。

话虽如此，但实际做起来又哪有那么容易？接触过功能安全的人都知道，功能安全有以下几个特点：

基于流程驱动，包括需求开发、架构设计、详细设计、实现、集成、测试验证、确认等环节，在每个环节都有相应的技术要求；
覆盖产品的全生命周期，包括策划、概念、设计、验证、生产、运行一直到报废；
覆盖电子电气的各个方面，包括传感器、处理器、执行器、硬件电路、基础软件、应用软件、芯片、软件工具等；
覆盖影响上述内容的支持过程，包括项目管理、安全管理、需求管理、配置管理、变更管理、生产管理、售后服务管理等。

可以看到，功能安全是一个系统的、完整的体系，内部逻辑非常严谨，环环相扣。对其中任何一个部分进行调整，都有可能造成整体性逻辑链条的损害或缺失。任何局部的改动，都必须从整体上来考虑，否则就有可能形成逻辑上的漏洞。想想也是，ISO 26262标准从2005年开始制定，在6年后、也就是2011年发布了第一版，又在7年后、也就是2018年发布了第二版，它已经很成熟了。所以，要想让ISO 26262标准适配国内企业的实际情况，需要国内整个行业的共同努力，大家一起学习、讨论、提炼、调整、完善，才有可能让ISO 26262真正在国内落地生根。

这几年项目做下来，笔者也遇到过大大小小的问题，有的已经解决了，有的还在想办法解决。如果说实践是检验真理的唯一标准，那么量产是检验功能安全落地的唯一标准。基于此，笔者根据以往的项目经验，总结了现阶段功能安全量产落地的三大主要困难，取名为“三座大山”。它们是：

融合与平衡
周期与成本
理论与实践

笔者将详细描述这“三座大山”，希望能抛砖引玉，促进国内同行之间的交流讨论，为功能安全在国内推广普及贡献一丝力量。

融合与平衡

2.1 融合的必要性

在某些行业比如轨道交通、过程工业等，安全防护设备（如SIS）和常规控制设备（如DCS）常常是分开的。也就是说，它们在物理上是独立的实体。从系统自顶向下分解而来的安全功能，基本上都由安全防护设备来承担，而安全防护设备基本上也只承担安全功能。功能安全只针对安全防护设备，以及安全防护设备和常规控制设备的系统集成。这样的系统架构泾渭分明，非常清晰，也比较容易理解。

然而在汽车行业就不一样了，安全功能和非安全功能常常是由同一个设备来承担的。不管是为了降低产品成本，还是为了节省布置空间，除了个别情况下使用ASIL分解来隔离安全功能和非安全功能外，总体上而言，我们面临的项目基本上都是需要ASIL和QM混合开发的，ASIL的内容只是项目的一部分。所以，功能安全永远是也只能是产品的一部分。笔者认为，这是汽车功能安全从业人员首先需要端正的态度和认识。

由于ISO26262标准自身非常完备，功能安全工程师很容易产生一种错觉：我已经有了葵花宝典，还要紫霞神功干啥？这种观点其实大错特错。首先，你误解了ISO 26262标准的真正含义，这一点后文会讲到。其次，你有没有想过：在目前没有国家/政府/行业强制要求的情况下，产品研发可以不导入功能安全。

但反过来却完全不同，要导入功能安全必须依托产品研发。也就是说，功能安全必须与现有的产品研发融合，才有落地的可能。其中包括：

安全管理流程与现有产品流程融合；
安全需求开发与现有产品需求融合；
安全架构设计与现有产品架构融合；
安全软件设计与现有产品软件融合；
……

这里笔者想着重强调一下“现有”，是因为大多数企业在导入功能安全之前，基本上都已经有自己的产品或者产品原型了。甚至说该产品是可以投放市场的，只不过没有按照功能安全标准的要求进行研发而已。也就是说，先有常规控制，后有功能安全，这是汽车功能安全项目面临的普遍情况。既然功能安全是后来的，那么就应该主动的融合到现有的产品当中去。导入功能安全不是为了推翻和颠覆，而是为了继承和发扬，在与现有产品融合的过程中对其施行必要的改进和优化，这样才能以最少的成本将功能安全落地。

2.2 案例分享

给大家分享一个笔者在实际项目中遇到的案例。如图所示，信号传输路径为：传感器-->采集板-->主控板-->执行器。对于传感器的电路故障（开路、短路）诊断，

一般放在采集板实施，这个通常没有异议。但对于传感器的合理性故障诊断，可以放在采集板，也可以放在主控板，这两种方式都不违背功能安全的原则。

到底哪种方式更合理，其实很大程度上取决于现有产品的设计。也就是说，在导入功能安全之前，主控板和采集板的分工是什么？采集板有没有协助主控板进行算法处理，还是单纯的采集和传输？采集板有没有开发软件标定功能？主控板和采集板之间的通信带宽是否允许传输更多的原始数据，还是只能增加一些故障信息？主控板和采集板的硬件余量（RAM空间、ROM空间、CPU负载率等）分别还有多大？……这些都是需要考虑的因素。笔者最后综合考虑各方面因素，选择了在主控板完成对传感器的合理性故障诊断。

2.3 实施建议

既然与现有产品融合如此重要，那么到底应该怎么做呢？ISO 26262标准里其实提供了一个解决方案：从现有产品研发中获得输入。下面是几个例子：

开发FSC需要的输入：

开发TSC需要的输入：

开发HSR需要的输入：

开发SSR需要的输入：

以上这些内容可能平日里大家关注没那么多，但事实上ISO 26262标准隐含的要求就是功能安全要与现有产品相融合。这个思路本身挺好，但在项目实际过程中，常常会遇到另一个现实问题：现有产品文档严重缺失，无法提供关键有效的输入。稍微夸张一点说，它就是一个黑盒。这种情况下，就算功能安全想要主动去融合，实际操作起来也有很大的困难。所以，现有产品研发流程体系越完善，功能安全越容易落地。一般来说，如果CMMI或者A-SPICE达到Level 3，可以认为产品研发流程体系比较完善。

遇到上面这种情况怎么办？其实也没有更好的办法，只能是功能安全工程师投入更多的时间、精力，通过调查、访谈、甚至是逆向工程等方法，将缺失的信息补上。毕竟，与现有产品实现融合并不意味着功能安全就能量产落地，这只是需要解决的问题之一。但是，放弃与现有产品的融合就意味着功能安全的导入必然以失败而告终，这一点毋庸置疑。

2.4 平衡的必要性

在功能安全与现有产品融合的过程中，不可避免的会遇到平衡的问题。所以，笔者将融合与平衡放在一起论述。

什么是平衡问题？很多功能安全工程师在项目实施过程中，自始至终的关注点都是安全目标能不能实现、会不会违背，安全性非常重要、甚至高于一切。从功能安全的角度出发，这是理所应当的做法。但是对于整个项目而言，安全性只是产品的属性之一。除了安全性之外，我们耳熟能详的产品属性还包括可用性、可靠性、可维护性、可测试性、可扩展性、可移植性、可重用性……，这些都是产品研发需要考虑的方面。所以，最终的产品设计，一定是各个方面综合考虑、折中平衡的结果。

很多功能安全工程师都有过切身经历，就是在项目组中常常要和别人“吵架”，有的时候甚至要争论很久才能达成一致。这其实就是平衡问题的现实反映：每个人都有自己的立场，每个人都希望自己的观点能够变成最终结论，而其他人能够接受自己的观点，并为之做出让步和妥协。

但现实情况哪可能如此理想？你眼中的人命关天，别人可能根本就不理解、不接受，甚至都不关心。所以，对功能安全工程师来说，沟通能力非常重要。因为你需要不断的说服别人，上到管理层、下到普通员工，都可能是你需要说服的对象。如果你只会特别强硬的坚持自己的观点，最后很可能就是你一个人站在所有人的对立面，结局可想而知。

除了加强沟通之外，我们也可以尝试换位思考一下：为什么会有这么多反对的声音？有没有可能是我们的立场太狭隘、视角太片面呢？有句话叫“不忘初心，方得始终”。我们做功能安全的初衷是什么？是为了降低产品风险，防止人员伤亡。但我们不能忽略一个事实：产品是由企业研发、生产、制造、销售和维护的，产品可能造成人员伤亡的前提是有用户使用该产品。

我们来设想一些极端的例子：

一架永不起降的飞机；
一列永不出站的火车；
一辆永不发动的汽车；
一台永不运行的X光机；
……

这些设备都非常安全，但是没有用！因为没有人使用它们。于是一个悖论出现了：

当使用该产品的用户很少时，类似的悖论仍然有可能出现：

如果真的遇到了上面这样的情况，你会不会产生自我怀疑？坚持了这么久的功能安全，到底有什么意义和价值？

实际上，功能安全的意义和价值，是通过产品传递给用户的。产品首先需要销售给用户、让用户来使用，然后用户在使用产品的过程中可能会遇到由于电子电气故障引发的风险，这种风险可以通过功能安全来降低至合理水平。使用产品的用户越多，功能安全的意义和价值就越大。

基于此，笔者想再次强调：功能安全永远是也只能是产品的一部分，安全性只是产品的属性之一。所以，功能安全工程师千万不要把自己局限在功能安全里面。实现功能安全没有什么了不起的，这本来就是你的职责所在。如果做不到，只能说明你还不够称职，还需要继续努力。但如果仅仅只是实现了功能安全，你可以称得上合格，但还谈不上优秀。真正牛逼的功能安全工程师，需要更上一层楼，站在产品的角度来看问题，在确保产品安全性的同时，平衡好安全性和产品其它属性的关系。

2.5 案例分享

给大家分享一个笔者在实际项目中遇到的案例。系统架构如图所示，MCU通过驱动器控制执行器，并且定时对SBC喂狗。安全目标对应的FTTI为3秒，而MCU复位一次的时间约为500毫秒。将SBC的延时切断设置为2秒，既不违背FTTI，又可以容许MCU多次复位，在保证安全性的同时提高可用性。

2.4 实施建议

如何解决平衡问题？笔者认为，首先是要树立全局意识。我们的目标决不是仅仅为产品的Safety负责，我们要为产品的Dependability负责。Dependability包括Reliability、Availability、Maintainability和Safety等RAMS的各个方面。这样慢慢的你就会站在更高的层面来看待功能安全，也就能更好的将功能安全融合到产品当中去。

其次，需要具备灵活运用功能安全原理的能力，知其然并知其所以然，做到收放自如。如果只是生搬硬套、照本宣科，片面强调安全性，那就肯定无法平衡好产品的各个属性。这一点将在“理论与实践”部分再与大家详细讨论。

周期与成本

3.1 交付周期的重要性

我们先来看一些汽车企业高管的公开言论：

在未来五年中，沃尔沃汽车公司将每年推出一款纯电动汽车，力争到2025年纯电动汽车占全球销量的50％，其余为混动车型。

——沃尔沃总裁兼首席执行官哈坎·萨缪尔森

未来5年，通用汽车在全球推出的30款电动车型……通用汽车将提前完成12款全球电动车型的开发工作。

——通用汽车首席执行官玛丽·博拉

以后，我们需要考虑新功能的发布周期，几天甚至几个小时，而不是几个月。

——戴姆勒研发部门首席信息官席格马尔·哈西

大家感受到了吗？市场的节奏早就不再是以前三、四年推一款新车的那种沉稳的风格了。现在各大车企都在加快推出新车型，纯电领域已经基本做到了一年一款甚至多款新车。

从2012年的Model S搭载整车OTA技术以来，到现在特斯拉已经通过OTA为其推送了二三十次的大版本软件升级，其中涉及了人机交互、动力系统、自动驾驶等众多方面，完成了钥匙卡漏洞修复、续航里程提升、提高最高速度、提升乘坐舒适度等功能调整。这在传统的汽车研发流程里几乎是不可想象的。从某种角度而言，Model S的研发在其量产之后一直持续进行着，而且研发交付周期很短，因为软件更新频率很高。

可能当初谁也不会想到，特斯拉，这家从美国硅谷横空出世的电动汽车制造商会以绝对领先的优势超越丰田、大众等传统车企巨鳄，成为全球市值最高的汽车制造商。不管你愿不愿意承认，事实上特斯拉已经取得了阶段性胜利，其采用的很多创新理念和技术正引领业界潮流。特斯拉从一个科技公司而非汽车公司的视角重新定义了电动汽车，使得各大车企感受到了巨大压力。

市场竞争如此激烈，如果你不想被淘汰，就必须跟上节奏：

快速交付产品，抢占市场；
及时了解市场需求，根据用户偏好做出功能优化；
迅速修复软件bug，提升售后服务效率；
……

于是，我们今天要讨论的问题就出现了：产品研发周期这么短，连常规控制功能的交付压力都如此之大，还怎么做功能安全？

事实上交付周期对功能安全是一个巨大的挑战。众所周知，ISO 26262标准依照“V”模型将系统、软件、硬件等不同层面的工作组织到一起，严格来说在上一个阶段必须做足功课才能进入下一个阶段。这种模式很严谨，但也很死板。按部就班、步步为营的工作方式，可能真的无法适应需要快速交付产品的市场节奏。还记得笔者之前提到的悖论吗？如果你的产品失去了市场，那就意味着很少人会使用，于是也就不需要做什么功能安全了，因为人员伤亡风险很低。所以，功能安全也需要适应市场节奏，做到快速交付。

3.2 案例分享

在这几年的项目经历中，笔者已经不止一次遇到过由于赶不上SOP时间，暂缓或停止功能安全任务的事情了。这其实也能理解，先有常规控制，后有功能安全。如果连基本功能都不成熟的话，产品根本就达不到投放市场的条件，又怎么去抢占市场呢？所以产品交付肯定是第一位的。

坦率的说，基于传统“V”模型来实施功能安全，在面对周期只有一年、甚至更短的项目时，笔者也没有太好的办法。笔者曾经尝试过将不同的安全任务并行穿插，比如说TSC开发和硬件FMEDA同步进行、SSR开发和软件编码同步进行等方式。但总的来说效果并不明显，因为项目周期实在是太短了，而“V”模型又很死板，在这个框架内能够做出的调整非常有限。所以笔者认为，必须采用一种快速的、灵活的开发模式，才有可能适应项目的交付要求。

3.3 实施建议

“物竞天择，适者生存”。今天连丰田、大众这样的传统汽车巨头都已经开始转型，时代真的变了。作为一名功能安全的学习者、思考者、实践者，笔者认为传统的功能安全开发方式已经不太适应新的市场环境，需要做出调整。而且随着互联网、IT等科技企业不断涌入汽车行业，笔者有一种强烈的预感：敏捷开发将逐渐成为汽车软件开发的主流方式，也将逐渐成为功能安全软件开发的主流方式。通过敏捷开发，功能安全（主要是软件）可以做到快速交付。这是一个很有意思的话题，有机会再与大家展开讨论。

3.4 导入功能安全的成本到底有多高

前面我们讨论了交付周期，其实严格来说，交付周期也是成本的一种——时间成本。只不过在当前的市场环境下，交付周期的问题特别突出，所以有必要单独进行讨论。

降低成本的重要性无需多言，不管是哪个行业、哪家公司，降本增效都是永恒的课题。但是汽车行业又有其特殊性——汽车是一个规模效益的产业，所以对汽车企业来说，销量非常关键。销量越大，均摊的成本就越低。而成本越低，在产品营销上就越有优势，销量就越能继续扩大。这是一个相互促进的过程。所以对于汽车产业而言，降低成本显得更为迫切。

接触过功能安全的人都知道，功能安全的导入会给企业增加不少成本，包括：

硬件成本

高ASIL等级的安全功能常常需要增加冗余，也就是增加硬件组件
核心芯片往往都需要经过功能安全认证，而且往往不止一个芯片
硬件失效率不达标，需要更换可靠性更高/失效率更低的电子元器件
硬件FMEDA及故障注入测试需要投入大量的时间精力，而且常常要反复好几轮……

软件成本

需要开发新的软件（承担安全功能）
软件分区等措施的引入可能对原有软件架构影响很大，需要大改
软件白盒测试的覆盖率指标要求很高，达不到的话需要返工
增加很多安全机制有可能造成软件不稳定，需要大量时间来调试、修改、验证……

工具链成本

需求管理工具；
安全分析工具；
软件开发工具；
软件测试工具……

管理成本

流程体系建立需要投入人力；
项目安全管理需要投入人力；
功能安全审计需要投入人力；
功能安全评估（如有）需要投入人力……

这一系列折算下来，保守估计也得上千万。而且这还主要是设计研发环节的统计，并没有包括产品的全生命周期。导入功能安全会引起成本上升这很正常，但如果增加的太多，很容易让人望而却步。尤其对于很多中小企业来说，可能基本的流程体系都还不健全，现金流压力也比较大。在这种情况下想要实施功能安全，往往需要面临更大的挑战。

当然，对于上述这些成本，我们也应该辩证的来看：

硬件BOM成本随着出货量增大而降低，而且现在芯片厂家提供的芯片很多都是经过功能安全认证的，不做功能安全反而没有“物尽其用”
软件在首次开发时会遇到很多困难，但是只要成熟、稳定之后，就可以作为平台软件长期复用，尤其是基础软件模块，非常典型
很多工具软件并不是实施功能安全才要求的，比如需求管理工具、软件测试工具等，只不过之前一直没有，所以在导入功能安全时暴露了当前存在的问题
功能安全流程涉及的管理职责，可以由现有的角色比如项目经理、质量工程师等兼任，大家各自负责一部分，这样每个人增加的工作量就比较容易让人接受

这么看下来的话，导入功能安全的成本其实也没有那么高了，对吧？所以，很多企业实施功能安全的成本特别高昂，很大程度上是因为第一次搞，而且在搞功能安全之前的研发流程、软件工具等基础设施并不完善。基础差、底子薄，却要一下子来个“三级跳”，感觉吃不消其实很正常。

所以笔者认为，企业首先需要真正做到ISO 26262标准里要求的QM，然后在这个基础上再导入功能安全，这是最理想的情况。在这种从QM到ASIL的发展模式下，增加的成本仍然会有，但绝不会像现在这样让人难以接受。

罗马不是一天建成的，基础设施的建设也需要持续投入，在此我们也就不再过多讨论了。作为一名功能安全工程师，我们首先要做的、并且肯定能做的就是在项目实施的过程中，想方设法用最低的成本来实现功能安全的要求。把功能安全做出来没有什么了不起的，我们的目标是要用最低的成本做出来。如果能做到这一点，那就意味着我们的产品相比同行友商而言，已经有了竞争优势。

3.5 案例分享

给大家分享一个笔者在实际项目中遇到的案例。要实现ASIL C的电流采样功能，我们可以使用两个Hall传感器来进行冗余比较，但是这样成本太高。然后我们可以使用一个Hall传感器+一个分流器来进行冗余比较，这样能降低成本。接下来我们还可以使用两个分流器来进行冗余比较，进一步降低成本。

然而这样就结束了吗？并不是，实际上我们可以采用一个分流器来实现ASIL C的电流采样功能。安全目标没有变，但我们的设计成本在不断降低。

3.6 实施建议

我们的目标是用最低的成本实现功能安全的要求。要做到这一点，我们必须密切关注行业发展动向，因为整个行业都在追求降本，更低成本的方案/设计/芯片在不断的面世。如果有一种物美价廉的新技术，同时又能满足我们的需求，我们为什么不采用呢？另一方面，我们需要对功能安全深入理解，达到灵活运用的水平。这样的话，当新的技术方案摆在你面前的时候，你才能够判断出它是否可以满足功能安全的要求。这一点将在“理论与实践”部分再与大家详细讨论。

理论与实践

4.1 你真的理解ISO 26262吗

其实严格来说，“理论与实践”应该放到最前面来讲。因为不管是“融合与平衡”，还是“周期与成本”，都会涉及到“理论与实践”的问题，这一点我们在前面的讨论中已经提到过。只不过“理论与实践”的问题没有那么显式，或者说它往往是某些现象背后的根本原因，所以不太容易被察觉到。在遇到一些实际的项目问题后，再来讨论“理论与实践”的问题，可能更容易引起大家的共鸣。

功能安全工程师在项目过程中常常会被问到这样的问题：

这样设计符不符合功能安全？
这个方案有什么问题？为什么不行？
要怎么修改？到底要怎么做？
……

很多时候大家都会回答“ISO 26262标准就是这么要求的”。这种回答没有错，但如果你只会这么回答，那么很可能你的项目会以失败而告终。言必谈标准，说明你只会教条主义、生搬硬套。试问有哪个项目是100%符合标准的呢？遇到那些不符合的部分，又该如何处理？

ISO26262标准在Scope里面说自己是一个框架，同时包含了流程和技术两方面的内容。既然是框架，那么当它落实到某个具体产品、具体项目时，肯定是有灵活性的。也就是说，标准是一样的，但执行起来会有不同。同样的要求可以有不同的解决方案，而且不同的解决方案之间往往也不存在谁对谁错，有的只是谁更合理、谁更合适。只有达到灵活运用的水平，才能从容面对各种不同的项目场景，功能安全才能落地，这也是功能安全的精髓——方法论的价值所在。

尽管ISO 26262标准比较抽象，但它仍然是实施功能安全所围绕的核心。毕竟我们评价一个产品是否满足功能安全的要求，都是通过其是否符合ISO 26262标准的要求来判定的。换句话说，灵活运用功能安全其实就是灵活运用ISO 26262标准，而灵活运用标准的前提在于深刻理解标准。大家不要小看“理解”这两个字，不同的人对于标准的理解很可能是不一样的，甚至差别很大。下面举几个实例进行说明：

4.2 实例1

举个例子，ISO 26262表格里的技术和方法，两个“+”号的一般都是要实施的，这一点应该没有什么异议。那一个“+”号的呢？从标准里的解释来看，一个“+”号对功能安全也是有益的，否则不会“recommend”。

当技术和方法可选时，优先选择两个“+”号，对一个“+”号如何处理没有明说，但显然不会是反对或禁止，肯定是可以考虑使用的。

所以如果存在两个“+”号无法满足的情况时，是不是可以用一个“+”号来替代呢？以下表为例，ASILB的开发目标，如果1i无法满足（对于基于SEOOC模式开发的产品来说有可能是现实存在的情况），我们是直接略过？还是选择用一个“+”号的技术和方法来替代？如果选择的话，又选择哪个？或者只选择一个并不算充分，需要再增加更多？仅从技术层面考虑，在这种情况下补充使用更多的技术和方法（哪怕是一个“+”号），对功能安全肯定是有益的，当然这会涉及到成本。

4.3 实例2

再举个例子，如果某个ASIL对应的要求是在括号（）里，那么其实它只是一个建议，而不是要求。

所以对于ASIL A和ASIL B来说，诊断潜伏故障的安全机制并不是强制要求，只是建议。

同样，对于ASIL B来说，计算SPFM、LFM也不是强制要求，只是建议。

4.4 实例3

再举个例子，PMHF大家应该都比较熟悉了。不同ASIL等级的安全目标，对应的PMHF值有不同的要求。

但是如何理解这个PMHF值呢？如果没有达到上表中的指标要求，我们是不是必须反过头来修改设计呢？我们看看标准里是怎么说的：

看到了吗？首先，表6只是PMHF目标值的来源之一。其次，计算PMHF不是为了必须达到某个值（不管这个值是引用表6还是其它来源），而是为了与既有产品进行比较。

以上这三个例子都是从标准本身的要求来展开分析的，是不是和大家通常的理解或者做法不完全一样呢？大家对标准里明文规定的内容都有不一样的认识，更何况是隐藏在背后的逻辑？下面我们再来看一个例子。

4.5 实例4

如下表所示，按理说ASIL等级越高，要求就越严格。所以“++”的数量排序应该是：ASIL D >= ASIL C >=ASIL B >= ASIL A。但这个表里ASIL B有两个“++”，而ASIL C只有一个。这是不是很奇怪？

笔者和一些同行讨论过这个问题，很多人都认为是标准写错了。但笔者经过仔细思考和分析，最终得出的结论并不是标准有误，而是我们没理解到位。这个问题很有意思，有机会和大家单独讨论。

一千个人眼中有一千个哈姆雷特。由于每个人的教育背景、项目经验、知识结构都不完全一样，所以每个人对ISO 26262标准的理解也不完全一样。在学习功能安全时，别人怎么理解并不重要，重要的是你必须形成自己的理解，并且能够逻辑自洽，这才是我们能否做到灵活运用的关键。否则的话，一旦项目情况发生变化，你怎么可能做到灵活处理、随机应变呢？所以在学习功能安全时，一定要多思考、多揣摩，争取做到深刻理解。

笔者认为，对ISO 26262标准的理解可以分为由浅入深的三个层面：

What（第一层面）：标准里描述的要求是什么？那些专业名词术语是什么含义？硬件失效率公式怎么计算？……
Why（第二层面）：标准为什么提出这样的要求？背后的原因是什么？这个要求和其它章节的哪些要求是相关的？……
How（第三层面）：怎么做才能满足标准的要求？如果做不到或者做不了，有没有替代方案？如果就是无法满足，有什么影响？……

很多人追求“短平快”，上来就想学会 “How”，然后直接上手。这种心情可以体谅，但如果不能真正理解“What”和“Why”，又怎么可能真正理解“How”呢？一味追求“How”的人，做项目只能是生搬硬套，照猫画虎。一旦出现以下情况：

增加了新功能或原有功能出现调整
采用新的技术方案
使用场景发生变化
……

也就是说，只要出现了新情况、知识库里没有对应的“How”可以模仿，那些未能真正理解“What”和“Why”的人，一下子就会懵逼，不知道该怎么办才好。“How”的精髓，不仅在于如何做才能符合标准要求，更加在于当出现不符合的情况时如何判断：是让步接受？是带条件通过？还是返工重来？没有“What”和“Why”的支撑，“How”是走不到这一步的。

4.5 案例分享

给大家分享一个笔者在实际项目中遇到的案例。某既有软件导入功能安全后，需要实施的功能包括：ASIL C（60%）、ASIL A（20%）和QM（20%），但该软件的整体规模并不大。常规的做法肯定是进行软件分区，避免不同ASIL等级的软件相互干扰。但由于该软件在前期开发时没有导入功能安全，不同ASIL等级的软件在设计时相互交织，要实施软件分区的话对软件架构影响很大，很可能需要推倒重来。基于当前的现状，笔者提出了第二种解决方案：对现有软件进行白盒测试摸底，如果测试覆盖率指标还不错的话，考虑将软件整体按ASIL C来走一轮。这种做法可能并不常见，但它同样符合功能安全的要求，没有任何问题。

4.6 实施建议

功能安全的精髓在于灵活运用，而灵活运用的前提在于深刻理解。那么，到底应该如何努力来提升对ISO 26262标准的理解呢？笔者根据自身的学习经历，在这里给大家提几点建议：

1. 改变非黑即白的观念

很多工程师都有一个通病：喜欢证明自己是对的、别人是错的。但是有意思的是，功能安全在很多时候并没有对错之分。因为功能安全是一套方法论，方法论是用来解决问题的，而针对一个具体问题的解决方案往往不止一种。既然都可以称得上解决方案，那么大体上都能满足功能安全的要求。也就是说，功能安全的实现方式常常是灵活的。

举几个例子：

问：实现ASIL C的采样功能一定要两路传感器冗余吗？
答：不一定。笔者在前期文章的案例分享里已经有过论述。
问：不同ASIL等级的软件共存一定要采用软件分区吗？
答：不一定。本期文章的案例分享就是一个典型。
问：实现功能安全一定要采用EGAS三层架构吗？
答：不一定。EGAS三层架构只是一种典型的实现方式，常用的安全架构还包括1oo2、2oo2、2oo3等。

看到了吗？在很多时候，功能安全不是一定要这样、或者必须要那样的。不同的实现方式没有谁对谁错，只有谁更合适、谁更合理。“汝果欲学诗，功夫在诗外”。当面对不同的解决方案时，我们除了确认其是否可以满足功能安全的要求之外，还应该从更高的层面来进行分析：

哪种方案对既有功能、设计的改动最小？（融合）
哪种方案与既有策略的矛盾、冲突最小？（平衡）
哪种方案技术难度最小、实现起来最快？（周期）
哪种方案的设计、生产、维护成本最低？（成本）

在每一个实际项目中，我们都需要具体问题具体分析，从“诗外”的这些维度，仔细评估、综合考虑，最终选择最合适的、最合理的解决方案。能不能做到这一点，某种程度上可以反映你是否达到了灵活运用的水平。

2. 广泛深入的阅读资料

在所有的学习资料中，笔者首推ISO 26262标准，因为这是实施功能安全必须围绕的核心。也许很多人都尝试去读过，但由于种种原因没有坚持下来。标准很抽象，读起来确实也很枯燥，但笔者仍然强烈建议所有的功能安全从业人员反复阅读ISO 26262标准，而且要一边阅读一边思考，不断加深理解。有句话叫做“读书百遍，其义自见”，标准永远是常读常新的，每次读下来都会有新的收获，这一点笔者深有体会。

除了标准之外，还有很多相关的书籍、论文，都可以从里面汲取营养。目前来看，基本上都是英文资料居多，阅读起来没有那么轻松，但是看多了也就习惯了。笔者也阅读过不少相关书籍，有机会的话给大家做一个推荐

3. 大量有效的项目实践

“操千曲而后晓声，观千剑而后识器”。项目实践对于掌握理论的重要性无需多言。不管是学什么，只有学以致用，才能做到知行合一。在这里笔者想着重强调一下项目实践过程中的关键点，否则如果只是为了做项目而做项目的话，就算做再多的项目也只是重复劳动而已，没法快速有效的提升水平。

实际上，功能安全工程师要想真正的把功能安全融合到产品里面去，必须从三个方面同时入手：功能安全原理、产品领域知识和嵌入式软硬件技术，这三者缺一不可。从功能安全原理出发，产品领域知识决定了你的高度，而嵌入式软硬件技术决定了你的深度。功能安全是产品的一部分，你必须从更高的层面、也就是从产品角度来看待功能安全。而每当和软件工程师、硬件工程师讨论实施细节的时候，你的嵌入式软硬件技术功底有多深，你就能和他们讨论到多深。功能安全是通过嵌入式软硬件技术来融合到产品中的，所以我们不难理解，对一个企业来说，嵌入式软硬件研发水平越高，功能安全越容易落地。