一、概念阶段

1. 相关项定义及要素划分

相关项是实现车辆层面或部分功能的系统或者系统组。相关项定义并描述系统或系统组，以及其与环境、其他相关项之间的依赖关系和交互影响，为充分理解相关项提供支持，以便执行后续阶段的活动。车辆层面的相关项定义如图所示，主要包括相关项的功能、系统边界与接口、环境条件和法律要求等。车载智能计算平台的相关要素主要包括传感器接入及管理、AI计算、通用计算、车控、内部通信、V2X、高精度地图数据存储等。

相关项定义

2. 相关项层面的影响分析

车载智能计算平台的开发项目分为新开发、修改或复用，若为修改和复用，则需要进行相关项层面的影响分析。影响分析应识别和指出因相关项的修改、相关项使用条件的修改所带来的影响，可能的修改包括运行场景和运行模式、与环境的接口、安装特性、环境条件等。

高级别自动驾驶相对于辅助驾驶在运行环境感知范围和驾驶任务上会发生变化，例如：

1）设计运行范围对感知要求的变化相对于辅助驾驶系统面临的运行环境条件，高级别自动驾驶系统相对减少对驾驶员的依赖，需要感知的车内外环境范围更广，以确保自车行驶过程中的道路安全。在某些场景和系统设计中，需要对自车周围影响道路安全及自车定位的动态和静态物体感知。

2）动态驾驶任务和人为因素的变化L3及以上的自动驾驶系统相对于辅助驾驶系统容许一定程度的驾驶员不在环。在系统发现预期无法处理或者无法保证动态驾驶任务安全执行等紧急情况时，为使车辆控制权被快速接管并避免危害，驾驶员状态也需要被感知（如监测驾驶员专注度、心率等生理状态）。

3. 危害分析和风险评估

通过危害分析和风险评估确定ASIL等级和安全目标，以避免不合理的风险。为此，根据相关项中潜在的危害事件，对相关项进行评估。安全目标以及分配给它们的ASIL等级是通过对危害事件进行系统性的评估所确定的。

ASIL等级是通过对影响因子严重度、暴露率和可控性的预估所确定的，影响因子的确定基于相关项的功能行为，因而不一定需要知道相关项的设计细节。关键步骤具体包括场景分析及危害识别、危害分级、ASIL等级的确定、安全目标的确定。由于在动态驾驶任务中，L3及以上自动驾驶相对于辅助驾驶，容许一定程度的驾驶员不在环，将会导致对危害的可控性降低，在进行危害分析与风险评估时，可控性或将变为C3，可能会引起功能安全等级需求的提升。

4. 功能安全概念

功能安全概念是从安全目标中导出功能安全要求，并将其分配给相关项的初步架构要素或外部措施。功能安全概念包括安全目标、初步安全架构设计、安全分析、安全要求。

安全架构设计方面，L3自动驾驶系统已经允许驾驶员的手长时间脱离方向盘，无需时刻观察道路状况，从系统出现失效到驾驶员反应并接管控制存在一定时间间隔。在这段时间间隔内，系统要确保车辆的安全性，需要做到某一个单元失效的情况下，车辆能够维持横纵向控制直到驾驶员接管或安全停车，因此需要冗余的架构设计。一般来说，对于整个自动驾驶系统的冗余设计又可以细分为电源冗余、执行机构冗余、传感器冗余、计算平台冗余、用户交互链路冗余等。

从安全目标可以导出安全要求，安全要求继承安全目标的ASIL等级。一个安全要求可以分解为两个或多个子安全要求，分配到独立冗余的安全架构设计中。独立性是ASIL分解的重要要求，即冗余单元之间应避免共因失效和级联失效。

二、系统层面

1. 应用环境

相对于功能安全概念阶段，系统阶段更专注于产品的详细设计，涉及系统工程、安全工程和架构设计等不同技术领域。同时，系统阶段也经常扮演着供应链上、下游功能安全的DIA交互阶段，是功能安全中非常重要且考验技术水平的阶段。

车载智能计算平台，作为自动驾驶的主要部件，其应用环境参考如图：

车载智能计算平台应用环境参考示意图

车载智能计算平台的应用环境主要包含用于环境感知（如摄像头、激光雷达、毫米波雷达、超声波雷达等）和位置定位（如GNSS、高精度地图等）的传感器，整车底盘域、动力域以及车身域的执行器，人机交互的HMI，以及外部互联与通信的T-Box和OBD等。随着自动驾驶等级的不断提高，车载智能计算平台对应用环境中的传感器、执行器、人机接口和外部互联通信有更高的功能要求及功能安全要求。

2. 功能划分

车载智能计算平台按照功能可以分为传感器接入及管理、AI计算、通用计算、通信、存储和车控等。不同的功能依赖不同的系统模块实现。传感器接入与管理单元提供丰富的软硬件接口，使能传感器接入及管理。

AI计算提供深度神经网络算法加速计算能力。通用计算主要是指面向常规算法的计算能力。车载智能计算平台内部通信提供车载智能计算平台内部各个要素之间通信能力。V2X通信提供车载智能计算平台连接车辆外部设备能力。存储功能提供诸如高精度地图存储及服务能力。车控提供车控下发能力，对接车辆执行器。

车载智能计算平台功能单元参考ASIL等级

3. 安全分析

系统安全分析的目的是识别功能或系统设计中存在的违背安全目标的失效（包括单点失效或异常）和相关性失效（如共因失效和级联失效）等。ISO 26262对此提及两种安全分析方法：

1）归纳分析（Inductive analysis）：是一种以自上向下的分析方式，从已知影响结果入手逐步向下分析找到失效原因的方法；

归纳分析方法是针对所有ASIL等级的功能安全开发都强烈推荐使用的方法，具体常用的方法有失效模式与影响分析（FMEA）和事件树分析（ETA）等。

2）演绎分析（Deductive analysis）：是一种以自下而上的分析方式，从已知的失效原因入手推导出影响结果的方法。

