智能汽车软件功能安全的“夹缝生长”

纵观汽车行业的发展，一百多年前当第一台汽车诞生时，主要通过机械化硬件实现功能。在这一百多年间，汽车逐步向电子化发展，一辆汽车由至少上百个软硬一体的电子控制单元协同构成。当下随着自动化技术、智能化技术的发展，智能汽车中软件开始占据主导地位，整车电子电气架构也由分布式向集中式演变，并且汽车功能越来越丰富，所以部署在硬件系统中软件规模开始变得越来越庞大，在这种背景下，智能汽车软件在向着基础平台化软件加应用软件分层解耦的方式发展，从而需要：

软件架构要有强大的兼容性和可扩展性，接口要标准化；

软件内部分层化、模块化、解耦化；

提高软件开发效率，适当使用优秀的开源代码；

强大的工具链支撑；

高安全性和高可靠性。

随着AI技术的发展，大模型时代拐点到来，世界万物格局都可能发生变化，产生新的范式，未来智能汽车软件也可能会产生更多颠覆性的变革，例如：AI技术可能替代软件工程师编写代码；现在智能汽车软件生态圈将会变成AI为核心的AI生态圈；当下使用感知和规控等小模型的算法实现自动驾驶的方案可能变为通用人工智能大模型在自动驾驶领域开展应用；针对目前场景复杂、人工智能算法不可解释性问题，在未来可能通过AI来进行场景泛化、用AI来解释AI、以及更多意想不到的变化。

随着智能汽车软件的发展趋势变化，软件功能安全也在发生着改变，在传统汽车时代，功能安全就是围绕ISO26262标准的内容开展即可，而在智能汽车时代，不仅需要功能安全，也需要考虑预期功能安全，预期功能安全其实就是在弥补功能安全之前定义的局限性，我们可以将二者统称为“功能型安全”。在未来，可能还要关注人工智能模型的安全性，我们统称为“复合型安全”，所以随着软件发展，广义的功能安全需要与时俱进。

每一个功能安全从业者可能会深有体会，当下汽车领域的功能安全就像身处夹缝之中，很难尽情发展。以下三句话可以概括这种夹缝困局：

说起来重要、做起来次要、忙起来不要；

对外重要、对内次要、实际不要；

宣传重要、实践次要、花钱不要。

并且有很多客观或主观的因素导致夹缝困局：

基于ISO26262标准的传统功能安全对一些新技术存在局限性，并且默守陈规、按部就班的方式无法适应快速发展的智能汽车软件；

基于ISO21448的预期功能安全活动还没有形成行业最佳实践，还需要经历时间的考验，对于未知场景是无穷尽的探索；

以ChatGPT通用人工智能技术的发展对社会、科技带来新格局、新范式，功能安全也可能需要一些新的思考；

当下汽车行业整体环境安全文化、安全意识不足，大家对功能安全的认知存在偏差；

在没有强制性法律法规要求的情况下，智能汽车行业面临成本、效率与安全冲突时，往往会舍弃安全；

安全这件事，做的好无人知晓，做的不好人尽皆知，并需要背锅。

如果想在夹缝中生存、成长，那就向自然界取经，学习小草的精神，要有较强的适应能力，突破能力和坚忍不拔的精神。

适应能力可以对应功能安全流程建设，智能汽车软件领域的环境背景复杂，多技术融合、多生态协作、人员缺乏安全意识；所以流程体系需要适应这些情况，适当弹性灵活，建立融合型软件研发体系，既有原则也有灵活性。

突破能力对应功能安全技术，面对新技术，在功能安全方面需要突破与创新：

首先识别痛点：认识智能汽车软件的复杂性、不确定性；

然后创新思维：不拘泥于标准，技术方法勇于创新，但有底线、不盲目；

最后突破壁垒：突破传统约束，建立新规则、新方法、新标准。

小草的坚忍不拔的精神适用于功能安全从业者，需要乐观积极面对：

首先坚定态度：对安全永远要抱有敬畏之心；

积极向上突破：顶住压力说服领导重视安全，创建自上而下安全文化；

积极向下蔓延：传播安全理念，督导全员遵循流程重视安全开发细节。

