e-GAS 三层监控架构 — Powertrain / EV 的 ASIL-D 骨架

功能安全L2别名 e-GAS · EGAS · E-Gas · E-Gas Konzept · AKEG · Arbeitskreis EGAS · three-level monitoring · 三层监控架构 · 扭矩监控 · TMS · Torque Monitoring System · Level 1 functional · Level 2 monitoring · Level 3 watchdog · Q&A watchdog · 问答看门狗 · Powertrain safety architecture · 动力总成安全架构 · unintended acceleration · 意外加速防护相关[[topic-ev-safety-development-flow]][[topic-asil-d-case-studies]][[topic-current-sensing-safety]]

本质与导读

本质 e-GAS 的三层监控源于德国汽车工业为防"意外加速"(unintended acceleration)的标准化安全架构,如今所有 ASIL-D 动力总成 ECU 都沿用同一骨架。核心是三套独立的故障假设、检测与 safe state 切换:L1 主功能、L2 用简化算法独立验证 L1、L3 用外部 SBC 监控整个 MCU 是否还活着。ISO 26262 未明文要求三层,但工业界默认 ASIL-D = 三层,因为只有这样才能同时覆盖 systematic 与 random 失效。

核心要点

三层 = 三种独立故障假设 — L1 应用代码错 / L2 内存翻转 / L3 整 MCU 死
L2(TMS)是 e-GAS 的精髓 — 在同一 MCU 上跑"驾驶员意图"简化模型,交叉验证 L1 输出
L3 = SBC + Q&A WD — 物理独立芯片 + 问答式看门狗,捕获 MCU 卡死 / 时钟错 / clock-storm
FFI 是关键挑战 — L1 / L2 同一芯片,要靠 MPU + 不同 task period + 不同 ADC channel 实现 freedom from interference
ASIL 分配:L1 = QM~ASIL-B,L2 = ASIL-D,L3 = ASIL-D(SBC 硬件资质)
典型 PFH < $1 0^{- 8}$ /h — 三层组合达到 ISO 26262 ASIL-D 随机硬件失效目标
历史标准:AKEG (Arbeitskreis EGAS) 工作组 v6.0 (2015),Bosch / VW / BMW / Daimler / Audi 共同制定

主线坐标:横轨 · 功能安全(跨站) · ↑ 全景主线

1. 历史背景 — 为什么会有 e-GAS

1990 年代电子节气门(drive-by-wire throttle)取代机械拉线时,安全工程师面临前所未有的问题:软件 bug 可以直接造成 100% 油门。机械拉线时代,司机松脚就一定收油,而电子节气门一切由 ECU 软件决定。2002-2005 年间欧洲多起"意外加速"事件,促使 Bosch 主导、VW/BMW/Daimler 参与的 AKEG (Arbeitskreis EGAS) 工作组在 2003 年发布第一版三层监控概念,2015 年定到 v6.0。

虽然 e-GAS 表面只是"节气门安全",它的真正贡献是把"如何在不可信的复杂软件上构建可信子系统"这个问题给出了工程答案。这套答案后来被 ISO 26262 第 5/6 部分内化为标准做法,也被 AUTOSAR Powertrain Profile 和所有现代 EV inverter / BMS / EPS 沿用。

e-GAS ≠ ISO 26262…

e-GAS ≠ ISO 26262 e-GAS 是架构模式(具体怎么搭),ISO 26262 是流程标准(怎么开发)。两者不冲突 —— e-GAS 提供了 ISO 26262 ASIL-D 最常见的实现样式,但不是唯一。也有 lockstep dual-core(双核同步比对)作为替代方案,代价是芯片成本翻倍。

2. 三层总览

整个架构看一张图就清楚:

e-GAS 三层监控总览

三层各自负责一种故障检测,它们的输入、算法、芯片资源都尽可能独立,这样才能保证"任何一层失效时,其他两层独立工作把系统切到 safe state"。

层	位置	角色	代码量	ASIL
L1	主 MCU	完整 powertrain 功能	~ 95%	QM ~ ASIL-B
L2	主 MCU(独立 task)	扭矩监控 TMS	~ 5%	ASIL-D
L3	外部 SBC	整 MCU 健康监控	固件	ASIL-D(硬件资质)

注意 L1 的 ASIL 标 "QM ~ ASIL-B" 而不是更高 —— 这是 ASIL 分解 的力量:L1 通过 L2 监控被"提升"到等效 ASIL-D 系统级别,而 L1 自己可以以较低的 ASIL 开发,大幅降低成本。详见 topic-asil-decomposition。

3. Level 1 — 主功能(可能 buggy)

