1、概述
汽车行业的工程师们可能对E-GAS架构听得比较多，该概念提出的架构也常被称作 “三层电子架构” 或 “三层监控架构”，是EGAS工作组定义的一种标准化的传统燃油发动机控制系统架构设计模式，但其架构设计理念也适用于各类控制器系统，尤其是动力域相关的控制器系统。
E-GAS的文档，主要介绍了如下方面
1.1、术语介绍
1、driving cycle
在传统车的角度指的是发动机启动/停止之间的操作时间，对于纯电动来说由BMS指定。作为域控可以通过报文来解析获取该信息。
2、error or a single error
在需要考虑的特性里面至少有一个不能完全满足则可以定义为 error or a single error。
3、error
如果在下一个driving cycle没有发生，并且驾驶员或者是控制器也没有检测到相关故障，则这个error需要被定义为 潜在的error。
4、double error
需要定义为两个error，都发生几乎在同一时刻发生,并且这两个故障没有因果关系。
5、dual error
需要定义为两个single error，都发生(时间间隔超过一个很短的时间),并且这两个故障没有因果关系。
6、fault detection
当相关的系统参数超过允许偏差，导致不满足至少一个有关所考虑单元的要求特性的要求。这里设定一个检测时间。来减少误判，如果在这一事件内被检测到 则定义为已检测到错误。
7、failure effect
需要在无故障下和有故障下根据系统的具体特性偏差来指定。
8、failure reaction
在发生故障后，开始一套完整的手段响应，来减少故障带来的影响，将破坏降低到一个被允许的限度。
9、Controllable failure reactions
·响应时间
·整车行为限制，扭矩，转速，加速度等
10、Raw signals
·硬件寄存器采样的数字信号或者模拟信号
·总线当前的没有被更改过的数据
11、Reset
·SW reset 被软件控制的初始化 判断影响范围 （ram, rom, etc)
·HW reset 被硬件初始化 判断影响范围(看门狗，上下点，等等)
12、injection cut off (ICO)
(ICO)限制了发动机的最大额定转速(例如，通过切断与扭矩相关的路径)。
13、Pedal Value Sensor (PVS)
踏板值传感器(PVS)测量油门踏板的位置，从而衡量驾驶员的需求。
14、Timing Processing Unit (TPU)
时序处理单元(TPU)或其他具有时间或角度同步输入和输出的可比较的co/sub处理器。
这些与扭矩采集或扭矩转换相关(例如速度测量，启动喷射和火花输出阶段)。
1.2、开发指导基本原则
1、优先考虑保护生命，生命作为最重要的考虑点。
2、能用可靠性解决的不要使用退而求其次的备用方案。可靠性优先于备份功能。
3、检测机制应该独立于功能，并且尽可能的独立于驾驶员的反应。
4、系统监控包括故障响应，需要简单的，并且可控便于管理的。
5、系统设计应当使single error， error 发生或者同时发生时系统反应时可控的。监控的相关信号路径应该是从传感器，到执行机构，到功能层面都要被监控
6、就高系统可用性来说，应争取阶段性错误反应。
7、”confirmed defected", "explicit detection", "assumed defected"，当一个故障在被检测到后，过了系统定义的次数或者时间后变成了"explicit detection"。在reaction执行之前都被认为 "assumed defected"。
8、适当的reaction需要设计，当系统处于 "assumed defected"阶段。当然在”confirmed defected"这时候reaction是必须的。
9、reset这种故障响应，需要视情况而定，必须是可控的情况下。避免很多不连续的情况发生或者导致系统不连续的情况发生。
10、当系统不受控制，或者达不到可控的范围，这时候可以请求停机。这里的停机指的是将车辆请求到一个功能安全定义的安全感状态。
11、信号传输，发送方需要保证信号的有效真实完整性
12、当error发生，或者一系列的errors发生，系统出现了不可预测的响应，这时候需要提醒驾驶员。必要的时候改变驾驶形式。
13、监控功能需要有较高的鲁棒性，简单性
14、在每一次driving cycle前需要进行关断路径测试，检测其有效性。和科目三驾驶员绕车转一圈一个意思。
15、当检测到电源有问题后，关断路径的检测依然应该是可用的。需要对电源进行监控，避免损坏其他部件。
16、安全理念需要遵循ISO26262
1.3、系统定义
概念从下图简单系统定义进行说起，功能安全设计的最开始需要定义清楚每个部件的边界，以及系统边界图。
有了完整的系统边界图，才对下面的安全分析有方向性，和目标性。
1.4、危害（Hazard）分析和风险（Risk）分析
作为Hazard 和Risk 分析的一部分，分析了典型驾驶情况下系统的行为。基于上面的系统做了个简单的分析定义。并得出一下结果。这是从最顶层的分析结果。
安全目标
SZ-01 Prevention of unintended acceleration → ASIL B
防止意外加速→ASIL B
SZ-02 Prevention absence of acceleration → QM
防止加速度缺失→QM
SZ-03 Prevention of unintended deceleration → QM
防止意外减速→QM
SZ-04 Prevention absence of deceleration → QM
防止无减速→QM
2、功能安全概念
分析哪些部件可能导致车子无意识加速
1、错误的扭矩
扭矩来自于哪里发动机，电机，扭矩监控出问题，执行件出了问题。所以要对下面的component 进行一下安全要求(safety requirement)
2、sensor
在捕获信号后，可对传感器信号(例如驾驶员加速踏板需求)进行合理性检查。
3、actuators
执行器(A)在捕获执行器信号后，可以对执行器信号(例如油门位置)进行合理性检查。
4、Engine control unit
可以检测并确认不允许的高驱动扭矩设置
并将系统作为故障反应带入安全状态
安全概念采用了中央功能监控(2级)的理念。
发动机控制单元检测传感器系统故障。
发动机控制单元检测执行器故障。
在发动机控制单元中实现了安全概念
为了达到安全目标SZ-01，功能安全概念应提供对车辆允许加速度或允许驱动扭矩合规性的监控。
当车辆发生故障时，应在适当的容错时间内使车辆进入可控的安全状态。
安全要求分布在以下组件:
传感器(S1/S2):在捕获信号后，可对传感器信号(例如驾驶员加速踏板需求)进行合理性检查。
执行器(A)在捕获执行器信号后，可以对执行器信号(例如油门位置)进行合理性检查。
发动机控制单元(L):发动机控制单元检测传感器系统故障。发动机控制单元检测执行器故障。
在发动机控制单元中实现了安全概念，可以检测并确认不允许的高驱动扭矩设置，并将系统作为故障反应带入安全状态。安全概念采用了中央功能监控(2级)的理念。
Central 功能监控:
无论功能级别(1级)如何，被监控的功能都应在功能监控级别(2级)中进行计算，并在发生错误时将其控制在可控范围内。
独立开发确保系统错误不会对功能层(第1层)和监控层(第2层)产生相同的影响。应在控制单元中实施附加措施，以验证所应用ECU硬件的完整性。
应确保位于1级和ECU-HW中的错误不会对2级产生未被发现的影响。
3、技术实施
3.1、概述
GAS架构中三层架构的概念及特点。
- 第一层(Level 1) — 功能层（function level）
第一层用于实现控制器的基本功能，针对发动机控制器该层包含发动机控制功能，即执行要求的发动机扭矩、部件监控、输入/输出变量诊断，以及在检测到故障时控制系统的反应。
- 第二层(Level 2) — 功能监控层（function monitoring level）
第二层用于监控第一层功能实现的正确性，也即检测第一层的功能实现过程中是否有缺陷。例如通过监测第一层中计算的扭矩值或车辆加速度来判断扭矩是否符合预期，如果超出预期，系统会触发故障响应。
- 第三层(Level 3) — 控制器监控层（controller monitoring level）
第三层用于监控系统中控制器是否正确运行。用于监控控制器运行状态的监控模块应独立于控制器本身，通过某种机制(e.g. 问答机制)来检验控制器运行过程的正确性。
带锁阶核心(LC)的发动机控制器的三级概念
从上面分析，无意识加速时需要考虑的。需要被监控的。并且需要定义一个fault tolerance time(fft：容错时间)
3.2、实施细则
根据1.3章节的系统定义 下面的概念，以及设计都是为了达到SZ-01这个 GOAL 来实施的。
根据上个图 该架构示意图对应于VCU的系统架构框图如下：
经过分析该控制器的ASIL等级最高的一个安全目标为：
根据上方系统架构及基本功能定义，对 "SG01_避免非预期的加速" 做个快速FTA，以识别出架构中与该目标相关的要素，如下：
从上方简易FTA可知，以下事件将导致非预期加速：
1）加速踏板(Drive Pedal)输入过大 -> 加速踏板传感器；
2）外部请求扭矩过大 -> 外部ECU(e.g. EPS);
3）目标扭矩计算过大 -> EGAS处理器(e.g. EMS);
4）执行扭矩过大 -> 扭矩执行单元(e.g. MCU);
加速踏板传感器采集的踏板行程信号反映的是驾驶员的意图，即驾驶员踩下油门的深浅。
针对驾驶员意图，EGAS中给出了下方的驾驶员意图监控架构：
驾驶员意图最终也是以扭矩的形式表达，只不过在转换成扭矩之前须保证加速踏板信号采集的正确性(这在输入端代表了驾驶员意图的合理性)，这意味着加速踏板传感器需采用独立的冗余采集，以便处理器实施踏板信号的合理性检查。
关于实施功能监控的原则，EGAS监控概念中有这么段话可供参考：
Only components shall be considered now, which are relevant for monitoring and inherently present in the system. Implying that if a value cannot be directly monitored (according to the state-of-the-art), monitoring another physically correlated values may be also acceptable.
Jet Note: 在实施某个功能的监测时，如果一个值不能直接监测（根据现有技术），监测另一个物理相关的值也是可以接受的。比如单体电压和模组电压存在直接的换算关系。这个思想是非常重要的，既可用于设计诊断策略，还可以为ASIL 分解提供思路。
EGAS中对于扭矩管理功能的监控提供了两种监控架构，一是基于扭矩的监控，二是基于加速度的监控。
驾驶员的意图(demand)通过踏板(加速，制动)采集后其意图最终用扭矩表征，只不过扭矩和加速度之间存在一定的换算关系，故在实施扭矩监控时结合了这两者的监控逻辑。
这里不管是基于哪个信号的监控逻辑，都遵循一个监控原则，即扭矩连续。
Usage possible for all monitoring principles → continuous torque
这里的扭矩连续原则主要是出于加速踏板的动态特性考虑，它包含了几层含义：
1）扭矩连续但不可突变；
2）如果踏板行程维持在一个恒定状态，允许有较小的跳变；
基于此原则，实施扭矩管理时不允许出现不可控的加速度。
我们来看下EGAS中提到的扭矩监控架构和基于加速度的监控架构。
基于加速度/扭矩监控的实施原则：
An actual acceleration/drive torque shall be determined of the vehicle acceleration information from an acceleration sensor and the evaluation of the power train speed. The actual acceleration/drive torque shall be compared against the permitted acceleration/torque.
应根据来自加速度传感器的车辆加速度信息和动力传动系速度的评估来确定实际加速度/驱动扭矩，然后将实际加速度/驱动扭矩与允许的加速度/扭矩进行比较。
基于扭矩的监控架构
此架构的监控逻辑是比较独立计算得到的**“允许的扭矩”与“实际扭矩”**之间的差值是否超过限值。
基于加速度的监控架构
此架构的监控逻辑是比较独立计算得到的**“允许的加速度”与“实际加速度”**之间的差值是否超过限值。
车辆实际加速度和发动机转速应通过第2层中的冗余采集输入值进行监测。
如果当前车辆加速度高于目标车辆加速度，则第二层应在合适的时间内限制节气门角度。
Q: 上面的监控架构体现了架构设计上的什么特性？除了上面的监控方法还有没有其他监控方法？
接下来我们再看看EGAS的第三层在架构设计上是什么表现形式。
这一层用于监控系统中控制器是否正确运行，对应监控模块要独立于控制器，也即这一层的监控模块可独立控制执行器。
Controller monitoring refers to the interaction between software and hardware structures. It enables the detection of faulty operations of the function controller (controller core, affected areas in RAM/ROM).
Jet Note: 控制器监控功能的实现包括实施控制器处理器本身自带的控制器内部控制器诊断机制，即芯片自带的安全机制，这部分机制可以是硬件的(如ECC, BIST)，也是可以通过软件功能实现(e.g. range check)，或者两者的结合，具体可通过查看芯片的安全手册来获取。除了芯片自带的安全机制，还需要结合外部一个独立的监控器(monitor)来监控整个控制器的运行状态是否正常，即芯片自带的机制是用于检测芯片是否具备执行相关功能的能力(functioning ability)，而外部独立的monitor是对处理器运行过程中状态的在线监控(on-line monitoring)，检测的是处理器的正确运行的能力**(operating ability)**。
必要的检查可以作为软件功能（例如存储器测试值和补码）来执行，或者作为控制器内部错误检测硬件或两者的组合来执行。
Q: 基于上方关于第三层的控制器监控的描述，你认为要对控制器的哪些功能模块实施监控？
我们再看看上面的三层监控架构概念框图。
Level 3的监控功能主要由两部分组成，一是独立的监控模块(monitor module_MM)，一个是处理器内部自带检测电路及对应的检测软件模块(L3_SW)，这两部分相互结合实现对处理器functioning ability 和operating ability的监控。
一般地，控制器的最小系统的外设都需要被监控以保证functioning ability，整个处理器的运行逻辑需要被监控以保证operating ability。
- Memory Check — 内存检测
当在level 3中监控模块(L3_MM)中使用ROM/RAM部件时，这些部件应在每个驾驶循环中至少循环测试一次。
在可通过配置处理器内部自带的测试硬件(MBIST)对ROM/RAM进行上电自测，以及打开ECC机制对ROM/RAM进行周期性的测试。
EGAS中给到的Level 3的Memory test概念架构如下：
- Clock Fault Check — 时钟故障检测
安全处理器内部带有时钟监控器(clock monitor_CLKMON)用于监控时钟是否运行在指定的频率范围，还有就是结合外部监控模块(L3_MM)对时钟在系统层面进行逻辑监控。
外部监控模块(L3_MM)与处理器内部监控软件通过问答机制(Q/A)实现对处理器运行状态的监控，结合外部监控模块的时钟可实现对处理器执行程序流的监控，以及时钟频率正确性的系统层面监控。
- ADC Integrity check — ADC完整性检测
在初始化阶段ADC的完整性也要被检测，可通过处理器内部自带的参考电压或外部独立的某个高精度的电压源作为参考结合一定的检测逻辑来确认ADC的完整性。
也可以通过常用模拟量(如，电压、温度)的合理性检验来实现ADC完整性检测，这时电压(V)或温度(T)的初始值是经过标定后作为参考值用。
下方是ADC检测的一种流程，供参考：
除了上面提到的这些Level 3的监控功能，还有配置寄存器集(configuration set) 的正确性检测、安全关断路径(shut-off path)完整性检测等都是要在Level 3的监控概念中实施.
3.3、1级功能层
这里需要梳理清楚ECU 包含了哪些Level 1的功能，这里简化一下，简单列几个需要包括1、所有的Level 1 层的功能2、对监控从相关诊断的输入，输出定义。现在只考虑与监控相关且固有存在于系统中的组件。这意味着如果一个值不能直接监控(根据最新技术)，监控另一个物理上相关的值也是可以接受的。
sensor components：传感器组件
加速踏板传感器、制动开关、发送机转速信号、负载信号...
Actuator components：制动器组件
Signal paths in the ECU system compound：ECU系统中的信号路径复合
Protected shutoff paths of the cruise control：保护巡航控制的关闭路径
硬件特性以及诊断需求
这里需要列出上面需要被监控的components 的
特性
诊断的points
检测的方式
故障的描述等等
3.4、2级功能监控
对于具有扭矩监测的系统，第2级的中心部分应是单独计算的“允许发动机扭矩”和“实际发动机扭矩”之间的比较。
2级加速监控系统的中心部分应该是单独计算的“允许车辆加速度”和“实际车辆加速度”之间的比较。
监测第1级故障反应，如果L2不能单独产生故障反应。
拥有周期性监控的内存区域计算程序流控制
举个Level 2层监控加速度的例子。
基本原理就是实际的和可能的/合理的/设计的计算进行对比。就得出了L2层的结果。
其他的一些monitor 也是使用类似的机制。这里不进行一一截图。截一张官方给的具体示例图监控加速度。
这一整套需要从最初开始的传感器，一直到实际的车速扭矩等信息的采集。整条链路需要从最上层车的级别去分析，然后深入到最终实现车运动这个动作的部件的角度来分析。
就比如从最上端的理论支撑，哪些部件涉及到。
下图是：新的加速安全概念(A-SaCo)
3.5、3级控制器监控
控制器监控是指软件和硬件之间的相互作用。
它可以检测功能控制器(控制器核心，RAM/ROM中受影响的区域)的故障操作。
必要的检查可以作为软件功能(例如存储器测试值和补码)或控制器内部错误检测硬件或两者的组合来执行。
只有在以下情况下才允许由控制器内部错误检测硬件进行检查
控制器内部错误检测硬件在当前周期内的工作能力
应通过对潜在缺陷的测试来验证(例如，在关机路径上渗透ECC)。只有在完成此试验后，才允许发动机启动。
控制器内部错误检测硬件的配置是周期性测试的(例如激活ECC)。
一般有一下方面：
1、ROM检测
在发动机启动前(初始化或前一个驱动周期，包括后续)，必须至少检查一次完整的ROM。测试可以通过软件功能或控制器内部错误检测硬件来执行。2级和3级的ROM范围需要定期检查。测试可以通过软件功能或控制器内部错误检测硬件来执行。
ROM测试至少必须检测到以下错误:
·由于寻址错误导致的2/3级代码/数据错误(HW)
·ROM中的位转储器
·不正确的ROM编程(例如，闪烁)
2、检测QA机制
程序流监控、指令集测试、功能指令集、原子指令集、控制器内部故障
3、采样的检测 – AD转换等
4、reset 系统特性
下图为综合L1,L2,L3 直至整车reaction的路径图。每一个步骤都需要下一层的保障。
下图为故障监控显示
可以说L3层更多的是机制本身的实现与确保。对板本身的监控与测试。
下图为芯片层级监控。
下图为内存测试图示
下图为内存错误之后做出的反应
