1 引言

2018 年 12 月，备受汽车电子行业关注的 ISO26262 《道路车辆功能安全标准》第二版发布，适用范围从乘用车扩展到所有车型，包括商用车和摩托车，该标准对商用车汽车电子器件提出更为详尽的功能安全要求。在功能安全相对领先的欧美国家，主流 OEM 和 Tier1 普遍对 ISO26262 标准有要求，已成为事实强制标准。

从 2016 年接触 ISO26262 标准以来，对 PART 6 “软件部分”进行了反复研读，但始终无法找到其与车载嵌入式软件设计之间的联系，在很长一段时间内都不知道如何开发出满足功能安全的车载 ECU 软件；即使在 2020 年，我所在的电控团队顺利拿到了 ISO26262 ASIL D 流程认证，但我对功能安全的认知也仅仅停留在“编写一系列文档”的水平。

从 2022 年 4 月到 2023 年 12 月，我有幸全程参与了一个完整的车载电控模块功能安全项目 - 基于公司的某款纯电车辆，开发出满足功能安全 ASIL C/D 等级的 VCU （整车控制器）产品。在这篇文章里，将结合自己在项目中的实践，对部分开发过程进行梳理，希望能给像我一样对 ISO26262 标准实现有困惑的同行提供些许参考。

2 基本概念

ISO26262 标准的术语在 PART 1 中按照音序顺序进行了详细描述，表 2-1 只列出了本文需要用到的基本概念。

表 2-1: VCU 功能安全项目 术语

3 功能安全概念开发

VCU 功能安全项目只进行了概念（ ISO26262 PART3 ）、系统（ ISO26262 PART4 ）、硬件（ ISO26262 PART5 ）和软件（ ISO26262 PART6 ）阶段的开发，本章整理概念阶段的工作内容，系统和软件的工作将分别在第 4 章和第 5 章整理。

功能安全概念阶段应输出相关项定义、危害分析和风险评估、功能安全概念等工作产品。

3.1 相关项定义

相关项指实现整车层面功能或部分功能的系统或系统组合；相关项定义指在整车层面对相关项进行定义和描述，包括功能及其与驾驶员、环境和其他相关项的依赖性和交互。

概念阶段的开发是 从 相关项定义 （ Item Definition ） 开始的，相关项定义是对系统的描述，此系统也是标准中 “ 安全 ” 要求应用的对象。

项目定义的目的是定义和描述相关项，以及对其他相关项和环境的依赖和相互作用。因此，需要描述功能和非功能需求、边界、接口和其他系统相互作用的假设。

相关项定义为危害分析和风险评估 （ HARA ） 提供输入参数，在 HARA 中通过对 E/E 系统功能故障的定义和分析，识别整车级别的潜在危害。

对于相关项 （ Item ） 的边界，相关项与其他相关项或环境的相互作用，相关项内部的元素以及涉及到元素的功能分配，需要在相关项文档进行描述。

表 3-1 列出相关项定义的主要内容。

表 3-1: 相关项定义主要内容

3.2 HARA 分析

危害分析、风险评估和 ASIL 等级的评定用于确定相关项的安全目标。为此，根据相关项的潜在危害事件，对相关性进行评估。通过对危害事件进行系统性的评估确定安全目标及分配给他们的 ASIL 等级。 ASIL 等级的确定需要考虑严重度、暴露概率和可控性。

HARA 分析的输出物是《危害分析和风险评估报告》。

3.2.1 危害分析

表 3-2 为危害分析示例。

表 3-2: 危害分析示例

① 如表 3-3 和图 3-1 所列

表 3-3: 危害分析引导字说明

图 3-1: 危害分析引导字图示

3.2.2 风险评估

对不含内部安全机制的相关项进行评估 ， 表 3 - 4 为风险评估示例。

表 3-4: 风险评估示例

3.2.3 计算过程

确定每个危害事件的严重度等级、暴露概率等级和可控性等级，并根据这三者确定其 ASIL 等级。本步对所有 不含内部安全机制的相关项 进行风险评估。

表 3-5 、表 3-6 、表 3-7 和表 3-8 分别列出与 ASIL 等级确定的知识点。

表 3-5: 严重度等级

表 3-6: 关于运行场景的暴露概率等级