演绎分析方法是针对ASIL等级为C/D的功能安全开发所使用的方法，具体常用的方法有故障树分析（FTA）、可靠框图（RBD）、系统理论与过程分析（STPA）等。

另外，安全分析包括定量分析与定性分析，在系统阶段的安全分析用于辅助系统设计，因此，这个阶段定性的安全分析就足够了。在系统阶段的安全分析过程中，除了上面提及的分析方法，还包括危险和可操作性分析（HAZOP）、接口安全分析（ISA）。

4 . 安全策略

自动驾驶功能目前的系统安全策略大体分为两种，即Fail-Safe（失效-安全）以及Fail-Operational（失效-可操作）。Fail-Safe要求系统监控关键的部件以达到失效后系统关断的目的。但是对于L3及以上的功能，驾驶员处于脱眼、脱手的状态，系统的关闭并不能保证可靠地完成驾驶权的转移。

例如，高速公路场景中，车辆紧急停止在本车道是一种潜在的风险状态，很容易发生高速追尾。Fail-Operational安全策略解决了这一问题，即使在主功能系统失效的情况下，仍然有备份系统可以保证车辆进行降级操作，让车辆转移到安全区域。

5. 系统安全设计

系统安全架构，业内常使用的是E-Gas三层监控架构。E-Gas监控概念源于奥迪、宝马、戴姆勒、保时捷、大众等成员一起通过工作组的形式开展的针对复杂车载控制系统的安全监控架构设计指导性文档，涉及系统架构、软件和硬件的设计理念，广泛应用于传统燃油车和新能源汽车监控与诊断设计领域。

E-Gas监控概念的核心是三层安全架构设计。整体设计分为Level1、Level2和Level3，其定义如下：

E-Gas三层安全架构（带锁步核）

Level1：功能层，包括扭矩的解析、功能的诊断等，最直接的理解就是能够实现设计基本功能的软件及相关硬件资源的组合；

Level2：功能监控层，负责监控功能层的输出结论，简单理解来看，就是软件的冗余校验，但是，由于不想消耗太多资源及避免算法共因，所以基于功能结果的监控；

Level3：硬件监控层，负责确保Level1和Level2的运行的硬件环境是正常工作的，异常的运行环境会导致Level2的设计起不到很好效果，因此，Level3在整体的监控架构中作用是不可替代的。

车载智能计算平台的安全策略可以是独立的监控模块或冗余的系统设计。独立的监控模块实时监控功能实现模块的软硬件故障，一旦检测到有安全相关故障，车辆即进入安全状态，如需要可先进入紧急运行模式（Emergency Operation）。例如，功能降级、当前车道停车、安全地点停车等。

冗余的系统设计是指两个或多个功能模块互为备份。例如，车载智能计算平台可以采用“主处理单元+辅处理单元”双处理架构，以确保L3及以上自动驾驶车辆的安全。在该架构下，主处理单元对车辆的运动轨迹进行规划和控制，辅处理单元的作用是监控主处理单元。同时两个单元不断地进行交叉检查，当两个通道在规划轨迹和控制策略存在较大偏差时，系统就会进入降级模式。主处理单元和辅处理单元可以按照ASIL-B设计开发，仲裁模块可以按照ASIL-D设计开发。

在系统阶段进行设计时，需要考虑不同系统单元的故障以及对应的处理策略，具体包括传感器接入能力失效，比如丢帧、乱序等；通用计算能力或AI计算能力失效，比如代码跑飞、执行超时等；内部或V2X通信能力失效，比如超时等；存储失效，比如高精度地图数据损坏等；车控失效，比如非预期发送车控等；电源失效；时钟失效。

6. 技术安全概念

技术安全概念是车载智能计算平台系统设计中安全策略与安全设计的集合。技术安全概念的内容主要包含基于系统架构的功能安全分析，基于上级功能安全要求与功能安全分析导出的技术安全要求，最终集成安全设计的系统架构，以及后续生产过程中需要采取的安全措施。

技术安全要求需要定义具体的安全机制并分配到相应的架构要素中，以确保在下一级的开发过程中，安全机制可以被进一步细化与实施。在车载智能计算平台的开发过程中，技术安全概念可能针对于某一系统或子系统，因而技术安全要求涉及的架构层级可以不止一层。

功能安全概念规定了系统的安全目标，以及系统所需要的安全功能以实现这些安全目标。而技术安全概念则需要实现以下两部分内容：

①进一步细化安全概念提出的安全功能，也就是从做什么转化为怎么做，得出安全功能的实现技术方案；

②分析安全功能的实现路径，找到系统或技术方案中引起安全功能失效的单点故障、潜伏故障和多点故障，并提出安全措施或安全机制来覆盖这些故障。

具体而言，从功能安全需求（FSR，Functional Safety Requirement）/功能安全概念（FSC，Functional Safety Concept）导出到技术安全需求（TSR，Technical Safety Requirement）以及技术安全概念（TSC, Technical Safety Concept）的步骤如下：

步骤1：针对每一条FSR/FSC，详细制订该条FSR/FSC的实现技术方案，也可以理解为FSR/FSC在系统初始架构要素中的功能执行路径，从传感器→控制器→执行器的实现路径；

步骤2：FSR/FSC的实现技术方案为对象，进行FTA或FMEA分析，识别出该实现技术方案中违背该条FSR/FSC的单点故障和双点故障；

步骤3：针对单点故障，设计相应的具体诊断机制或安全措施；

步骤4：针对双点故障，设计相应的避免潜伏故障的诊断机制或安全措施；

步骤5：汇总上述技术实现方案、针对单点的诊断机制和避免潜伏的诊断机制，形成TSR；

步骤6：将导出的TSR分配到具体实现要素如硬件和软件，优化系统架构设计，即TSC；

步骤7：针对较复杂或多层系统，可重复步骤1—6过程进行迭代设计，直至完成整个系统的TSR/TSC开发。