对抗夹缝困局，需要有文化、体系等基础支撑，所以构建新型智能软件研发体系至关重要。智能汽车领域既要求汽车行业的规范性，也要求高科技行业的高效性，所以在构建软件研发体系时需要借鉴传统汽车行业和ICT行业特点：传统汽车行业讲究元器件的车规级要求、注重过程符合性、研发过程遵循整车开发流程和软件开发V模型；ICT行业讲究冗余可靠设计、注重过程高效性、研发过程遵循顶层架构-功能-设计-测试的阶段性流程。

在模式上，ICT行业主要采用围绕产品进行设计开发与集成验证的开发模式，技术融合性强、应用可以灵活衍生；支持需求快速迭代，面向服务的架构可灵活扩展，采用冗余设计使得可靠性较高；利用自动化测试能够快速提高效率。而传统车企的模式只负责整体集成，供应商负责模块或系统的完整开发。在智能汽车软件变革和ICT模式的影响驱动下，车企和供应商的模式及分工将有所变化，OEM不仅做整体硬件集成，还要负责软件集成，需要关注软件架构，侧重应用软件开发，让技术变得更加自主可控。而供应商则侧重平台化技术，统一架构，统一接口，能够灵活扩展，需要支持各种应用快速开发；并且应能够快速响应客户需求变化，使得产品不断迭代改进。

此外，在研发体系构建过程中，需要深入理解现有的成熟体系要求：

ASPICE体系特点：以软件质量为核心的一套方法论；关注过程，侧重双向追溯一致性，流程-计划-实际执行的一致性。

功能安全体系特点：以失效的危害分析与防护为核心的一套方法论；关注过程与技术，侧重故障检测和故障处理的有效性；

SOTIF体系特点：围绕将未知转化为已知，将不安全转化为安全的一套方法论；关注触发条件，侧重已知场景的验证和未知场景的验证；

敏捷特点：以需求快速迭代发布为核心的体系；个体和互动高于流程和工具；工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。

Devops特点：开发、技术运维和质量保障这三方面融合，促进相互之间的沟通、协作与整合；通过协作提高产品开发、测试、发布效率。

在深入理解的基础上，结合智能汽车软件特点，将这些体系进行深度融合，建立一种新型高效的软件研发体系，以ASPICE为基础，增加功能安全和预期功能安全的要求，在设计阶段进行充分的安全分析，在测试阶段进行全面的故障插入测试和触发条件验证，并融入ICT的CICD流程和自动化测试流程，借鉴敏捷思想，不断进行需求迭代，并且需要完善工具链，确保每个流程环节在工具链的支撑下，能够达到事半功倍的效果。

有了最基本的体系保障之后，智能汽车软件还需要面对技术上的痛点，找到相应的解决方案。

在产品形态及开发模式上，对比传统电控功能的ECU开发，ECU开发的痛点为开发单一电控功能，周期较长；软件中没有OS或只有简单的OS；一般采用汇编或C语言，开发效率低，学习成本高。而传统ECU开发通过MATLAB/simulink工具来实现图形化开发即可解决上述痛点。智能汽车软件同理，针对其软件架构复杂，复用性和移植性差、标准化的框架和模块匮乏、全代码开发缺乏便捷易用的开发工具，学习和迁移成本高，人才培养难度大等痛点，需要采用计算基础平台加图形化开发工具来解决这一问题。

在功能安全技术层面上，智能汽车软件面临四大痛点及解决方案如下：

基于以上这些思考和探索，下面进行智能汽车软件功能安全方面“夹缝生长”的实践经验分享，要想在夹缝中生长，首先需要挖掘“夹缝困局”的本质，针对性的制定“生长策略”。

夹缝困局的本质问题在于：

一、智能汽车软件功能安全实现难度大；

二、功能安全成果难以量化体现，无法短期见效；

三、对安全的重视度不高。

针对第一条，采取挖掘本质、循序渐进策略：从第一性原理解决功能安全技术难题；从0-1的过程可以分为从0到0.1再到0.5最后到1，例如在单元测试MCDC覆盖率的要求上，如果开始直接要求100%，那么可能根本做不到，并且研发人员会慢慢丧失信心，所以可以从一个及格线开始，不断提高要求，最终满足真正的需求。

针对第二条，采取认证推动、从点到线再到面的落实策略：认证能够带来成就感和凝聚力，鼓舞团队士气，通过在功能安全项目中，先努力带动一小部分人提高安全认识和功能安全能力，再用星星之火燎原。