表 3-7: 可控性等级

表 3-8: ASIL 等级确定

3.2.4 安全目标

应为具有 ASIL 等级的每个危害事件确定一个安全目标，该 ASIL 等级从危害分析和风险评估中得出。如果所确定的安全目标是类似的，可将其合并为一个安全目标。

表 3-9 为安全目标示例。

表 3-9: 安全目标示例

3.3 功能安全概念

为了满足安全目标，功能安全概念包括安全措施（含安全机制），这些安全措施将在相关项的架构要素中实现，并在功能安全要求中规定。

功能安全概念包含以下内容。

3.3.1 安全分析

针对每个安全目标，对系统的初始架构进行安全分析，找出影响安全目标的子系统故障，作为后续导出功能安全需求的依据。安全分析工具可以是 FTA 或 FMEA ，图 3-2 为采用 FTA 方法的示例。

图 3-2: FTA 安全分析示例

3.3.2 功能安全需求

根据安全分析的结果，针对每个安全目标导出相应的功能安全需求。表 3-10 为功能安全需求的编写示例。

表 3-10: 功能安全需求示例

3.3.3 外部系统功能安全需求

外部系统功能安全需求分为 “相关项对外部系统的功能安全需求”和“外部系统对相关项的功能安全需求”，表 3-11 和表 3-12 分别为这两者的示例。

表 3-11: 相关项对外部系统的功能安全需求示例

表 3-12: 外部系统对相关项的功能安全需求示例

3.3.4 报警和降级

当系统诊断到相应的故障后，应该立刻进入到安全状态，如不能直接进入安全状态，则需要进入紧急操作模式，或降级模式，再进入安全状态，同时也要规定紧急操作模式的时间长度。另外，当故障出现后，驾驶员需要作何反应，有何行为要求也需要描述。

表 3-13 为报警和降级的编写示例。

表 3-13: 报警和降级示例

3.3.5 功能安全需求汇总和分配

对所有安全目标导出的功能安全需求进行汇总和ASIL等级的合并，确定相关项的功能安全需求，同时将功能安全需求分配到系统架构中去。

表3-14为功能安全需求汇总和分配示例。

表3-14: 功能安全需求汇总和分配示例

3.3.6 功能安全架构

根据所提出的 FSR ，更新系统架构，并将功能安全需求分配到架构的模块上去，从而使得系统的架构满足功能安全需求。

4 功能安全系统开发

功能安全系统阶段的工作包括技术安全需求、技术安全概念、系统架构设计规范和软硬件接口规范等。

4.1 技术安全需求

技术安全 需求 应定义系统对影响安全 需求 实现的激励的响应。这包括在各种相关运行模式和所定义的系统状态下 ， 激励与失效的组合。

表 4-1 为技术安全需求示例。

表 4-1: 技术安全需求示例

4.2 软硬件接口规范

软硬件接口规范包含以下内容。

4.2.1 操作模式

操作模式包括操作模式转换图（ Operating Modes Transfer Diagram ）、操作模式描述（ Operating Modes Description ）和操作模式转换条件（ Operating Modes Transfer Condition ）等。图 4-1 、表 4-2 和表 4-3 分别为三者的示例。

图 4-1: 操作模式转换图示例

表 4-2: 操作模式示例

表 4-3: 操作模式转换条件示例

4.2.2 配置参数

列出 IC 相关配置参数（如： MCU 、通信、存储器、 I/O ）。例如： AURIX TC275 的描述内容包括 MCAL 、 SafeTlib 、 MCU-SM 。

4.2.3 独立性要求

软件进行相关失效分析（ Dependent Failure Analysis ）后识别到支持软件独立性要求的硬件特性 。

表 4-4 为 AURIX-TC275 的描述内容（部分）。

表 4-4: AURIX-TC275 独立性要求描述

4.2.4 相互免干扰

软件进行相关失效分析（ Dependent Failure Analysis ）后识别到支持软件相互免干扰要求的硬件特性 。

表 4-5 为 AURIX-TC275 的描述内容（部分）。

表 4-5: AURIX-TC275 相互免干扰描述

4.2.5 输入输出

描述 ECU 级别的硬件信号与 MCU 的端口 / 引脚和软件输入 / 输出变量之间的关系，表 4-6 为其示例。