在车载智能计算平台的技术安全要求中，若采取多层次的技术安全要求，其基本原则不变，即技术安全要求要与架构层级相映射并最终被分配到软件与硬件中，以保证软件与硬件的功能安全开发有明确和完整的输入。

7. 测试验证

系统测试内容与方法从软硬件层面、系统层面与整车层面提出了要求，相应的测试内容、测试方法以及ASIL等级要求如表。

系统测试内容与方法列表

车载智能计算平台在功能安全概念阶段开发或假设了上层的安全目标和功能安全要求，安全要求在之后各个阶段被逐渐细化和实现。最终完成硬件层面及软件层面开发和集成的车载智能计算平台能否正确实现安全要求，以及是否存在非预期的功能，需要通过系统层面的集成测试进行验证。系统层面的测试验证，一方面需要确保安全要求能够被正确地使能，另一方面还需要确保车载智能计算平台不会因为安全要求非预期使能而导致系统可用性降低。

制定有序的系统层面测试计划，并进行持续的过程跟踪管理，是保障车载智能计算平台测试验证工作有序可靠进行的必要途径。开发测试团队应重点考虑项目整体时间计划、测试验证的人员安排与责任分工、测试方法、测试环境、测试工具等方面的内容，综合评估和确认之后形成测试计划。

基于SEooC模式开发的车载智能计算平台实际应用到目标车型时，系统集成测试和整车集成测试是发现系统性故障不可或缺的安全活动。在系统集成测试和整车集成测试活动中，需重点验证目标车型的功能安全要求是否得到正确实现，集成真实的传感器和执行器等其他其它要素之后的系统响应是否满足安全机制的要求，车载智能计算平台与目标车型其他要素之间的接口与交互过程是否正确，以及安全要求在外界严苛的环境条件和运行工况下能否正常实现。

8. 系统开发常用工具介绍

依据ISO26262的要求，为实现系统设计满足如图所示的原则，一般可使用半形式化如SysML语言+自然语言实现。行业内用得比较多的、支持系统设计的工具有Medini Analyze、IBM Rhapsody和Enterprise architect等。Medini Analyze与ISO 26262要求更加契合，IBM Rhapsody和Enterprise architect的系统工程建模则更加强大。

系统设计原则

a、Medini Analyze

Medini Analyze是Ansys公司开发的一款支持ISO26262开发活动的工具，它提供一系列绑定在模型化环境中的先进分析方法，包括：

•针对电子电气系统和软件控制功能的安全分析和设计，以及适用于ISO26262、IEC61508、ARP4761和MIL-STD-882E的特定模板；

•将架构/功能设计与质量、可靠性和功能安全分析方法进行集成；

•可支持运行情境分析、危险与风险分析（HARA）、功能性风险评估（FHA）、FTA、FMEA、FMEDA、FMECA概率可靠性分析以及硬件失效指标；

•依照SAEJ1739、VDA质量手册、AIAG等标准进行产品设计及相关流程的质量分析；

•完整的端到端可追溯功能；

•工作成果和文档的定制化生成；

•团队协作支持，包含模型化高级对比和合并技术；

•集成Ansys SCADE Architect、IBM Rational DOORS、IBM Rational Rhapsody、Enterprise Architect、MATLAB/Simulink、State flow、PTC Integrity、Microsoft Office、Tortoise SVN、IBM Rational ClearCase、Jama Software等工具。

Medini Analyze驱动集成安全分析

b、IBM Rhapsody

IBM Rhapsody是IBM公司基于UML/SysML的模型驱动开发集成环境，用于嵌入式和实时系统的系统设计开发工具。Rhapsody的主要功能如下：

• 使用行业标准建模语言：UML、SysML、DoDAF等；

• 支持可视化模型仿真；

• 支持C、C++、Java等语言开发环境，做到模型平台无关性；

•支持常用的嵌入式实时操作系统，如VxWorks、嵌入式Linux、Android、OSEK、QNX等；

• 基于Jazz平台与DOORS、RTC、RQM无缝集成。

c、Enterprise architect

Enterprise architect是Sparx Systems公司的旗舰产品。它覆盖了系统开发的整个周期，除了开发类模型之外，还包括事务进程分析、使用案例需求、动态模型、组件和布局、系统管理、非功能需求、用户界面设计、测试和维护等。该工具特点：

• 高价值、端到端的建模，支持软件和系统工程的完整的建模生命周期；

• 建模、管理和跟踪需求；

• 强大的文档生成能力；

• 源代码的生成和反向工程；

• 先进的模型驱动架构，包括C#、DDL、EJB、Java、Junit、NUnit、WSDL、XSD的建模转化；

• 支持SysML系统工程和仿真；

• 业务流程建模；

• 基于UML2.4.1语言；

• 高效的项目管理；

三、硬件层面

作为车载智能计算平台功能软件与系统软件的载体，硬件的失效可能直接导致功能软件输出不可信任的结果，从而违背安全目标。由于硬件故障在硬件生命周期中发生时间的随机性，在通过改善流程降低系统性失效的同时，ISO 26262功能安全标准在硬件层面重点关注识别安全相关的硬件故障以及采取安全机制诊断相应硬件故障，并发现的硬件故障进行处理（例如进入安全状态），从而将硬件随机失效对安全目标的影响降低到可接受的程度。

1. 硬件架构设计

由于现有关键器件的功能安全能力的局限性与ASIL D系统对单点失效度量的严格要求，硬件冗余是实现高功能安全等级安全目标的常见方式。冗余式硬件架构的主体是通过对冗余计算单元输出结果的相互校验达到提高计算单元硬件故障诊断覆盖率的目的。由于对相互冗余系统的独立性要求，相互冗余的系统需尽可能的避免由同源输入、共用资源、环境影响等因素引起的共因失效。

