前言

这段时间工作太忙，很久没有和大家分享功能安全知识，也正是因为这段时间的忙碌，对智能汽车的功能安全又有了一些新的思考与感悟。上周受邀参加2021国际汽车安全与测试大会，发表了《智能汽车产业的功能安全挑战与创新》主题演讲，周末整理了一下演讲内容，附带PPT，分享给大家。

以下为演讲内容全文：

对于每一个功能安全玩家，功能安全标准都是一件必不可少的装备。众所周知，功能安全标准的母标准是IEC61508，无论是汽车行业的ISO26262还是轨道交通领域的EN系列标准，亦或是工控、核电、医疗等行业的功能安全标准，都是源于母标准，它们就像兄弟姐妹，有着共性的东西，也有着少许特定化差异。但任何的功能安全标准概括起来都不过是三方面的内容：技术要求、流程要求、组织和人员要求。

由于我十年前是从事轨道交通行业的功能安全，在当时的背景下，一般都是在项目中摸爬滚打去积累功能安全经验，然后同步去查阅标准，纠正或升级自己的做法，所以很不解现在汽车行业的一种普遍现象，大多数人先学标准，再做项目，甚至学完标准一直没有做过完整项目。这种方式好处是理论性更强、缺点是先用标准的囚笼把自己框住了，过于追求理论表面的条条框框而无法深度挖掘自我的思想和能动性。

针对汽车行业的ISO26262功能安全标准，总结下来就是一个三V模型，V模型的精髓在于逐层递进与逐层追溯。目前功能安全行业的痛点在于大家认知的差异，需要统一拉齐：

• 功能安全不是paper work，不只是搞文档，文档只是设计与过程的体现形式；

• 功能安全是全生命周期的活动，只在一些阶段考虑了功能安全的产品不能称之为安全；

• 功能安全是全产业链的要求，一个功能串行链上的任何一个设备，一个环节都是功能安全不可或缺的保障；

• 功能安全不只是一种辅助性分析的工作，而是通过正向设计加逆向分析，才能更全面的保障安全；

• 功能安全的流程和技术是同等重要的两个方面，偏科不会取得最终好成绩；

• 我们费尽人力物力财力时间辛辛苦苦去搞功能安全，绝不是为了一张证书！

功能安全的核心就是降低风险，将风险降低到一个可接受的程度。传统的功能安全聚焦失效，主要是因为功能安全的起源时没有想到除了失效，还有那么多不失效的复杂情况也会导致风险。当年正是有那么多工业设备发生失效，才积累了大量的数据和经验，慢慢形成了功能安全理论雏形，然后形成方法论，用来降低失效风险。

所以功能安全依赖数据与经验，致力于降低随机性失效和系统性失效带来的风险；但这种传统的功能安全方法论也有着按部就班的局限性，并且目前逐渐将功能安全评估需求衍生为对认证和证书的追求。

总结起来，目前功能安全就是在“以不变应万变”：

• 安全不够，冗余来凑；

• 冗余不够，多样化来凑；

• 多样化不够，诊断来凑；

• 诊断不够，流程来凑；

• 以上都不够，推给SOTIF。

而SOTIF不应该和功能安全划清边界，它本身就是功能安全曾经遗失的一部分而已，现在发现遗失，找回来了，应该构成一个整体完整体系，而不应该分道扬镳。

对应功能安全的“以不变应万变”，智能汽车产业却在发生在颠覆性变革。随着软件定义汽车时代的到来，汽车逐渐演变成一部会跑的手机，汽车的产品架构演变为由硬件、操作系统OS和应用软件构成，其中，硬件和操作系统OS组成智能计算基础平台，在智能计算基础平台的基础上可以快速灵活开发各种应用软件，实现复杂功能。伴随网联云控的发展，由单车智能逐渐向多车智能转变，车路云协同计算应运而生，这些新技术新领域让汽车产品形态发生了翻天覆地的变化。

传统汽车电子电气架构也随之在发生变革，由传统汽车上百个分布式ECU架构演变成集中的域控制器架构，未来又在逐步转变为中心化控制架构，车的功能变为在云端实现。这些转变带来的是越来越复杂的软件架构，越来越庞大的代码量，对于功能安全构成前所未有的挑战。

并且智能汽车功能安全绕不开的话题是人工智能的不确定性，这种不确定性主要分为模型的模糊性和数据的不确定性，模型的不确定性例如神经网络的错误率，数据的不确定性例如训练数据的不完整性，分布偏差以及与实际环境的差异。在人工智能算法的应用下，一些数据噪声就足以让识别结果产生巨大的差异，所以这些难题在如今传统功能安全的定义中都找不到答案。

总结起来就是功能安全就像一个垂暮老人，以一种保守的姿态缓慢前行，而智能汽车产业就像一个朝气蓬勃的少年，在奋尽全力的奔跑，所以功能安全目前追不上智能汽车的步伐。