表 4-6: AURIX-TC275 软硬件接口输入输出示例

4.2.6 中断

描述系统所有中断分配情况，包括中断源、中断频率、中断服务程序的职责 ， 以及其他相关的信息等 ，表 4-7 为其示例。

表 4-7: AURIX-TC275 软硬件接口中断示例

4.2.7 内存分配

描述系统所有用到的 RAM 空间、 FLASH 空间、 EEPROM 空间的分配方案 ，表 4-8 为其示例。

表 4-8: AURIX-TC275 软硬件接口内存分配示例

4.2.8 访问机制

描述硬件设备间的访问机制（ Serial ， parallel ， slave ， master/slave ），表 4-9 为其示例。

表 4-9: 软硬件接口访问机制示例

4.2.9 硬件诊断

描述硬件的诊断特性和响应的安全机制及软件的实现 ，表 4-10 为其示例。

表 4-10: 软硬件接口硬件诊断示例

4.2.10 时间约束

描述系统安全机制 中 硬件与软件所用时间 ，表 4-11 为其示例。

表 4-11: 软硬件接口硬件诊断示例

4.3 技术安全概念

技术安全概念的目的是从功能安全概念 中 导出技术安全需求，设计技术安全概念，并且将技术安全需求分配到相关项的初始架构中。

4.3.1 系统功能描述

系统功能如表 4-12 所列，文档中需要对每项功能进行详细描述。

表 4-12: 系统功能描述示例

4.3.2 系统初始架构设计

设计 VCU 整体初始系统架构并按照表 4-13 、表 4-14 和表 4-15 分别进行功能、外部接口和内部接口描述。

表 4-13: VCU 初始架构功能描述示例

表 4-14: VCU 外部接口描述示例

表 4-15: VCU 内部接口描述示例

4.3.3 基于系统初始架构的安全分析

安全分析首先需要设计功能失效列表；再依次进行外部非电气接口失效矩阵分析、约束性需求失效矩阵分析、配置功能失效矩阵分析和共享资源安全完整性分析；最后分别对系统失效顶事件进行安全分析。

（ 1 ） 功能安全目标

表 4-16 为功能安全目标的设计示例。

表 4-16: 功能安全目标设计示例

（ 2 ） 功能失效列表

根据功能安全目标提炼出功能失效列表，这是进行安全分析的基础，如表 4-17 所列。

表 4-17: 功能失效列表示例

（ 3 ） 顶事件安全分析

使用与图 4-2 类似的 FTA 进行安全分析，输出表 4-18 所示的单点故障和潜伏故障列表。

图 4-2: FTA 安全分析示例

表 4-18: 单点故障和潜伏故障列表示例

4.3.4 安全机制设计

分别设计单点故障和潜伏故障的安全机制，参见表 4-19 和表 4-20 。

表 4-19: 单点故障安全机制设计示例

表 4-20: 潜伏故障安全机制设计示例

4.3.5 其他

技术安全概念还应包含下列内容：系统降级策略；非功能相关的技术安全需求（试验需求、机械结构安装需求、硬件指标需求、共存需求、独立性需求等）；生产、运行、服务和报废需求规范；最终输出系统安全整体架构。

5 功能安全软件开发

VCU 功能安全软件阶段设计按照 V 流程的步骤进行，包括软件需求分析、软件架构设计、软件单元设计、软件单元测试、软件集成等步骤，软件集成测试和嵌入式软件测试分别由 HIL 和实车测试工程师负责。

5.1 软件安全需求

本阶段定义或细化由技术安全概念和系统架构设计规范导出的软件安全需求，并描述软件实现所需的安全相关功能和特性。

5.1.1 需求列表

表 5-1 为软件需求列表的示例。

表 5-1: 软件需求列表示例

5.1.2 模式转换

主要用于描述当前系统不同行为模式（例如上电模式、下电模式、运行模式、故障模式等）及各个行为模式的功能，模式之间的切换条件等。

5.1.3 功能描述

对软件功能进行详细描述，表 5-2 为功能描述示例。

表 5-2: 软件安全需求功能描述示例

5.1.4 设计约束