Level 1 承载完整的 powertrain 控制策略 —— 油门解析 / map / PID / 动态补偿 / 能量回收 / OBD 等所有"看得见"的功能。它的代码量大、依赖第三方库、需要频繁标定迭代 —— 这些特征注定它不可能做到 ASIL-D 流程(那样开发成本会十倍化)。

L1 自己做基本的输入检测:

range check — 每个 sensor 读数在合理范围
rationality check — 多源交叉检查(双 pedal 误差 < 5%)
sensor diagnostic — 短路 / 开路 / 卡值检测

但 L1 不验证自己的输出 —— 那是 L2 的责任。L1 检测到 sensor fault 时,典型反应是 降级运行(limp-home,扭矩限制 30%,转速限制 3000 rpm)+ 写 DTC + 点 MIL 灯。

4. Level 2 — TMS(扭矩监控系统)— e-GAS 的精髓

Level 2 是整个架构最值得理解的部分。它和 L1 跑在同一 MCU上,但执行完全独立的任务:计算驾驶员意图允许的扭矩上限 $T_{perm}$ ,然后验证 L1 输出的 $T_{req}$ 不超过它。

Level 1 vs Level 2 — TMS

4.1 输入精简 — 仅 pedal + brake

L2 故意只用最少、最可信的输入:

加速踏板(独立 ADC channel,与 L1 共享物理传感器但 ADC 路径独立)
制动开关(物理触点,高可信)
gear lever 位置(P/R/N/D)

不用复杂 CAN 状态(BMS / VCU)—— 因为 CAN 故障会传染给 L1 和 L2,无法独立。

4.2 算法极简 — 线性映射 + 安全余量

L2 的核心算法是一个分段线性 / 查表的"驾驶员意图模型":

T_{perm} = f_{simple} (α_{pedal}, ω_{motor}) + Δ_{margin}

其中 $f_{simple}$ 是简化版的 driver intent map, $Δ_{margin}$ 是 $5$ - $10%$ 的安全余量,确保 L1 在正常工况下不会被 L2 误判。

特殊规则:

brake override:任何 brake-on → $T_{perm} = 0$ (无条件)
direction lock:gear = P/N → $T_{perm} = 0$
OEM-specific clamp:某些主机厂要求倒车扭矩 < $20 Nm$

4.3 交叉验证 — 不等不行,等多了也不行

每个周期,L2 算出 $T_{perm}$ ,与 L1 输出的 $T_{req}$ 比较:

if T_{req} > T_{perm} + Δ_{detect} for > t_{debounce} \to fault

$Δ_{detect}$ 是"误判防抖"阈值(典型 $5$ - $10 Nm$ ), $t_{debounce}$ 是连续违例时间(典型 $50$ - $100 ms$ )—— 避免单次 noise 触发误关 inverter。

L2 检测到 fault 后:MCU 自己 cut PWM 输出 / 切到 fail-silent state / 等 MCU reset。L2 不直接关电源(那是 L3 的事)。

4.4 FFI — 同一 MCU 如何独立?

这是 e-GAS 最巧妙的部分。L1 / L2 都在同一颗 MCU 上,但通过多重隔离实现 freedom from interference:

维度	实现
空间隔离	MPU 划分 RAM/ROM 区,L1/L2 不能互写
时间隔离	OS time-slice,L1 = 1 ms / L2 = 5 ms 不同 task
数据隔离	独立 ADC channel / 独立 CAN handler / 独立 EEPROM region
代码隔离	L2 用独立 compiler 选项 / 独立单元测试 / 形式化验证
时钟隔离	L2 周期由独立 timer 触发(不依赖 main clock 中断)

典型 MCU 资源占比:L2 用 < 5% CPU + < 10% RAM,但开发成本占整个 ECU 软件的 30-40%(因为 ASIL-D 流程贵)。

5. Level 3 — SBC Q&A Watchdog

L1 和 L2 都是软件,任何软件都依赖底层硬件正常工作。如果 MCU 本身死机(clock 错 / 内存 ECC 错 / 中断风暴 / 电源故障),L1 / L2 一起失效 —— 这时候必须有"外部观察者"判断 MCU 还活着没。这就是 Level 3 的角色,由物理独立的 SBC(System Basis Chip)承担。

Level 3 SBC Q&A Watchdog

5.1 Q&A WD vs 普通 WD

普通 watchdog 只要 MCU 定时 "kick" 一次就 OK —— 但这无法检测程序卡在错误循环里也定时 kick 的情况。Q&A WD 引入"挑战-应答":