功能安全在硬件层面，关注硬件器件中的安全相关故障可以通过自检或外部监控的方式被检测到，并在故障容忍时间内实现安全状态。硬件器件实现安全状态的方式多为重启、断电、报错、禁言等，因此单硬件通路的硬件架构可以满足Fail-Safe概念的需求。根据车载智能计算硬件平台所承载功能与功能安全要求分配的不同，AI单元、计算单元与控制单元所选用的芯片可通过单器件或冗余的方式实现相应的功能安全等级。

单硬件通路Fail-Safe抽象硬件架构示例

随着自动驾驶的发展，Fail-Safe的安全策略难以满足高级别自动驾驶的安全要求。基于L3以上自动驾驶功能对系统Fail-Operational的需求，越来越多的车载智能计算平台在主通路实现ASIL C-ASIL D的基础上增加与主通路相互监控的Fail-Operational通路，实现主通路失效情况下硬件层面的失效可操作性，以提高系统的安全性和可用性。需要注意的是，根据自动驾驶功能等级对Fail-Operational系统在主通路失效情况下需要完成的紧急运行模式的不同，Fail-Operational通路所包含的硬件单元可能会有所差异。

多硬件通路Fail-Operational抽象硬件架构示例

诊断覆盖率指的是硬件要素失效率中，由实施的安全机制探测或控制的失效率所占的比例。由该定义直接评估诊断覆盖率，需要基于大量的硬件随机失效事件考察安全机制的有效性，实际操作中很难实现。一般情况下，对诊断覆盖率分为三个等级：Low（60％）、Medium（90％）和High（99％）。基于ISO 26262，提供以下两种较为简单的确定诊断覆盖率的方法。

1.1 基于能够探测的失效模式

一个典型的系统（包含传感器、控制器、执行器）硬件要素如图所示：

常见系统硬件

对于硬件要素来说，其失效模式分布呈一定的统计规律。基于硬件要素的失效模式分布，能够诊断某些失效模式或失效模式的组合，得出相应的诊断覆盖率（DC, Diagnostic Coverage）。针对图5-20所示系统所含硬件要素，低诊断覆盖率（Low DC）、中诊断覆盖率（Medium DC）和高诊断覆盖率（High DC）三种不同的诊断覆盖率与其所需要能够覆盖的失效模式如表。

系统硬件要素失效模式与诊断覆盖率

A、卡滞是一个故障类型,可以描述为要素针脚上持续的“0” “1”或者“打开”。该故障只针对具有要素层针脚接口的要素才是有效的。

B、直流故障模型包含下列失效模式:卡滞故障、卡滞开路、开路或者高阻抗输出,以及信号线间的短路。这里的意图不是一定需要全面的分析,比如要求对于微控制器内或者来自于一个复杂的PCB板上任何理论可能的信号组合的桥接故障进行详尽的分析。分析着重于主要信号或者在布局层面分析中识别出的高度耦合互连。

C、“软错误模型”:软错误(比如位翻转)是由封装衰变的α粒子或者中子等引起的瞬态故障的结果。这些瞬态故障也就是单粒子翻转(SEU)和单粒子瞬态(SET)。

1. 2 基于采用的安全机制

根据对硬件要素采用的安全机制，ISO 26262同样给出了可供参考的诊断覆盖率。例如：针对传感器，若只采用短电源、短地诊断，诊断覆盖率为Low；若采用双冗余传感器做相互校验，诊断覆盖率为high。

ISO 26262 Part5 传感器安全机制与诊断覆盖率

根据能够覆盖的失效模式与根据采用的安全机制评估诊断覆盖率，双方并无本质的不同。上表中安全机制与诊断覆盖率的关联，其背后逻辑依然是安全机制—能够覆盖的失效模式—失效模式分布。

诊断覆盖率的评估方法适用场景

2. 随机失效概率量化指标

根据硬件故障对安全目标产生影响的不同，硬件故障可分为安全相关故障与非安全相关故障，其中安全相关故障又进一步分为单点故障、残余故障、多点可探测故障、多点可感知故障、多点潜伏故障与安全故障。其中，单点故障和残余故障可以直接导致安全目标的违背。

多点潜伏故障虽然不会单独导致安全目标的违背，但可能会在与其它故障同时发生时导致安全目标的违背。

因此用于表示单点故障与残余故障诊断覆盖率的SPFM（Single-Point Fault Metric，单点故障度量），多点潜伏故障诊断覆盖率的LFM（Latent Fault Metric，潜伏故障度量）与PMHF（Probabilistic Metric for random Hardware Failures，随机硬件失效概率度量）是功能安全用于衡量随机硬件失效率是否达到可接受程度的重要衡量指标。

针对于不同的功能安全等级，ISO 26262针对上述指标给出了参考性量化目标。下列数值是广泛应用于业界评估安全系统是否满足相应功能安全等级的重要指标。

硬件随机失效度量参考量化目标

“单点故障度量”和“潜伏故障度量”计算示例，如下图的系统在一个ECU中实现了两个功能。

“单点故障度量”和“潜伏故障度量”计算示例

功能1有一个输入(通过传感器R3测量温度)和一个输出(通过I71控制阀2),功能1的表现是当温度高于90℃时打开阀2。

如果没有电流经过I71,阀2打开。

相关联的安全目标1是“当温度高于100℃时关闭阀2的时间不得长于x ms”。安全目标被分配为ASILB。安全状态是:阀2打开。

微控制器的ADC读取传感器R3的值。R3的电阻值随着温度升高而减小。该输入没有监控。控制T71的输出级由模拟输入InADC1(表中的安全机制SM1)来监控。在这个例子中,假设安全机制SM1能够对T71违背安全目标的某些失效模式的探测提供90%的诊断覆盖率。如果SM1探测到失效,安全状态被激活但是没有点灯。因此,声明针对潜伏故障的诊断覆盖率只有80%(驾驶员将通过功能降级获悉失效)。

功能2有两个输入(通过传感器I1和I2生成脉冲来测量轮速)和一个输出(通过I61控制阀1),功能2的表现是当车速高于90km/h时打开阀1。

如果没有电流经过I61,阀1打开。