设计约束包括功能启动时间、负载率、内存空间使用率、空间分配、共存需求和独立性需求等，表 5-3 为其设计示例。

表 5-3: 软件安全需求设计约束示例

5.2 软件架构设计

软件架构设计以层次结构的形式表示软件架构要素以及他们的交互方式。描述了静态方面 ， 如软件组件之间的接口 ； 动态方面 ， 如进程序列和时序行为。

软件架构设计既 要 满足软件安全要求 ， 又 要 满足其他软件要求。因此 ， 在该子阶段中 ， 与安全相关和非安全相关的软件要求在同一个开发过程中处理。

5.2.1 软件架构总体描述以及分层视图

本项目的软件架构基于 AUTOSAR 架构开发，应用层开发方式为基于模型设计（ MBD ），底层购买自第三方（ ETAS AUTOSAR ）。

VCU 软件架构如图 5-1 所示。

图 5-1: VCU 软件架构图

5.2.2 软件组件设计

分别描述软件架构中各组件的组件描述、组件图和接口描述等，表 5-4 、图 5-2 、表 5-5 和表 5-6 分别为对应的示例。

表 5-4: 组件概览示例

图 5-2: 软件组件图示例

表 5-5: 软件组件数据接口描述示例

表 5-6: 软件组件函数接口描述示例

5.2.3 动态行为

动态行为常见的描述方式有以下三种：时序图（ Sequence Diagram ） 、 活动图（ Activity Diagram ） 和 交互纵览图（ Interaction Overview Diagram ） 。 动态行为描述的对象基于系统级功能列表，对其功能进行描述。

图 5-3 为动态行为图示例。

图 5-3: 动态行为图示例

5.2.4 任务调度和任务分配

描述系统所有任务的调度策略及任务划分，抢占属性，调度周期和优先级等。 任务 划分时，需考虑便于实现不同 ASIL 等级之间的 免干扰性。

5.2.5 资源预估

计算 CPU 在不同调度周期（如： 1ms 、 5ms 、 10ms 、 100ms 、 1s ）的使用率以及软件系统所用到 RAM 空间、 FLASH 空间、 EEPROM 空间的分配方案。

5.2.6 资源冲突和控制流监控

所有存储在同一个字节中的全局标志应视为共享资源 ， 对于有共享资源冲突的使用需要保护 。

控制流监控有三种类型：活跃性监控（ Alive Supervision ）、最后期限监控（ Deadline Supervision ）和逻辑监控（ Logic Supervision ）。

本步制定在资源冲突和控制流监控时的安全机制。

5.3 软件单元设计和实现

软件单元设计和实现的目的是按照软件架构设计、设计准则和所分配的支持软件单元实施和验证的软件要求，进行软件单元设计；并实现所定义的软件单元。

5.3.1 软件功能简述

描述软件单元实现的功能。

5.3.2 组件源码文件

罗列程序文件名称及其实现的功能，表 5-7 为组件源码文件示例。

表 5-7: 组件源码文件示例

5.3.3 静态框图

可以通过约定的方式展示组件静态框图，包括组件内单元的结构关系及单元之间的接口，且保持整个组件设计与架构中组件定义保持一致 。 图 5-4 为静态框图示例。

图 5-4: 软件单元静态框图示例

5.3.4 单元接口

描述单元间输入、输出信息，或使用表格的形式展示，也可单独管理接口信息，参见数据字典。 表 5-8 为软件单元接口示例。

表 5-8: 软件单元接口示例

5.3.5 动态行为

基于 SWC 在架构设计中的动态行为及要求实现的软件功能需求及非功能需求，描述组件内单元之间的动态行为；动态行为描述可以采用时序图、状态机等形式进行 。 图 5-5 为软件单元动态行为示例。

图 5-5: 软件单元动态行为示例

5.3.6 变量定义

描述本组件或某单元内部的局部变量、标定量、常量、宏、复合数据等；也可单独管理接口信息，参见数据字典。 表 5-9 为变量定义示例。

表 5-9: 软件单元变量定义示例

5.3.7 配置项设计

描述可在线配置和离线配置的配置项，离线 指 修改参数后再次编译，在线是通过诊断服务的方式进行配置项修改。 表 5-10 为配置项设计示例。

表 5-10: 软件单元配置项设计示例