SBC 用 LFSR + counter 生成 question $Q k$
MCU 读 $Q k$ ,运行约定的函数 $f$ ,算出 answer $A k = f (Q k, seed)$
MCU 在指定 timing window 内 SPI 写回 $A k$
SBC 验证 $A k$ 是否正确

错答 / 早答 / 晚答都算 fault。 $f$ 函数必须包含程序执行流程的状态(如关键 task 完成标志),这样卡死的程序无法算出正确 answer。

5.2 window-based timing

时间窗约束是关键:

closed window(前段):MCU 不应该 refresh,过早 = fault
open window(中段):MCU 必须 refresh
错过 open window = too late = fault

这样**任何"卡循环导致提前 refresh"或"任务挂起导致漏 refresh"**都被精确检测。

5.3 INIT_FS 与运行容忍

上电启动时,MCU 还在初始化,可能错过几次 Q&A —— SBC 允许 7 次连续错误(INIT_FS 阶段)。运行中容忍下降到 3 次 —— 任何 3 次错答触发 RSTB(MCU reset)+ 重新进入 INIT_FS。

如果 reset 后连续多轮 INIT_FS 失败,SBC 拉 FS0B (fail-safe output B) 低,直接关 gate driver power,整车进 fail-safe 状态。WDT 详细原理与 SBC 实现见 topic-sbc-mc33907-design。

6. 三种 powertrain 映射

e-GAS 框架在不同动力系统中的具体实现:

e-GAS 在不同 powertrain 的映射

6.1 燃油 ICE — 原始出发点

控制变量 = throttle 角度。

L1:油门 + 转速 → throttle map + 喷油 + 点火
L2:油门 → 允许 throttle 上限, $T_{req}^{throttle} > T_{perm}^{throttle}$ → fault
L3:SBC 关 throttle motor 电源 → throttle 弹簧复位到 ICE 怠速位

ICE 的优势是有机械备份(throttle 复位弹簧),即使整个 ECU 死机,机械结构自动回到安全状态。

6.2 混动 HEV / PHEV — 双源扭矩

控制变量 = $T_{ICE} + T_{motor}$ 。

L1:复杂能量分配(发动机 + 电机)+ 充放电策略
L2:油门 → 总驱动扭矩上限 $T_{wheel}^{perm}$ , $T_{ICE} + T_{motor} > T_{perm}$ → fault
L3:SBC 在 HCU(混动控制器)+ MCU 双方,关 inverter PWM + ICE 进 limp-home

混动复杂之处在于两个扭矩源都要算到总和里,任何一方失控都可能造成总扭矩超限。L2 必须能同时拿到 ICE 和 motor 的"声明扭矩"做加总验证。

6.3 纯电 BEV — 最严格

控制变量 = $i q \times ψ$ (电机磁链)。

L1:FOC + MTPA + 弱磁 + SVPWM
L2:油门 → $T_{motor}^{perm}$ , $∣ i q ∣ \times ψ > T_{perm}$ → ASC(三相短路 / Active Short Circuit)
L3:SBC 关 gate driver power → 全部 SiC MOS OFF → free-wheel diode 续流

BEV 没有机械备份 —— 一旦 inverter 失控,唯一的安全状态是 ASC(三相短路)或 FW(自由轮),具体选哪个根据车速:

低速(< 50 km/h):FW 安全(free-wheel,电机被动旋转无扭矩)
高速(> 50 km/h):ASC 安全(三相短路,电机产生制动扭矩防超速)

详见 topic-asil-d-case-studies 中的 EV inverter 安全状态切换。

7. unintended acceleration — 三层共同对抗的核心故障

e-GAS 设计的核心 use case 是"意外加速",即驾驶员没踩油门,车却加速。下面给出 4 类故障假设,展示三层如何协同:

假设	故障描述	哪一层捕获
1	pedal 物理卡住 100%	检不出 — pedal 信号本身正确,car 应该加速
2	L1 输出 80% 扭矩但 pedal = 0%	L2 — TMS 检测 $T_{req} > T_{perm} = 0$
3	MCU 死机 / clock 错	L3 — Q&A WD 失败 → FS0B
4	SBC 自己坏	MCU 反查 SBC heartbeat + 两 SBC 互监

假设 1 不属于 ECU 责任(机械故障),其他三类都被三层覆盖。

假设 4 — SBC 自己坏怎么办…

假设 4 — SBC 自己坏怎么办 ISO 26262 要求 ASIL-D 系统对所有元件做单点失效分析。SBC 自身故障的检测靠两条:(a) MCU 定期读 SBC status register,任何不一致 → MCU 直接进 safe state;(b) 高端方案用两颗 SBC 互监(罕见,成本高,仅航空 / 国防 / 大客)。Tesla / 比亚迪 / 宁德 EV 主流方案是 (a),配合 SBC 出厂级 ISO 26262 ASIL-D 认证。