相关联的安全目标2是“当速度超过100km/h时阀1的关闭时间不得长于y ms”。安全目标被分配为ASIL C。安全状态为:阀1打开。

微控制器读取I1和I2的脉冲值。通过这些传感器给出的平均值计算轮速。安全机制2(表中的安全机制SM2)比较两个输入。它对每个输入的失效探测达到99%的诊断覆盖率。如果出现不一致,输出1设为0。阀1打开(晶体管电压为“0”则打开栅极。I61电压为“0”则打开阀1)。因此,99%可能导致违背安全目标的故障能被探测到并且进入安全状态。当安全状态被激活时,灯L1点亮。因此,这些故障是100%能被察觉的。剩下的1%的故障是残余故障而不是潜伏故障。

控制T61的输出级被模拟量输入InADC2(表中的安全机制SM3)监控。轮速由该传感器给出的平均值计算得到。

微控制器没有内部冗余。如果不具备关于复杂元器件的安全故障比例的详细信息,可假定安全故障的保守比例为50%,并假定通过内部自检和外部看门狗(表中的安全机制SM4)达到对违背安全目标的总体覆盖率为90%。看门狗通过微控制器的输出0得到喂狗信号。当看门狗不再被刷新,其输出变低。SM4(看门狗和微控制器自检)提供的故障探测把这两个功能切换到它们的安全状态并点亮L1。因此,针对潜伏故障的诊断覆盖率声称是100%。

L1是仪表板上的一个LED灯,当探测到多点故障(其中只有一部分可以被探测到)时点亮它,并提示驾驶员功能1(打开阀1)的安全状态已被激活。

安全目标1中,安全机制对硬件要素的给定失效模式的覆盖率,称为“失效模式覆盖率”。

安全目标1

安全目标1被分配为ASIL B,对于ASIL B,单点故障度量推荐为≥90%,以及潜伏故障度量推荐为≥60%。单点故障度量的计算值为93.2%，表明此度量已被满足,同时潜伏故障度量的计算值为90%，表明潜伏故障度量也被满足。

安全目标2

安全目标2被分配为ASIL C,其中,单点故障度量要求≥97%;潜伏故障度量建议≥80%。单点故障度量的计算值为96.5%表明此度量未被满足,同时潜伏故障度量的计算值为91.6%表明潜伏故障度量得到满足。

3. 关键器件的选型与集成

车载智能计算平台的硬件主要由AI单元、计算单元与控制单元组成。根据不同的架构需求，上述单元可由一个或多个芯片组成，芯片的种类可能包含GPU/FPGA/ASIC、SoC、MCU等。

芯片多采取SEooC开发模式。安全相关芯片供应商在提供产品的同时会提供给车载智能计算平台的系统集成者相应的安全使用手册。安全使用手册一般包含芯片供应商对系统功能安全要求的假设，可支持的最高功能安全等级，集成的安全机制以及实现承诺功能安全等级需要满足的假设条件。

车载智能计算平台选用的安全相关器件需要满足分配到该器件的技术安全要求。芯片通常会对内部处理单元、存储单元、通信总线、接口等元件提供相应的安全机制以满足安全相关故障的诊断覆盖率要求。

除此之外，由于芯片的正常性能表现受限于一定的条件约束，保证时钟、温度、供电等在可操作范围内的安全机制也对功能安全的实现极为重要。车载智能计算平台需要按照各芯片厂商提供的安全手册搭建安全芯片外围电路和配置内部参数，确保芯片的安全内外部安全机制正常运行，从而在出现故障时能够及时进入安全状态。确保每个芯片正确集成的同时，还需确保集成后的硬件架构满足所有安全目标的随机失效概率量化指标要求。

处理单元

4. 供电系统设计

电源是整车电子电气架构中最基础的共用资源。如若电源系统发生失效，则可能导致车载智能计算平台的所有功能失效，对于L3及以上自动驾驶系统是不可接受的风险。车载智能计算平台的供电系统需要满足Fail-Operational的要求，通常会采用双电源供电的方式。需要考虑双路电源供电有足够的隔离措施，确保一路供电出现故障（电压过高、过低甚至出现短路）时，另外一路供电不受影响。

为满足车载智能计算平台系统ASIL D的要求，车载智能计算平台的供电系统需要能够监控电源输入和输出是否存在异常，尤其是电源系统输出的监测和控制。若电源系统出现输出电压过高或过低故障时，车载智能计算平台内部的主芯片有可能会因为供电电压不稳而导致运算结果异常，最终导致违反安全目标。因此，电源系统需在输出电压异常时，及时关断对应的主芯片供电，确保车载智能计算平台输出为确定状态。

电源

5. 通信系统设计

车载智能计算平台作为L3及以上自动驾驶的运算核心，通常通过专用的通信通道传输外界环境信息，而车载智能计算平台实现融合决策和车辆控制之后，将车辆运动控制指令通过通信总线发送至车辆的纵向和横向控制执行器。总线通信通道可能因为线束破损、外界电磁干扰和其他节点损坏等因素导致通信失效，包括报文丢失、报文延迟和报文篡改等多种类型的失效模式。

采用多种安全监测工具的组合可以满足高诊断覆盖率的要求，但此种方法只能满足Fail-Safe的要求，即发现通信故障，但无法维持系统正常工作。为了实现L3自动驾驶功能Fail-Operation的要求，可采用硬件冗余的方式，一方面提高了诊断覆盖率，另一方面可满足Fail-Operation的要求。通信通道的冗余设计需要考虑二者的独立性，例如采用不同类型的通信协议（如CAN-FD和FlexRay），避免发生共因失效。

通信总线(串行,并行)

6. 硬件测试

车载智能计算平台的硬件集成完成后，需要对硬件的安全性做全面的测试。硬件测试用例的导出方法包含硬件安全要求分析、内部及外部接口分析、等价类生成和分析、边界值分析等。硬件测试需要涵盖功能测试、故障注入测试、电气测试等测试方法来验证硬件安全要求的正确性和完整性，另外还需要涵盖最恶劣情况测试、超限测试、EMC测试和ESD测试等测试方法来验证车载智能计算平台硬件的鲁棒性和耐久性。测试完成后需要输出全面的测试报告作为硬件安全的佐证。