5.3.8 函数单元设计

对软件单元所含各函数的函数原型、输入输出参数、返回值、功能描述、设计思路、实现方法等逐一说明。

5.4 软件单元验证

本步提供证据证明软件单元设计满足分配的软件要求且适合于实施，验证安全分析得出的安全措施得到适当实施，提供证据证明所实现的软件单元符合单元设计，并满足根据所需的 ASIL 等级分配的软件要求。

5.4.1 软件验证计划和策略

表 5-11 、表 5-12 、表 5-13 和表 5-14 分别为软件验证计划（ Software Verification Plan ）、软件单元测试范围（ Software Unit Test Scope ）、测试工具列表及环境（ Test Tool List and Environment ）和软件单元验证策略（ SW Unit Test ）的示例。

表 5-11: 软件验证计划示例

表 5-12: 软件单元测试范围示例

表 5-13: 测试工具列表及环境示例

表 5-14: 软件单元验证策略示例

5.4.2 软件单元测试用例和报告

表 5-15 为软件单元测试用例和报告的示例。

表 5-15: 软件单元测试用例和报告示例

5.4.3 软件模型和代码静态验证报告

表 5-16 和表 5-17 分别为软件模型和代码静态验证报告的示例。

表 5-16: 软件模型静态验证报告示例

表 5-17: 软件代码静态验证报告示例

5.5 软件集成和验证

本步定义集成步骤并集成软件要素，直至嵌入式软件完全集成；验证是确保软件架构层面的安全分析得出的已定义的安全措施得到适当实施。

5.5.1 软件集成

软件集成的方法应定义和描述将各个软件单元分层集成到软件组件中的步骤，直到整个嵌入式软件全部被集成。

对于 AUTOSAR 工具链方式设计的车载嵌入式软件而言，软件集成主要包括基础软件模块间的集成以及基础软件与应用层软件的集成。

5.5.2 集成测试范围

表 5-18 为软件集成测试范围示例。

表 5-18: 软件集成测试范围示例

5.5.3 集成测试报告

与软件单元测试报告格式相同。

6 功能安全基础软件核心工作梳理

下面列出 VCU 功能安全项目基础软件的主要工作。

6 .1 概念阶段

功能安全概念阶段基础软件工程师工作较少，主要是检查、学习相关项定义和功能安全概念开发，辅助绘制功能安全架构等。

6 .2 系统阶段

功能安全系统阶段基础软件的工作如表 6-1 所列。

表 6-1: 系统阶段基础软件工作

6 .3 软件阶段

功能安全软件阶段基础软件的工作如表 6-2 所列。

表 6-2: 软件阶段基础软件工作

7 项目总结

以上列出了新能源 VCU 功能安全项目的开发过程，下面简要做个总结。

7.1 标准与项目

功能安全规范只是一份指导性文档，学会满足功能安全的汽车电子设计方法离不开具体项目的工程实践，这个过程可以在专业咨询公司的指导下进行。

7.2 文档与程序工程

功能安全设计不仅仅是编写文档，而是借助文档制定安全目标、设计安全机制、再通过软硬件设计满足车辆安全性需求。最终输出的程序需要在经过 HIL 、实车测试验证后满足量产要求。

7.3 能力要求

从功能安全项目基础软件部分的工作看， Wdg 模块开发需要具备 MCAL 设计能力； WdgM 和 E2E 模块开发需要具备 BSW 设计能力；软件集成需要 RTE 设计能力；不同 ASIL 等级的任务分配需要 OS 设计能力；主控芯片和电源芯片安全机制实现需要手册研读和手工编程的能力 ...... 应用层软件与硬件工程师的工作也与之类似。因此，开发出一款满足 ISO26262 的车载 ECU 需要相关工程师具备全面的设计能力和文档能力。

功能安全不是一门单独的技术，而是软硬件设计的拓展和升华。

7.4 功能安全认证

最后聊一下车辆功能安全工程师考试。具备高含金量的功能安全证书考试具有较高的难度和巨大的题量（据说没有中国考生能做完题），并且考察的内容涉及到标准的各个章节（含术语、概念、系统、硬件、软件、生产等）。做项目肯定有分工，但如果想考证的话，标准各部分的重点知识要尽量多的掌握。