8. ASIL 分配实战

e-GAS 三层在 ASIL 分解中的典型分配:

系统目标	ASIL	拆解到
防止 unintended acceleration	ASIL-D	L1 (ASIL-B) + L2 (ASIL-D)
防止 MCU 死机 → 黑屏	ASIL-D	L3 (ASIL-D)
OBD 诊断完整性	ASIL-A	L1
Functional 标定一致性	QM	L1

ASIL-D = ASIL-B + ASIL-D(ASIL-B) 的合理性:两层独立(FFI 已保证),且 L2 是 ASIL-D —— 这满足 ISO 26262-9 的 ASIL 分解规则。

具体到开发流程:

L1:V-model + 单元测试 + 集成测试 + HIL(常规汽车软件流程)
L2:加 形式化验证 / 100% MC/DC coverage / 独立 review / 独立 timing 分析
L3:SBC 厂商提供 ASIL-D 资质 + 安全手册,集成方做端到端验证

9. 常见误区

工程实践中最常见的几个错误,绝大多数源于"没理解三层独立性的根本目的"。下面 6 条来自实际项目复盘和 ISO 26262 audit 反馈。

❌ "L2 算法越复杂越好" — 恰恰相反,L2 必须简单到可以形式化验证。复杂 L2 = 失去 L2 的意义
❌ "L1 和 L2 共享 driver intent map" — 必须独立 map,否则 map 错误同时影响两层
❌ "L3 用 MCU 内部 WDT 就够" — 内部 WDT 在 MCU 故障时也会失效,必须外部 SBC
❌ "三层都用同一个时钟源" — clock 错时三层一起死,L3 必须独立 oscillator
❌ "QM ASIL-B 等于 ASIL-D" — 不对,ASIL 分解要求 FFI + 独立性证明,不是数学加法
❌ "lockstep 双核可以替代三层" — lockstep 解决随机失效,但不解决 systematic(软件 bug)失效。需要双核 + 独立软件版本才等价 e-GAS

10. 工程 cheat-sheet

下表压缩 e-GAS 在产品开发中的关键决策点,按时间顺序排列。

阶段	决策点	推荐做法
概念	选 e-GAS vs lockstep	单 MCU + SBC = e-GAS(主流);双核 lockstep = 大功率高安全
概念	ASIL 等级	动力 = ASIL-D;辅助 = ASIL-B/C
架构	选 SBC	NXP MC33907_8(主流)/ TI TPS65381 / ST L9788
架构	L2 算法策略	分段线性映射 + brake override + 5-10% margin
软件	L1/L2 隔离	MPU + 不同 task period + 独立 ADC + 独立 timer
软件	L2 验证	100% MC/DC + 形式化验证 / 独立 reviewer
集成	Q&A WD 参数	INIT_FS 7× / 运行 3× / window 5-10 ms
测试	fault injection	软件 bit-flip / clock stuck / SBC SPI error
认证	文档	ISO 26262 Part 9 ASIL 分解 work product

11. 自检题

按章节顺序的 10 题,前 4 题考三层角色,5-7 考 FFI + Q&A,8-10 考 ASIL 分配 + EV 应用。

e-GAS 全称是什么?哪个工作组制定?
Level 1 / 2 / 3 的代码量比例约为多少?ASIL 等级分别是?
为什么 L2 算法必须简单,不能用复杂 PID?
brake override 在 L2 是怎么实现的?为什么用物理开关而非 CAN?
同一 MCU 上的 L1 / L2 通过哪 5 种维度实现 FFI?
Q&A WD 的 closed window 和 open window 各自含义?
INIT_FS 阶段允许 7 次错答,运行中允许几次?为什么不同?
ASIL-D = ASIL-B + ASIL-D(ASIL-B) 的合理性?需要满足什么前提?
BEV 失控时,低速和高速的 safe state 各是什么?
lockstep 双核能否完全替代 e-GAS?有哪个 ASIL 维度不覆盖?

Cross-references

← 索引
topic-functional-safety — ISO 26262 总体流程
topic-asil-decomposition — ASIL 分解规则与 e-GAS 的关系
topic-functional-safety-chip-selection — SBC 与 MCU 选型
topic-sbc-mc33907-design — Level 3 SBC 硬件实现(NXP MC33907_8)
topic-ev-safety-development-flow — EV 整车功能安全开发流程
topic-asil-d-case-studies — ASIL-D 工程实例(含 e-GAS 应用)
topic-current-sensing-safety — TMS 的 motor 电流测量冗余