1 引言
我从2016年接触ISO26262标准以来，对PART 6“软件部分”进行了反复研读，但始终无法找到其与车载嵌入式软件设计之间的联系，在很长一段时间内都不知道如何开发出满足功能安全的车载ECU软件；即使在2020年，我所在的电控团队顺利拿到了ISO26262 ASIL D流程认证，但我对功能安全的认知也仅仅停留在“编写一系列文档”的水平。
从2022年4月到2023年12月，我有幸全程参与了一个完整的车载电控模块功能安全项目 - 基于公司的某款纯电车辆，开发出满足功能安全ASIL C/D等级的VCU（整车控制器）产品。在这篇文章里，我将结合自己在项目中的实践，对部分开发过程进行梳理，希望能给像我一样对ISO26262标准实现有困惑的同行提供些许参考。
2 基本概念
ISO26262标准的术语在PART 1中按照音序顺序进行了详细描述，表2-1只列出了本文需要用到的基本概念。
3 功能安全概念开发
VCU功能安全项目只进行了概念（ISO26262 PART3）、系统（ISO26262 PART4）、硬件（ISO26262 PART5）和软件（ISO26262 PART6）阶段的开发，本章整理概念阶段的工作内容，系统和软件的工作将分别在第4章和第5章整理。
功能安全概念阶段应输出相关项定义、危害分析和风险评估、功能安全概念等工作产品。
3.1 相关项定义
相关项指实现整车层面功能或部分功能的系统或系统组合；相关项定义指在整车层面对相关项进行定义和描述，包括功能及其与驾驶员、环境和其他相关项的依赖性和交互。
概念阶段的开发是从相关项定义（Item Definition）开始的，相关项定义是对系统的描述，此系统也是标准中“安全”要求应用的对象。
项目定义的目的是定义和描述相关项，以及对其他相关项和环境的依赖和相互作用。因此，需要描述功能和非功能需求、边界、接口和其他系统相互作用的假设。
相关项定义为危害分析和风险评估（HARA）提供输入参数，在HARA中通过对E/E系统功能故障的定义和分析，识别整车级别的潜在危害。
对于相关项（Item）的边界，相关项与其他相关项或环境的相互作用，相关项内部的元素以及涉及到元素的功能分配，需要在相关项文档进行描述。
表3-1列出相关项定义的主要内容。
3.2 HARA分析
危害分析、风险评估和ASIL等级的评定用于确定相关项的安全目标。为此，根据相关项的潜在危害事件，对相关性进行评估。通过对危害事件进行系统性的评估确定安全目标及分配给他们的ASIL等级。ASIL等级的确定需要考虑严重度、暴露概率和可控性。
HARA分析的输出物是《危害分析和风险评估报告》。
3.2.1 危害分析
表3-2为危害分析示例。
表3-2: 危害分析示例
表3-3: 危害分析引导字说明
3.2.2 风险评估
对不含内部安全机制的相关项进行评估，表3-4为风险评估示例。
表3-4: 风险评估示例
3.2.3 计算过程
确定每个危害事件的严重度等级、暴露概率等级和可控性等级，并根据这三者确定其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.3.2 功能安全需求
根据安全分析的结果，针对每个安全目标导出相应的功能安全需求。表3-10为功能安全需求的编写示例。
表3-10: 功能安全需求示例
3.3.3 外部系统功能安全需求
外部系统功能安全需求分为“相关项对外部系统的功能安全需求”和“外部系统对相关项的功能安全需求”，表3-11和表3-12分别为这两者的示例。
3.3.4 报警和降级
当系统诊断到相应的故障后，应该立刻进入到安全状态，如不能直接进入安全状态，则需要进入紧急操作模式，或降级模式，再进入安全状态，同时也要规定紧急操作模式的时间长度。另外，当故障出现后，驾驶员需要作何反应，有何行为要求也需要描述。
表3-13为报警和降级的编写示例。
3.3.5 功能安全需求汇总和分配
对所有安全目标导出的功能安全需求进行汇总和ASIL等级的合并，确定相关项的功能安全需求，同时将功能安全需求分配到系统架构中去。
表3-14为功能安全需求汇总和分配示例。
3.3.6 功能安全架构
根据所提出的FSR，更新系统架构，并将功能安全需求分配到架构的模块上去，从而使得系统的架构满足功能安全需求。
4 功能安全系统开发
功能安全系统阶段的工作包括技术安全需求、技术安全概念、系统架构设计规范和软硬件接口规范等。
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.2.2 配置参数
列出IC相关配置参数（如：MCU、通信、存储器、I/O）。例如：AURIX TC275的描述内容包括MCAL、SafeTlib、MCU-SM。
4.2.3 独立性要求
软件进行相关失效分析（Dependent Failure Analysis）后识别到支持软件独立性要求的硬件特性。
表4-4为AURIX-TC275的描述内容（部分）。
4.2.4 相互免干扰
软件进行相关失效分析（Dependent Failure Analysis）后识别到支持软件相互免干扰要求的硬件特性。
表4-5为AURIX-TC275的描述内容（部分）。
4.2.5 输入输出
描述ECU级别的硬件信号与MCU的端口/引脚和软件输入/输出变量之间的关系，表4-6为其示例。
4.2.6 中断
描述系统所有中断分配情况，包括中断源、中断频率、中断服务程序的职责，以及其他相关的信息等，表4-7为其示例。
4.2.7 内存分配
描述系统所有用到的RAM空间、FLASH空间、EEPROM空间的分配方案，表4-8为其示例。
4.2.8 访问机制
描述硬件设备间的访问机制（Serial，parallel，slave，master/slave），表4-9为其示例。
4.2.9 硬件诊断
描述硬件的诊断特性和响应的安全机制及软件的实现，表4-10为其示例。
4.2.10 时间约束
描述系统安全机制中硬件与软件所用时间，表4-11为其示例。
4.3 技术安全概念
技术安全概念的目的是从功能安全概念中导出技术安全需求，设计技术安全概念，并且将技术安全需求分配到相关项的初始架构中。
4.3.1 系统功能描述
系统功能如表4-12所列，文档中需要对每项功能进行详细描述。
4.3.2 系统初始架构设计
设计VCU整体初始系统架构并按照表4-13、表4-14和表4-15分别进行功能、外部接口和内部接口描述。
4.3.3 基于系统初始架构的安全分析
安全分析首先需要设计功能失效列表；再依次进行外部非电气接口失效矩阵分析、约束性需求失效矩阵分析、配置功能失效矩阵分析和共享资源安全完整性分析；最后分别对系统失效顶事件进行安全分析。
（1）功能安全目标
表4-16为功能安全目标的设计示例。
（2）功能失效列表
根据功能安全目标提炼出功能失效列表，这是进行安全分析的基础，如表4-17所列。
（3）顶事件安全分析
使用与图4-2类似的FTA进行安全分析，输出表4-18所示的单点故障和潜伏故障列表。
4.3.4 安全机制设计
分别设计单点故障和潜伏故障的安全机制，参见表4-19和表4-20。
4.3.5 其他
技术安全概念还应包含下列内容：系统降级策略；非功能相关的技术安全需求（试验需求、机械结构安装需求、硬件指标需求、共存需求、独立性需求等）；生产、运行、服务和报废需求规范；最终输出系统安全整体架构。
5 功能安全软件开发
VCU功能安全软件阶段设计按照V流程的步骤进行，包括软件需求分析、软件架构设计、软件单元设计、软件单元测试、软件集成等步骤，软件集成测试和嵌入式软件测试分别由HIL和实车测试工程师负责。
5.1 软件安全需求
本阶段定义或细化由技术安全概念和系统架构设计规范导出的软件安全需求，并描述软件实现所需的安全相关功能和特性。
5.1.1 需求列表
表5-1为软件需求列表的示例。
5.1.2 模式转换
主要用于描述当前系统不同行为模式（例如上电模式、下电模式、运行模式、故障模式等）及各个行为模式的功能，模式之间的切换条件等。
5.1.3 功能描述
对软件功能进行详细描述，表5-2为功能描述示例。
5.1.4 设计约束
设计约束包括功能启动时间、负载率、内存空间使用率、空间分配、共存需求和独立性需求等，表5-3为其设计示例。
5.2 软件架构设计
软件架构设计以层次结构的形式表示软件架构要素以及他们的交互方式。描述了静态方面，如软件组件之间的接口；动态方面，如进程序列和时序行为。
软件架构设计既要满足软件安全要求，又要满足其他软件要求。因此，在该子阶段中，与安全相关和非安全相关的软件要求在同一个开发过程中处理。
5.2.1 软件架构总体描述以及分层视图
本项目的软件架构基于AUTOSAR架构开发，应用层开发方式为基于模型设计（MBD），底层购买自第三方（ETAS AUTOSAR）。
VCU软件架构如图5-1所示。
5.2.2 软件组件设计
分别描述软件架构中各组件的组件描述、组件图和接口描述等，表5-4、图5-2、表5-5和表5-6分别为对应的示例。
5.2.3 动态行为
动态行为常见的描述方式有以下三种：时序图（Sequence Diagram）、活动图（Activity Diagram）和交互纵览图（Interaction Overview Diagram）。动态行为描述的对象基于系统级功能列表，对其功能进行描述。
图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.3.3 静态框图
可以通过约定的方式展示组件静态框图，包括组件内单元的结构关系及单元之间的接口，且保持整个组件设计与架构中组件定义保持一致。图5-4为静态框图示例。
5.3.4 单元接口
描述单元间输入、输出信息，或使用表格的形式展示，也可单独管理接口信息，参见数据字典。表5-8为软件单元接口示例。
5.3.5 动态行为
基于SWC在架构设计中的动态行为及要求实现的软件功能需求及非功能需求，描述组件内单元之间的动态行为；动态行为描述可以采用时序图、状态机等形式进行。图5-5为软件单元动态行为示例。
5.3.6 变量定义
描述本组件或某单元内部的局部变量、标定量、常量、宏、复合数据等；也可单独管理接口信息，参见数据字典。表5-9为变量定义示例。
5.3.7 配置项设计
描述可在线配置和离线配置的配置项，离线指修改参数后再次编译，在线是通过诊断服务的方式进行配置项修改。表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.4.2 软件单元测试用例和报告
表5-15为软件单元测试用例和报告的示例。
5.4.3 软件模型和代码静态验证报告
表5-16和表5-17分别为软件模型和代码静态验证报告的示例。
5.5 软件集成和验证
本步定义集成步骤并集成软件要素，直至嵌入式软件完全集成；验证是确保软件架构层面的安全分析得出的已定义的安全措施得到适当实施。
5.5.1 软件集成
软件集成的方法应定义和描述将各个软件单元分层集成到软件组件中的步骤，直到整个嵌入式软件全部被集成。
对于AUTOSAR工具链方式设计的车载嵌入式软件而言，软件集成主要包括基础软件模块间的集成以及基础软件与应用层软件的集成。
5.5.2 集成测试范围
表5-18为软件集成测试范围示例。
5.5.3 集成测试报告
与软件单元测试报告格式相同。
6 功能安全基础软件核心工作梳理
下面列出VCU功能安全项目基础软件的主要工作。
6.1 概念阶段
功能安全概念阶段基础软件工程师工作较少，主要是检查、学习相关项定义和功能安全概念开发，辅助绘制功能安全架构等。
6.2 系统阶段
功能安全系统阶段基础软件的工作如表6-1所列。
6.3 软件阶段
功能安全软件阶段基础软件的工作如表6-2所列。
7 项目总结
以上列出了新能源VCU功能安全项目的开发过程，下面简要做个总结。
7.1 标准与项目
功能安全规范只是一份指导性文档，学会满足功能安全的汽车电子设计方法离不开具体项目的工程实践，这个过程可以在专业咨询公司的指导下进行。
7.2 文档与程序工程
功能安全设计不仅仅是编写文档，而是借助文档制定安全目标、设计安全机制、再通过软硬件设计满足车辆安全性需求。最终输出的程序需要在经过HIL、实车测试验证后满足量产要求。
7.3 能力要求
从功能安全项目基础软件部分的工作看，Wdg模块开发需要具备MCAL设计能力；WdgM和E2E模块开发需要具备BSW设计能力；软件集成需要RTE设计能力；不同ASIL等级的任务分配需要OS设计能力；主控芯片和电源芯片安全机制实现需要手册研读和手工编程的能力......应用层软件与硬件工程师的工作也与之类似。因此，开发出一款满足ISO26262的车载ECU需要相关工程师具备全面的设计能力和文档能力。
功能安全不是一门单独的技术，而是软硬件设计的拓展和升华。
7.4 功能安全认证
最后聊一下车辆功能安全工程师考试。具备高含金量的功能安全证书考试具有较高的难度和巨大的题量（据说没有中国考生能做完题），并且考察的内容涉及到标准的各个章节（含术语、概念、系统、硬件、软件、生产等）。做项目肯定有分工，但如果想考证的话，标准各部分的重点知识要尽量多的掌握。
作者：李漠尘
文章来源：汽车电子与软件
推荐阅读
- 车载充电机 (OBC) 技术解读
- 小鹏、蔚来、比亚迪、智己、阿维塔、埃安、电子架构最新情况梳理
- 功能安全入门-功能安全岛(FSI)
- YOLO的探索从未停止 | YOLOBU利用自下而上的位置线索成就单目3D检测的SOTA模型
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