四、软件层面

车载智能计算平台作为智能汽车的安全关键系统，软件层面的安全性至关重要。由于车载智能计算平台功能丰富，应用场景复杂，对软件的实时性、安全性、可靠性要求极高，应通过技术和流程两个方面保障软件的功能安全。技术上确保软件层级的每个功能安全相关软件节点都有相应的故障监测和处理机制，流程上按照软件安全生命周期模型规范软件开发过程。基于参考阶段模型,为软件层面产品开发进行生命周期的剪裁。

软件开发参考阶段模型

1. 软件安全要求

车载智能计算平台软件安全要求是对软件安全相关的功能和性能的具体要求，主要是通过技术安全要求在软件层面的分配得到，并通过继承或分配得到相应的ASIL等级。另外，在软件架构阶段执行的软件安全分析也可能会识别出额外的软件安全要求。采用专业的需求管理工具来实现需求的编写、评审、管理以及双向追溯性检查可大幅降低软件层面的系统性安全风险。

2. 软件架构设计

软件架构设计是对软件需求的设计与实现，用来描述软件的框架要素和软件各分层结构之间的相互作用，其范围层面应到能够识别所有软件单元的程度。软件架构设计不仅需满足相应ASIL等级的软件安全要求，还应满足软件其他非安全要求。在软件架构层面，软件安全要求会分层次地分配给软件组件直到软件单元，每个软件组件应按照分配给它的安全要求中最高的ASIL等级来开发。

车载智能计算平台应在软件架构设计阶段进行软件安全分析和相关失效分析，完善错误探测和错误处理的安全机制，以便识别或确认软件安全相关部分，证明软件的安全相关的功能和性能满足相应的ASIL要求，支持安全措施的定义及其有效性。车载智能计算平台软件架构设计完成后，应对其开展验证活动，输出软件验证报告，证明软件架构设计严格遵守设计规则，兼容目标环境，满足相应ASIL等级的需求，并且相关评审证据充足。

软件安全设计依然可以从E-Gas三层架构中提取关键设计理念。E-Gas针对的典型系统，基本的思想是外围系统—内部系统，内部系统分为传感器、控制器和执行器。在这个系统概念里，传感器是加速踏板传感器，控制器是ECU（Engine Control Unit），执行器是节气门。展开安全架构设计的时候，需要时刻关注将系统解耦和模块化，这对于软件的安全设计是非常重要的。

E-Gas典型系统组成及边界

关于E-Gas安全架构的核心理念和设计，这里再回顾一下，整体设计分为Level1、Level2和Level3，其定义如下：

E-Gas三层安全架构（带锁步核）

（1）Level1：功能层，包括扭矩的解析、功能的诊断等，最直接的理解就是能够实现设计基本功能的软件及相关硬件资源的组合。

（2）Level2：功能监控层，负责监控功能层的输出结论，简单理解来看，就是软件的冗余校验，但是，由于不想消耗太多资源及避免算法共因，所以基于功能结果的监控。

（3）Level3：硬件监控层，负责确保Level1和Level2的运行的硬件环境是正常工作的，异常的运行环境会导致Level2的设计起不到很好效果，因此，Level3在整体的监控架构中作用是不可替代的。

下图是Level2算法架构的一个示例（汽油歧管喷射），其整体思想是计算实际系统输出的扭矩和此刻系统允许输出的安全现值之间的差值，当差值大于一定数值及一定时间时，采用相应的故障动作。

同时，方案为了避免出现误报或者漏报的情况，每一项用于计算的信号或者相应的传感器都应该具有相应的诊断及故障动作，这也是软件开展功能安全设计很关键的理念，输入信号是需要高完整性和准确性的。

三层架构Level2算法架构示例

针对Level3的硬件监控层，需要涉及软件和硬件的交互，监控的机制可以通过软件实现，也可以通过硬件实现。这里罗列了E-Gas中涉及软件方面的问题：

（1）ROM检查：针对ROM的检查，主要是涉及数据翻转、错误的刷写、错误的数据等，软件在其中扮演着检测对比算法的角色，当然，ROM的检查通过硬件也可以实现。

（2）应答机制检查：软件需要在设定时间窗口内正确回答独立硬件监控单元的问题，如果超时或者回答错误一定次数，都会触发重置或者下电。

（3）指令集检查：指令集是处理器核心的计算最基本单元，也是Level2监控算法正确执行的基础，确保指令集的正确可以采用软件辅助计算应答方法，或者采用目前诊断覆盖率更高的锁步核机制冗余校验（Lockstep-Core）。

（4）程序流检查：监控算法、诊断算法等都是周期性按顺序执行的，因此，执行时序也需要进行检查。

通过E-Gas的三层经典架构，我们可以分析出软件层级的功能安全设计需要考虑的软件包括Level1的功能层软件、Level2的监控层软件以及Level3的部分支持硬件监控层软件。

对于Level1功能软件，它本身的失效在整体架构中并不会违反安全目标，理应可以按照QM来开发，但考虑到软件本身的可靠性，建议依照ASIL-A或者ASPICE CL2级进行开发，毕竟，一个产品只确保安全但可靠性很差是没有办法交付给客户的；对于Level2和Level3的软件，按照安全分析，需要依靠系统的最高ASIL等级开发。

软件开发遵循原则参考

当然，并不是说非三层架构设计软件无法实现功能安全开发或者产品无法符合功能安全要求。E-Gas三层架构能够很清晰地实现层级递进式的监控设计，尤其适用于功能软件复杂的产品。如果功能软件相对复杂，高ASIL等级的产品在导致软件开发的工作量大量增加的同时安全性也很难兼顾；当然，如果应用层软件相对简单（例如滤波算法、局部优化、状态机等函数），采用下表所列方式会更好。