针对第三条，采用换位思考、综合成本计算的策略：站在别人的角度考虑问题才能说服别人，功能安全从业者需要站在老板的角度考虑问题，找到切入点；并在功能安全这件事上，不能光看短期利益，而要综合产品质量、社会责任、品牌价值、企业发展综合计算成本，做企业不能有侥幸赌徒心理，需要敬畏安全，在研发阶段就投入功能安全要比量产后补救成本低的多，智能汽车时代，进入全自动驾驶后一旦发生安全事故，可能对有些企业就面临致命的打击。

虽然当下功能安全还不是强制性要求，但是一定要提前布局，才无后顾之忧。对于我们这种负责智能汽车平台软件开发的企业，夹缝困局更加艰难，由于是平台化基础软件，没有特定具体软件安全需求输入，并且需要为所有应用提供基础安全保障，所以功能安全，完全要靠我们的安全自驱力。

我们在实践中总结了功能安全实现的四个最佳实践：

注重强大的软件架构设计：软件架构需要分层、解耦、可扩展；

建立融合型软件研发流程体系；、

正向设计加逆向安全分析贯穿全过程；

全面的测试验证是确保安全性的重要保障。

国汽智控作为计算基础平台的定义者和引领者，目的打造融合、蓝海及平台型的计算基础平台产品，高安全，高可靠，可扩展；赋能中国自主品牌车企实现核心产品及技术自主可控；

用计算基础平台加配套开发工具解决智能汽车产品形态和开发模式痛点，如下图所示：

在功能安全方面，我们的总体原则是：

将安全机制尽可能的添加在平台化软件中；

功能软件作为承上启下的一层，是功能安全的重点；

用第一性原理解决智能汽车软件功能安全问题。

功能软件作为计算基础平台及智能驾驶操作系统的核心，功能软件框架提供智能驾驶pipeline的编排，调度及部署。通过 SOA 服务接口，提供环境模型，算法，数据安全服务等自动驾驶基础服务。支持多车型、多传感器数据接入，并提供任务的编排、调度、部署，具有实时、可靠、高性能等的特点，所以我们对其进行了ASIL D功能安全产品认证，提供一系列的安全机制对应用程序及服务进行监控，通过配置，可以为应用程序及服务提供安全保障。对于系统软件，主要包括内核和通信中间件，通信中间件主要通过端到端的保护实现功能安全，而在我们的方案中，在功能软件层对通信等基础功能已进行了功能安全防护，可保障通信中间件相应功能的安全性。对于操作系统内核，重点关注内核的实时性，可采用满足功能安全的内核，但智能汽车领域linux广泛应用，通过对linux进行实时化改进设计，逐步提高功能安全。对于应用软件，与特定项目相关，根据每个项目需要，具体制定应用层面的功能安全防护策略，并且依靠平台软件的安全机制。

在软件功能安全实践中，采用SEooC的开发方式，依次对应用场景、安全目标和系统安全需求进行假设分析，推导出软件安全需求，并做进一步详细分解，对于假设的内容，需要纳入安全手册中供使用方知悉。

具体的功能安全设计是基于独立的安全监控框架，通过异常监测机制和异常处理机制实现。监测机制总结起来主要涵盖三个方面的监测：数据、逻辑和时间。处理机制在平台软件中设置多种方式，可根据应用情况灵活选择。

在预期功能安全方面，实践内容主要在于设计阶段的分析与大量的测试验证，目前主要研究内容包含如下方面：

感知触发条件分析及测试验证；

决策算法评价方法研究及测试验证；

场景库建设；

随机测试及长期路测。

在实践过程中，基于功能设计，开展功能安全分析和预期功能安全分析，并基于场景进行仿真测试和实车测试，同时不断丰富、泛化场景内容，完善场景库、数据库和事故库。当下预期功能安全工作任重而道远，目前的探索是远远不够的，需要行业内共同努力，在安全这件事上，大家永远不是竞争关系，而是协作关系，分享经验，共享数据，共同探索，才有可能总结出最佳实践成果，助力自动驾驶落地实施，为智能汽车的安全性造福。

最后，总结说明一下智能汽车软件开展功能安全和SOTIF的必要性：

责任主体转移，需要系统保证安全；

提升客户认可度和信心；

提高产品竞争力；

社会责任；

能力储备，应对未来强制要求。

同时，也有三句话送给所有智能汽车领域及功能安全领域从业者：

1、有能力的影响一群人，没能力的被一群人影响！

2、对安全永怀敬畏，即使处于夹缝，也要顽强生长！

3、智能汽车安全需要我们每一个具有小草精神的安全从业者的共同努力！

End