E-GAS安全架构思想

9月18日，在 “2022世界智能网联汽车大会” 上，中国汽车工业协会软件分会理事长、AUTOSEMO轮值主席、中汽创智CEO李丰军先生代表AUTOSEMO通过视频的方式发布了《中国汽车基础软件发展白皮书3.0》。 本文节选自此次发布的白皮书，主要介绍功能安全软件架构。  

1. 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三层监视架构方案

（1） Level1 功能实现层

Level1 是功能实现层，完成具体的功能实现，比如对于电机控制器来说，这一层实现了将请求的扭矩转换为电机的扭矩输出。

（2） Level2 功能监控层

Level2 是功能监控层，用于监控 Level1 功能的运行是否正常。Level2 的核心是设计一套方法去判断Level1 的运行是否正常。虽然判断 Level1 运行是否正常的方法，往往跟被监控的功能相关，不同被监控功能有不同的判定方法，比如 : 通过软件多样化冗余。但也有一些适用范围较广的判断方法，比如合理性校验。

图3 合理性检查

如上图 所示，Level2 在使用合理性校验方法判断 Level1 功能是否正常运行时，先根据传感器输入的信号，计算控制量允许输出的合理范围，再计算从执行器反馈的实际输出量，最后判定 Level1 的实际输出量是否在允许的合理范围，如果超出了合理的范围，则判定 Level1 功能异常，执行错误处理。

（3） Level3 控制器监控层

Level3 是控制器监控层，主要由三部分功能构成。

电子电气系统硬件诊断：监控电子电气系统硬件故障，比如 : 控制器的 CPU 核故障、RAM 故障、ROM 故障等。

独立监控：控制器相关的故障发生后，此时控制器已经无法可靠地执行安全相关逻辑，为了保证安全性，需要外部额外的独立监控模块，来确保即使 MCU 发生严重故障后，依然能够进入安全状态。这个额外的独立监控模块，通常是集成看门狗的电源管理芯片。

应用程序流检查：监控 Level1 和 Level2 的监控程序是否运行正常。该监控功能通过将程序流检查和看门狗喂狗绑定实现。如果 Level1 和 Level2 相关的监控程序没有按照设定的顺序运行，或者没有在规定的时间内执行，则程序流检查失败，无法正常喂狗，从而进入系统安全状态。

图4 Level3功能框图

2. 国外功能安全软件架构发展情况

提到功能安全与软件架构，我们可以从 “符合功能安全的软件架构” 和 “功能安全软件架构” 这两个维度去看待它们之间的关系。

前者侧重点是从软件开发角度看我们的软件架构设计过程对功能安全的符合性，也就是我们的软件架构设计过程需要满足 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）根据标记来决定对功能的抑制。

AUTOSEMO背景

在全球汽车产业以电动化、智能化、网联化、共享化为代表的“新四化”的趋势下，智能化已成为汽车工业发展不可逆转的趋势。“软件定义汽车”已经成为全企业的战略共识，软件在整车成本中所占比重逐年增大，成为企业核心价值和战略制高点。汽车创新的主要方向，包括自动驾驶在内的大量车内的软件由于高度的复杂性，将很难由单一的整车企业或零部件供应商独立完成，同时大量新的传感器和控制器以及专用芯片也开始出现在汽车的硬件平台上，整车企业希望能够快速的将这些新的硬件和功能应用到车辆的系统中，并能够通过不断的软硬件升级给客户带来新的体验。为了顺应全球变革带给中国车厂的影响，对于本土车厂对智能网联、自动驾驶的需求。鼓励发展具有我国自主知识产权的汽车基础软件生态体系尤为重要，是解决中国汽车产业做大做强的坚实基础。

鉴于中国汽车基础软件发展的重要性，应国内主要汽车企业的要求，并经主管部门认可，中国汽车工业协会（以下简称：中汽协），于2019年12月决定组建中国汽车基础软件生态委员会（英文China Automotive Basic Software Ecosystem Committee，简称AUTOSEMO）。旨在联合汽车及软件产业内的成员，形成由本土企业主导的共同规划和创建适应新需求的软件架构和接口规范，做强本土基础软件，推动行业开放和协作，促进产业向更智能化的方向发展。在当前复杂多变的国际产业竞争趋势下，设立AUTOSEMO具有十分重要的战略意义和现实意义。

审核编辑 ：李倩