非三层架构开发遵循原则参考

对于功能安全软件设计而言，软件架构设计一个重要的目标是使软件需求的实现过程以一种完整的、正确的同时尽可能简单、可理解和可验证的方式展现，从而在软件需求实现过程中，尽可能降低由于设计错误造成违反功能安全需求的可能性。

功能安全要求软件架构的设计具备以下属性：可理解性，一致性，简单性，可验证，模块化，层次化，按层逐步细化、封装，低耦合性，可维护性。对于可理解性，ISO 26262中按照不同的ASIL等级规定了不同的软件架构设计的表示方式。

软件架构设计符号说明

常见的几种软件架构安全分析方法包括SW-FMEA、SW-FTA及SW-DFA。

A. SW-FMEA

SW-FMEA以硬件组件和软件模块之间的接口或软件模块和软件模块之间的接口为分析对象，列举硬件组件接口或软件模块的失效模式，分析失效模式对后续软件模块或者软件需求的影响，尤其是与功能安全相关的影响。在明确失效模式和失效后果的基础上，去寻找造成硬件组件接口或软件模块的原因，并且对原因施加控制措施。

B . SW-FTA

SW-FTA探究的重点是软件架构中多点错的发生对软件功能安全需求的影响。SW-FTA分析过程从软件功能安全需求出发，从软件架构设计中所有软件模块和软件接口的失效模式中去寻找和当前软件功能安全需求相关的失效模式，并且识别出这些失效模式和当前软件功能安全需求的相关性（单点失效还是多点失效）。

C. SW-DFA

SW-DFA在标准中定义的从属故障（Dependent failure）包括级联故障（Cascading failure）和共因故障（Common cause failure）。通常可以从以下几个方面来考虑Dependent failure 中Cascading failure的部分：

时间和调度问题造成Cascading failure。比如，由于其他模块运行时间过长导致目标模块无法运行，死锁、活锁、饥饿等现象导致模块运行停滞或者延迟，软件模块之间的同步性问题或者优先级问题导致调度次序出现问题。

存储空间问题造成Cascading failure。比如，目标存储区域被其他软件模块误篡改，软件模块之间对于同一存储空间的读写操作配合问题导致数据不一致（读数据的同时允许写数据），栈溢出等问题。

软件模块之间的通信（ 尤其是ECU 间的通信） 问题造成Cascading failure。时间和调度问题造成Cascading failure。

随着ASIL等级的提升，ISO 26262从语法和语义两个维度出发，从最低要求的自然语言描述到半正式的表述方式，逐步加强对表述方式的理解一致性的要求。为了避免系统性失效，ISO 26262对软件架构设计提出了一些设计原则。

软件架构设计原则

ISO 26262对软件架构设计验证方法

3. 软件单元设计与实现

在软件单元设计与实现阶段，基于软件架构设计对车载智能计算平台的软件单元进行详细设计。软件单元设计应满足其所分配的ASIL等级要求，与软件架构设计和软硬件接口设计相关内容保持一致。

为了避免系统性失效，应确保软件单元设计的一致性、可理解性、可维护性和可验证性，采用自然语言与半形式化方法相结合的方式进行描述。说明书应描述实施细节层面的功能行为和内部设计，包括数据存储和寄存器的使用限制。

在源代码层面的设计与实施应使得软件单元设计简单易懂，软件修改适宜，具有可验证性和鲁棒性，确保软件单元中子程序或函数执行的正确次序，软件单元之间接口的一致性，软件单元内部及软件单元之间数据流和控制流的正确性。

车载智能计算平台软件包含数百个软件单元，软件单元的标准化、单元间解耦是高效实现软件功能安全的基础。车载智能计算平台中不同安全等级的软件可以采用硬件虚拟化、容器、内存隔离等技术进行隔离，防止软件单元之间的级联失效。

软件代码设计过程中应遵守成熟的代码设计规范，例如MISRA C。MISRA C是由汽车产业软件可靠性协会（MISRA）提出的C语言开发标准。其目的是在增进嵌入式系统的安全性及可移植性，针对C++语言也有对应的标准MISRA C++。MISRA C一开始主要是针对汽车产业，不过其他产业也逐渐开始使用MISRA C：包括航天、电信、国防、医疗设备、铁路等领域中都已有厂商使用MISRA C。MISRA C的第一版《Guidelines for the use of the C language in vehicle based software》是在1998年发行，一般称为MISRA-C:1998.。

MISRA-C:1998有127项规则，规则从1号编号到127号，其中有93项是强制要求，其余的34项是推荐使用的规则。在2004年时发行了第二版的MISRA C的第一版《Guidelines for the use of the C language in critical systems》（或称作MISRA-C:2004），其中有许多重要建议事项的变更，其规则也重新编号。

MISRA-C:2004有141项规则，其中121项是强制要求，其余的20项是推荐使用的规则。规则分为21类，从“开发环境”到“运行期错误”。2012年发布第三版，为当前最新有效的C语言规范版本，称为MISRA C:2012。

企业可以基于MISRAC建立一套满足车载智能计算平台安全编码要求的内部编码规范，并严格执行。

ISO 26262软件单元设计和实现的设计原则

4. 软件单元验证

软件单元验证是通过评审、分析和测试的方法对功能安全相关的软件单元设计与实现进行验证，证明软件相关安全措施已经在设计与实现中全部落实。软件单元设计满足相应的ASIL等级的软件需求和软硬件接口规范要求，软件源代码的实现与单元设计一致，不存在非期望的功能和性能，且支持功能和性能实现的相关资源充足。

车载智能计算平台的软件单元验证可参考下表，通过需求分析、等价类的生成与分析、边界值分析和错误推测相结合的方法合理设计测试用例，确保对软件单元进行充分验证。为了评估软件单元验证的完整性，为单元测试的充分性提供证据，应确定在软件单元层面的需求覆盖率，同时对结构覆盖率进行测定。

