2024年网络安全最全功能安全软件架构_软件安全架构

目前，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 相关的监控程序没有按照设定的顺序运行，或者没有在规定的时间内执行，则程序流检查失败，无法正常喂狗，从而进入系统安全状态。

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）的约束，而条件诊断测试一般是发生状态迁移时或在激活某个功能前对功能进行的诊断。

给大家的福利

零基础入门

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

同时每个成长路线对应的板块都有配套的视频提供：

因篇幅有限，仅展示部分资料

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！