从事智能汽车功能安全领域的人是否有这样的感受，在工作时会有一点力不从心，我们按照功能安全要求完成各项活动，可是我们依然感觉不够充实，就像用花拳绣脚在捶打一个壮汉的感觉，费尽周折又无济于事。

智能汽车产业的功能安全急需突破与创新，默守陈规无法真正解决安全问题。

这张图是我们和中国软件测评中心以及多家企业共同编写发布的车载智能计算平台参考架构1.0，从参考架构可以看出车载智能计算基础平台分为异构分布硬件和自动驾驶操作系统软件，自动驾驶操作系统软件又分为系统软件和功能软件。以我们的产品实践为例，我们国汽智控的核心产品智能汽车基础脑IVBB就是以这个参考架构为基础，具有跨车型、跨平台、统一OS、应用定制、弹性可扩展、全生态支撑等特点，我们的产品形态是在此架构基础上形成ICT数字底座加SDK方式，由硬件平台、系统软件、功能软件的平台抽象层、功能软件通用框架和智能驾驶通用模型构成数字底座，由SDK为快速开发应用提供接口。

这是一个庞大的平台系统，其中有算法内容和linux内容，如果严格遵照传统功能安全的刻板要求，这两部分是要极力规避的，但是去除了这两部分，我们的智能汽车时代变更还有意义吗？所以面对问题，首先不应该是逃避，而是应该去思考解决办法。

智能汽车处在快速变革期，产品面临的时间、功能、质量三方面的权衡，三者平衡产品才有保障，与传统汽车产业相比，在智能汽车产业研发过程中，我们不仅要关注产品本身，还要关注应用场景，不同的场景下可能产生完全不同的决策控制，更要关注性能、仿真测试、实车测试，随着车路云发展，还要关注信息安全体系建设。

总结起来，智能汽车产业功能安全急需的突破点：

• 突破软件规模，实现大规模复杂软件的安全保障；

• 突破功能安全的确定性要求，保障算法不确定性下的安全性；

• 突破传统实时操作系统约束，研讨Linux的安全性；

• 突破传统功能安全失效思维，采用系统工程的思维方式；

• 突破功能安全边界，与机械安全、信息安全组成“复合型安全”体系；

• 突破欧洲标准的局限性，建立中国自主智能汽车功能安全标准；

• 突破以证书为导向的模式，关注智能汽车真正安全性。

那么如何突破呢？我今天抛砖引玉，先分享一下个人的思考，也希望业界同仁们后续可以一起深入探讨：

对于大规模复杂软件及系统，首先要“分清主次”，对于关键功能进行强制化安全要求，并设置安全保底功能；开发流程上不仅要规范还要高效，精简流程，但重要流程环节不能少；测试永远是软件把关的有力防线，并且要从实车测试中不断总结积累安全设计经验；要建立问题库、场景库、数据库，数据驱动才能真正保障大规模软件、算法及系统安全。

对于算法安全性保障，核心要进行精细化开发，精细化具体表现在：流程同软件一样，应建立规范的开发流程降低系统性失效风险，并且在设计上要提高算法的可解释性设计、增加对抗性训练，提高标注精度，建立全面的评价体系，同样需要数据驱动，建立数据库，场景库，增加训练集，测试集；另外，也可以考虑在输入输出端增加故障安全模式。

对于Linux的安全性，目前行业内也有一些联盟在集中研究，希望通过规范的开发流程降低其风险，将其满足ASIL B的安全目标。我个人的观点是ALARP原则，在linux通往功能安全的路上要考虑性价比，细分Linux内部功能及模块，如果某个功能转化为功能安全的代价高于所获得的收益，那么就可以接受这个风险。

对于功能安全的思维方式，建立一种全局观，基于系统工程的思维去分析，不光聚焦失效分析，也包括需求分析，过程分析。

对于安全，我想提出一个“复合型安全”的概念，弱化功能安全、SOTIF、信息安全、机械安全等边界，真正关注安全本身，在系统中进行一体化兼顾分析，并建立融合体系，并且不光关注安全性，也同时关注可靠性、可用性、可维护性等多重方面。

最重要的是智能汽车产业应加快推动中国标准落地，在功能安全的中国标准建立过程中，我们要采取借鉴而不盲从的态度，积累中国化数据信息，基于中国智能汽车特点及应用实例经验去创建自己的标准。

最后，在智能汽车功能安全领域，我们应该从关注证书的应试教育转为关注安全的素质教育，这需要的是建立一种真正的安全文化，加强组织内部的安全认可、审核、验证、确认和评估。

那么总结一下，安全三角形需要哪些元素才能维持稳定，必不可少的是海量数据、安全分析与测试，这些积累需要全行业的努力。

对于智能汽车产业的功能安全发展之路，我想今天在这里可以倡导一下，没有超人可以完成一切，需要的是全产业联盟，共同探索创新，共建生态共赢，共享数据、共享经验、共享case，只有大家携手共同努力，创建智能汽车中国标准，才能真正突破一切卡脖子问题，真正实现汽车强国。

演讲PPT：

--- END ---