车载智能计算平台软件单元测试的结构覆盖率目标为100%，如果已实现结构覆盖率不能达到目标，可以定义额外的测试用例并提供接受理由。车载智能计算平台软件单元的结构覆盖率测试应采用满足相关安全要求的测试工具，确保在测试过程中测试工具和检测代码不会对测试结果产生影响。

车载智能计算平台软件单元测试应根据测试范围，选用适当的测试环境。测试环境应适合完成测试目标，尽可能接近目标环境，如果不是在目标环境执行，应分析源代码与目标代码的差异、测试环境和目标环境之间的差异，以便在后续测试阶段的目标环境中，定义额外的测试。

软件单元验证方法

软件单元测试用例的得出方法

5. 软件集成验证

软件集成验证需要根据软件验证计划、接口规范、软件架构设计规范、软件验证规范等对软件架构中所描述的集成层次、接口、功能等进行持续测试，以验证其与设计的符合性。

由于车载智能计算平台软件的复杂性，实时性、可靠性、安全性既是设计目标也是基础性能，集成测试设计阶段应对其功能、逻辑、性能、边界、接口进行详细分析。车载智能计算平台的软件集成验证参考下表，不仅需涵盖所有应用软件、功能软件、系统软件以及与硬件之间的接口，并且应涵盖软件单元之间的接口。测试用例在测试工作中至关重要，其输出需要考虑功能需求、性能需求、边界值、接口、逻辑关系等。

软件集成验证方法

软件集成测试用例的得出方法

6. 嵌入式软件的测试

车载智能计算平台嵌入式软件测试主要是基于软件安全要求的测试可参考下表，针对软件安全要求进行充分的故障注入测试，最终确保软件安全要求的正确实现。为了验证车载智能计算平台软件在目标环境下是否满足软件安全要求，应进行硬件在环测试、车辆电控系统和网络通信环境下的测试以及实车测试。

硬件在环测试是将车载智能计算平台软件烧写到目标芯片中，在目标芯片的硬件异构平台环境下验证软件的安全要求。然后，将车载智能计算平台与部分或全部的车辆电子电气设备进行网络通信，在车辆电控系统和网络环境下验证软件的安全要求。

最后，将车载智能计算平台安装到实际车辆中，进行软件安全要求的验证与确认。

嵌入式软件的测试方法

嵌入式软件测试用例的得出方法

7. 人工智能

通过实施完善的开发流程可降低车载智能计算平台人工智能的系统性安全风险。车载智能计算平台人工智能的开发包含需求分析、算法设计、数据采集和标注、模型训练、测试验证以及运行等流程。

人工智能的需求分析应包含算法的基本功能需求和功能安全要求（如算法精度目标、算法Fail-Operational等）。

算法设计阶段应考虑采用多算法、多模型、多帧数据、多传感器等多种冗余机制的组合以提升安全性。

数据采集和标注阶段应确保数据标注精度、数据场景分布，并避免数据错标和漏标，从而确保模型训练不受影响。

模型训练阶段采用业界成熟、文档全面的人工智能框架。

测试验证阶段对所有需求进行闭环的测试，同时全面考虑各种潜在应用场景及环境影响因素，进行长距离的实车试验。

根据测试结果不断重复进行数据的采集、标注、模型训练和测试验证的阶段，通过迭代的方式逐步提高人工智能的安全性。在运行阶段，应持续地对实际运行数据和人工智能的安全性进行监控，通过分析实际运行数据对人工智能算法和模型不断优化。

8. 软件阶段常用工具介绍

a、Polyspace

Polyspace Bug Finder可以识别嵌入式软件C和C++代码中的运行时错误、并发问题、安全漏洞和其他缺陷。使用静态分析（包括语义分析），Polyspace Bug Finder可分析软件控制流、数据流和进程间行为。

通过在检测到缺陷之后立即高亮显示缺陷，可在开发过程的早期阶段鉴别和修复错误。Polyspace Bug Finder可检查是否符合编码规范，如MISRA C、MISRA C++、JSF++、CERT C、CERT C++和自定义命名规范。

它可以生成报告，其中包括发现的错误、代码违规和代码质量指标，如圈复杂度。Polyspac eBug Finder可与Eclipse IDE配合使用进行代码分析。

Polyspace软件截图

b、Tessy

Tessy软件源自戴姆勒—奔驰公司的软件技术实验室，由德国Hitex公司负责全球销售及技术支持服务，是一款专门针对嵌入式软件动态测试的工具。它可以对C/C++代码进行单元、集成测试，可以自动化搭建测试环境、执行测试、评估测试结果并生成测试报告等。

多样化的测试用例导入生成方式和与测试需求关联的特色，使Tessy在测试组织和测试管理上也发挥了良好的作用，目前，Tessy广泛应用汽车电子主流客户中。Tessy满足各类标准（如ISO 26262、IEC61508）对测试的需求，比如Tessy可以满足ISO 26262中各个测试等级对模块测试的要求，当然，Tessy本身也通过了TÜV的认证，证明该软件是安全可靠的，可以在安全相关的软件研发过程中使用。

Tessy 软件截图

c、Helix QAC

Helix QAC是静态代码分析工具，依据C和C++编码规则自动扫描代码对规则的违背。在开发过程的早期就可以用它来检测缺陷，因为此时修改代码是最方便也最经济的。Helix QAC自动化强制实施代码编程标准，比如，MISRA保证代码的合规性。Helix QAC识别必须修改的缺陷，提供详细的指导，帮助开发人员修改问题。这是不需要运行程序的。开发人员既然获得了即时的上下文反馈，他们将因此从错误中获得学习，下一次编写新的代码（或者评审代码）时，能力将得到提升。Helix QAC自动审查代码，确保它们符合用户选择的编码标准。合规性报告可视化地提醒用户哪些代码需要多加留意。Helix QAC支持多种C和C++编码标准，提供相应的合规性模块，也支持标准的客户化定制。

Helix QAC软件截图