01 E-GAS 安全架构思想
汽车功能安全旨在把电子电气系统失效而导致的人身危害风险控制在合理范围内。下图是常见的电子电气系统硬件构成图，一个电子电气系统的构成要素，除了图中可见的硬件外，也包含图中不可见的软件。
图1 常用电子电气硬件系统
电子电气系统的失效，既包含由于软硬件设计错误引起的系统性失效，也包含由随机硬件故障引起的失效。根据系统架构，需要设计各种安全机制去预防和探测功能故障，并能够在故障发生时，避免或者降低危害的发生。这就需要一个强壮的功能安全软件架构来管理和控制这些安全机制，降低功能安全整体开发难度。
目前，E-GAS（Standardized E-Gas Monitoring Concept for Gasoline and Diesel Engine Control Units）无疑是当前使用最为广泛的一个安全软件架构方案。虽然 E-GAS 最初只是针对汽 / 柴油发动机管理系统而提出的安全架构方案，但是经过简单的适配，也可以用于车身系统，变速箱系统以及新能源的三电系统等，具有非常良好的扩展性，应用非常广泛。
下图是 E-GAS 的三层软件架构设计方案，从上到下，软件分为 Level1~3 总共三层，Level1是功能实现层（function level），Level2 是功能监控层（function monitoring level），Level3 是控制器监控层（controller monitoring level）。该架构形成了很好的分层监视框架，并有效实现了功能安全分解，通常采用 QM（ASIL X） + ASIL X（ASIL X）的安全分解策略，即将功能实现软件（Level1）按照 QM 等级开发，功能冗余软件或安全措施（Level2、Level3）按照最高的要求等级 ASIL X（ASIL X）进行开发，这样可以有效降低功能软件的安全开发成本。
图2 E-GAS三层监视架构方案
Level1 功能实现层
Level1 是功能实现层，完成具体的功能实现，比如对于电机控制器来说，这一层实现了将请求的扭矩转换为电机的扭矩输出。
Level2 功能监控层
Level2 是功能监控层，用于监控 Level1 功能的运行是否正常。Level2 的核心是设计一套方法去判断Level1 的运行是否正常。虽然判断 Level1 运行是否正常的方法，往往跟被监控的功能相关，不同被监控功能有不同的判定方法，比如 : 通过软件多样化冗余。但也有一些适用范围较广的判断方法，比如合理性校验。
图3 合理性检查
如上图 所示，Level2 在使用合理性校验方法判断 Level1 功能是否正常运行时，先根据传感器输入的信号，计算控制量允许输出的合理范围，再计算从执行器反馈的实际输出量，最后判定 Level1 的实际输出量是否在允许的合理范围，如果超出了合理的范围，则判定 Level1 功能异常，执行错误处理。
Level3 控制器监控层
Level3 是控制器监控层，主要由三部分功能构成。
电子电气系统硬件诊断：监控电子电气系统硬件故障，比如 : 控制器的 CPU 核故障、RAM 故障、ROM 故障等。
独立监控：控制器相关的故障发生后，此时控制器已经无法可靠地执行安全相关逻辑，为了保证安全性，需要外部额外的独立监控模块，来确保即使 MCU 发生严重故障后，依然能够进入安全状态。这个额外的独立监控模块，通常是集成看门狗的电源管理芯片。
应用程序流检查：监控 Level1 和 Level2 的监控程序是否运行正常。该监控功能通过将程序流检查和看门狗喂狗绑定实现。如果 Level1 和 Level2 相关的监控程序没有按照设定的顺序运行，或者没有在规定的时间内执行，则程序流检查失败，无法正常喂狗，从而进入系统安全状态。
图4 Level3功能框图
02 国外功能安全软件架构发展情况
提到功能安全与软件架构，我们可以从 “符合功能安全的软件架构” 和 “功能安全软件架构” 这两个维度去看待它们之间的关系。
前者侧重点是从软件开发角度看我们的软件架构设计过程对功能安全的符合性，也就是我们的软件架构设计过程需要满足 ISO 26262 提出的各种要求，如：标记方法、设计原则、设计要素要求、安全分析要求、错误探测机制要求、错误处理机制以及设计验证方法等，其中，软件架构层面的安全分析主流手段是“软件 FMEA（Failure Mode and Effects Analysis）” 和 “软件 DFA（Dependent Failure Analysis）” 。
后者侧重点是从嵌入式软件系统角度看对系统级功能安全的支撑。基于 E-Gas 安全架构的思想，我们认为 “分层监视思想” 、“安全措施” 和 “诊断框架” 是 “功能安全软件架构” 的核心，“分层监视思想”和 “安全措施” 在上文有说明，本节接下来内容主要围绕 “诊断框架” 进行说明。无论我们使用的基础软件开发平台是 AUTOSAR CP、AP 或者是非 AUTOSAR，功能安全软件架的设计思路是类似的，这里基于 AUTOSAR CP 进行说明。
1） 功能安全诊断框架技术要求
图5 故障响应时间和容错时间间隔
我们结合 FTTI（故障容忍时间间隔，fault tolerant time interval）理解故障诊断过程。从故障发生到产生可能危害之间的这段时间就是 FTTI 时间，此期间主要有诊断测试、故障响应过程，并且希望在产生可能危害之前进入安全状态 ( 图 4.1-8)。诊断测试过程需要考虑诊断测试触发、故障确认（去抖）等，
故障响应过程需要考虑进入合理的操作模式（如：Fail safe, Fail operational, Emergency operation 等）、故障存储等。
综上，“诊断框架” 的核心设计需要考虑覆盖诊断测试、故障响应过程。主要的功能安全诊断框架技术要求有：
- 故障统一管理：对 E-GAS 多层监视框架各故障监视层上报的故障进行状态统一管理
- 故障响应时间要求：故障检出到进入安全状态需满足故障容忍时间间隔（FTTI）的要求
- 独立性要求：片上安全机制与功能存在共因问题，需支持独立性监视（MCU 片外监视）
- 多样化要求：软件架构须满足框架设计通用化和支持安全策略多样化（不同项目对安全机制有不同要求）
- 诊断测试时机：上下电，周期，条件触发等
- 故障去抖 / 延时检查：需支持安全机制的去抖测试功能，至少支持基于时间和基于计数去抖算法
- 诊断事件和功能解耦：诊断事件和功能独立管理，之间存在映射关系
- 故障存储：支持故障信息非易失存储
2） 国外诊断框架技术情况解读
在对诊断框架技术展开解读之前，有两个方面的建议供参考。
① 建议 1：根据需求确定诊断测试的时机
a. 上电时：这里结合一个典型应用需求进行说明。安全机制（safety mechanism）和对应的功能构成了双点，为了降低潜伏多点故障失效率，一般在系统启动阶段（上电时），安全机制需要做自检。此外，在多处理器系统中还需要考虑诊断测试同步问题。
b. 运行时：一般分周期性诊断测试和条件诊断测试。诊断周期的定义需要考虑 FDTI（fault detection time interval）的约束，而条件诊断测试一般是发生状态迁移时或在激活某个功能前对功能进行的诊断。
c. 下电时：可以选择执行一些比较耗时的测试，而测试结果一般放在下一次启动时处理。
② 建议 2：进行分组诊断测试
为了便于诊断管理（包括诊断触发和故障响应等），根据临界故障 / 非临界故障，诊断测试时机等因素进行分组。上电时如果检出临界故障（Critical fault），比如：核故障（Core Fault）、易失性存储器测试故障（Ram Test Fault）等，这时故障响应可以选择处在一个静默状态处理（如：MCU 处在连续复位状态）。
图6 “功能安全诊断框架”与“功能安全诊断控制流”
E-Gas 三 层 监 视 框 架 的 Level1(function level） 及 Level2(function monitoring level） 位 于 ASW(application software, 即 : 图 4.1-9 中 的 SWC) 层，Level3(controller monitoring level） 位 于BSW(basic software) 层。“诊断框架” 同样也位于 BSW 层，如上文所述主要覆盖诊断测试、故障响应过程，下文对其构成和工作过程展开介绍：
- BswM、 EcuM 主要负责上下电管理，在 STARTUP、UP、SHUTDOWN 阶段分别进行上电时、运行时、下电时的诊断测试
- ASW-Level1（E-Gas Level1）覆盖功能输入 / 输出的诊断；ASW-Level2（E-Gas Level2）一般实现为 ASW-Level1 功能的冗余算法，实现 ASW-Level1 ASIL 等级的分解；TestLib（E-GasLevel3）监视 ECU、MCU 层面的硬件失效（建议参考 ISO26262(2018)-Part5 Annex D 及 MCU安全手册），覆盖 Level1 和 Level2 共因失效的诊断，并和 “监视控制器” 实现用于逻辑及时间独立性诊断的问答看门狗机制
- TestManager 负责对 TestLib 安全机制的诊断测试触发及相应测试结果的收集
- DEM 收集 E-Gas Level1/2/3 的测试结果，诊断事件去抖，标记故障码及通过 NvM 进行故障信息存储。FiM 根据 DEM 诊断测试结果（去抖后）标记已配置的功能，功能软件（ASW-Level1）根据标记来决定对功能的抑制。
