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

导读：

本文由汽车电子与软件授权发布，作者为刘钊江。

如果说实践是检验真理的唯一标准，那么量产是检验功能安全落地的唯一标准。基于此，笔者根据以往的项目经验，总结了现阶段功能安全量产落地的三大主要困难，取名为“三座大山”。这“三座大山”是融合与平衡、周期与成本、理论与实践。笔者将详细描述这“三座大山”，希望能抛砖引玉，促进国内同行之间的交流讨论，为功能安全在国内推广普及贡献一丝力量。

1 序言

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

经过17、18、19三年，国内各大主机厂和零部件供应商基本上都试着进行了功能安全的引进和导入。即便没有完整的走完一轮，但起码都或多或少的试过水。

然而到了2020年，能够真正实现功能安全量产落地的国内企业却寥寥无几。

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

• “太虚了。”

• “流程太复杂，做起来很麻烦。”

• “项目太紧，没有资源去做。”

• “技术指标要求太高，做不到。”

• “动不动就进安全状态，车没法开了。”

• ……

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

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

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

• 基于流程驱动，包括需求开发、架构设计、详细设计、实现、集成、测试验证、确认等环节，在每个环节都有相应的技术要求；

• 覆盖产品的全生命周期，包括策划、概念、设计、验证、生产、运行一直到报废；

• 覆盖电子电气的各个方面，包括传感器、处理器、执行器、硬件电路、基础软件、应用软件、芯片、软件工具等；

• 覆盖影响上述内容的支持过程，包括项目管理、安全管理、需求管理、配置管理、变更管理、生产管理、售后服务管理等。

可以看到，功能安全是一个系统的、完整的体系，内部逻辑非常严谨，环环相扣。

对其中任何一个部分进行调整，都有可能造成整体性逻辑链条的损害或缺失。

任何局部的改动，都必须从整体上来考虑，否则就有可能形成逻辑上的漏洞。

想想也是，ISO 26262标准从2005年开始制定，在6年后、也就是2011年发布了第一版，又在7年后、也就是2018年发布了第二版，它已经很成熟了。

所以，要想让ISO 26262标准适配国内企业的实际情况，需要国内整个行业的共同努力，大家一起学习、讨论、提炼、调整、完善，才有可能让ISO 26262真正在国内落地生根。

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

• 融合与平衡

• 周期与成本

• 理论与实践

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

2 融合与平衡

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.6 实施建议

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

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

3 周期与成本

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 实施建议

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

原文连接：

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