[L4级功能安全]第3期：防患于未然——L4场景下的危害分析与风险评估（HARA）
原文链接：https://mp.weixin.qq.com/s/-nyK3hjoGK67doCvX4PXmg
一辆正在执行 80km/h 自动驾驶测试的 Robotaxi，突然毫无征兆地向电机下发了最大反向制动扭矩。整车减速度瞬间冲破 0.5g，轮胎撕咬路面的尖锐噪声几乎盖过了对讲机，后方跟随测试车险些追尾。
调出 CAN 总线报文日志后，原因令人骨冷：智驾域控在进行主备仲裁切换时，出现了一帧 20毫秒 的通信帧头错位，底层 VCU 将这帧异常指令错误解释成了最高优先级紧急制动请求。
在传统 L2 辅助驾驶时代，这种故障或许只会换来驾驶员的一句脏话和一脚接管；但在没有安全员的 L4 级全无人驾驶场景下，它可能直接演化成一场致死事故。 这就是为什么，在写下第一行控制代码之前，必须先把 HARA 做对。
HARA 不是表格游戏，而是控制权、时间常数与物理边界的总和。你如果没有把风险在架构上锁死，代码写得再漂亮，也只是把失控做得更快。
一、从 C1 到 C3：拿掉安全员如何推翻了传统 HARA 的危险方程
功能安全 ISO 26262 的核心逻辑，是用一套风险矩阵把系统故障导致的危害压到可接受范围内。这个矩阵最底层只看三件事：严重度 S、暴露率 E、可控性 C。
在传统乘用车里，很多危险事件之所以没有被拉到最高等级，并不是因为故障不危险，而是因为还有一个隐藏的安全资产存在：人类驾驶员。只要驾驶员还能踩刹车、反打方向、按一键切断，许多故障的可控性就还能被评到 C1 或 C2，最终把 ASIL 压到 ASIL B 甚至 QM。
但 L4 级全无人车不一样。人类被从驾驶闭环里物理抽离了，乘客坐在后排，没有方向盘，没有刹车踏板，也没有接管能力。换句话说， 拿掉安全员，等于把可控性参数在物理世界里直接锁死为 C3。
一旦 C = C3，HARA 矩阵就会出现典型的“ASIL 等级雪崩”。在城市路口（VRU 密集，E4）、高速巡航（车速 > 80km/h，E4）或大坡道起步（坡度 > 15%，E3）这类高频场景下，原本只需要 QM 或 ASIL B 的失效模式，会整体抬升到 ASIL D。
这不是评审话术，而是会反过来改写底层电子电气架构的硬约束。此时 VCU 不再只是一个“扭矩翻译器”，而必须演化成具备双 MCU 主从热备份、三层 E-GAS 监控、多路 CAN FD / 以太网冗余通信的中央运动控制枢纽。
S / E / C 不是静态打分表，而是整车控制权如何穿过物理世界的风险映射。
HARA 风险矩阵升级示意：从 C1 / C2 到 C3，ASIL 发生雪崩传统 L2 / L3仍有驾驶员兜底S3E4+C1/C2结果可能落在 ASIL B 或 QML4 全无人安全员被物理移出闭环S3E4+C3结果抬升为 ASIL D安全员被抽离
图 1：S/E/C 到 ASIL 的 HARA 风险升级。真正改变定级的，不是纸面逻辑，而是人类接管能力被彻底拿掉。
**一句话概括：**在 L4 场景下，很多风险不是“更容易发生了”，而是“再也没人能救回来了”。
二、200Nm 与 300ms：非预期高驱动扭矩的 ASIL D 拆解与三层 E-GAS 闭锁
在 VCU 的功能安全需求里，最危险的场景之一就是非预期高驱动扭矩。设想城市拥堵路口，车速 v < 30 km/h，周围密布行人和非机动车。此时系统发生功能失效，VCU 在没有加速请求的情况下，误向 MCU 下发了 200Nm 驱动扭矩。
这个场景的打分几乎没有争议：严重度 S3，暴露率 E4，可控性 C3，因此根据 ISO 26262 风险矩阵，直接落到 ASIL D。由此衍生的安全目标，就是文中反复出现的 SG01 / SG02——避免非预期加速或加速过大。
一旦定级到 ASIL D，架构就必须给出明确的时间边界。这里的故障容错时间间隔 FTTI 被压在 300ms 以内，安全状态 Safe State 被定义为：立即停止扭矩输出（0Nm）或降低输出扭矩。
为了守住这 300ms，VCU 通常采用三层 E-GAS 架构： L1 负责标称功能计算；L2 作为功能监控层，在安全核上独立验证扭矩是否越界；L3 则通过主芯片与安全电源芯片之间的问答式看门狗实现硬件级闭锁。只要 L2 判定扭矩超出允许范围，就能直接覆写指令并拉低使能硬线；若连底层硬件校验也失败，L3 会停止喂狗，触发复位并切断高压。
所以，当 ADCU 或 RDCU 下发的控制指令超出电机能力，或两路 CAN 同时出现 CRC / Counter 错误时，VCU 会立刻把 ADCU / RDCU 判定为 Not Available，并在 300ms 内将电机请求扭矩清零。
S3 + E4 + C3 → ASIL D → SG01 / SG02 → FTTI ≤ 300ms → Safe State: 0Nm / 限扭
SG01 / SG02 / SG04 与 FTTI、Safe State 对应关系SG01非预期加速ASIL DFTTI 300ms停扭矩 / 限扭SG02加速过大ASIL DFTTI 300ms减扭 / 停扭SG04驱动力丢失 / 过小ASIL CFTTI 500ms上报故障 / 限扭安全目标不是抽象口号，它必须落到可验证的时间常数与可执行的安全状态上
图 2：安全目标与 FTTI、Safe State 的映射。没有时间边界的安全目标，等于没有落地。
三层 E-GAS 监控闭锁：L1 / L2 / L3L1标称功能层解析驾驶模式处理扭矩请求输出执行指令L2功能监控层安全核独立运算冗余车速 / 加速度 / 反馈扭矩越界即覆写并拉低使能L3控制器监控层Q&A watchdogAURIX + TLF35584失效即复位 / 切断高压L1 失控由 L2 纠偏，L2 失效由 L3 物理切断，三层闭锁才配谈 ASIL D
图 3：三层 E-GAS 监控闭锁。软件判断、功能监控、硬件切断，缺一层都不够硬。
三、80km/h 下的紧急制动：高速误触发主动制动的极限 FTTI 与降级撕裂
如果说非预期加速是“往前暴冲”，那么高速误制动就是“原地立定”。在 L4 场景下，后者往往被低估，但它同样能稳定打出 ASIL D。
场景很简单：高架或封闭高速公路的 HWP 工况，车辆以 80km/h 巡航，后方紧跟重型卡车，车距小于 15m。此时若制动伺服缸压力计算错误，或智驾接口仲裁失效，系统在无障碍物前提下突然下发 100% 紧急制动，减速度超过 0.6g，那后果并不会比暴冲更轻。
在这类场景中，对再生制动误触发的管控被压得更狠：FTTI = 200ms。一旦回收制动分配出现 ASIL D 级失效，系统必须立即禁止再生制动。但工程矛盾也恰恰出在这里：如果直接把负扭矩从当前值切到 0，整车会出现明显的 Jerk，车态可能进一步失稳。
所以规范里通常会给出缓冲路径：若回收制动不可用，但拖曳扭矩控制 DTC 仍可用，则允许把负扭矩限制在 0.03g 的微小水平，用以模拟传统燃油车的滑行阻力，并在 200ms 内完成平滑切换。
对于液压机械制动，则常见 400ms 级别的 FTTI。若在 IPB 与 RBU 的仲裁链路中检测到非预期制动指令，系统必须在 400ms 内切断主动建压，并根据工况选择人工优先或进入 MRC 安全滑行。
**一个经常被忽略的现实：**为了避免暴冲而设计的刚性降级，如果处理粗暴，同样可能制造幽灵刹车。
功能安全不是“只要停下来就安全”，而是必须在物理边界内、在正确的时间常数里停下来。
高速误制动：200ms / 400ms 降级缓冲逻辑触发200ms400ms再生制动路径：200ms 内限到 DTC 0.03g液压建压路径：400ms 内切断主动建压80km/h 幽灵急刹风险禁止回收 ≠ 允许扭矩突降失稳
图 4：高速误制动的降级缓冲。真正难的不是“停”，而是“不把车态打坏地停”。
四、路测血案复盘：ADCU / RDCU / VCU 在扭矩仲裁真空期的 HARA 重构
所有漂亮的状态机，一上实车都会被现实撞出裂缝。最典型的一种裂缝，就是主备仲裁真空期。
在这套 L4 冗余控制架构里，上层有主自动驾驶域控 ADCU 与冗余自动驾驶域控 RDCU，底层由 VCU 执行扭矩与挡位控制。 一次高速路测中，ADCU 因 SoC 高负载导致总线通信抖动，发送给 VCU 的 0x153 / 0x154 报文出现连续 2 帧 Counter 错误。
按照早期版本的刚性 HARA 逻辑，VCU 一旦检测到 ADCU 报文校验失败，就立刻将 ADCU 判定为 Not Available，随后尝试寻找 RDCU 接管信号。但问题在于，RDCU 从休眠监听切换到主动仲裁需要毫秒级响应，此时它发出的“RDCU 仲裁状态有效标志位”恰好处于 Invalid（0x1） 的中间态。
结果是，VCU 非常死板地执行了矩阵给出的终极安全状态：判定“主备双失”，置位 InMRC，并强制降低驱动扭矩至滑行回收扭矩，拉起 EPB 急刹停车。原本只是一个可以通过重传解决的 20毫秒 总线毛刺，却触发了一次极其危险的高速幽灵刹车。
复盘会最关键的结论只有一句：为了避免暴冲而设计的刚性降级，反而诱发了非预期急刹。 团队因此推翻原逻辑，重构出更真实的弹性闭环：
在 RDCU 侧增加实时硬监控，要求 RDCU 必须在 10个周期 内发出有效仲裁状态与有效标志位。
在 VCU 侧引入精密 Debounce：通信异常后的 T0-T2 窗口内，禁止直接切入 MRC，必须保持上一帧有效控制指令。
当 ADCU 与 RDCU 同时失效、上层产生进入 MRC 的信号组合时，VCU 在真正切入前必须连续确认 10个周期。
这套“上一帧保持 + 10 周期确信窗口”的重构，本质上是在 SG01 防暴冲与 SG02 防幽灵刹车之间，找出了一条狭窄但有效的工程缝隙。
ADCU / RDCU / VCU 仲裁真空期与 10 周期 DebounceT0T1T2+10 周期旧逻辑：错包即 InMRC新逻辑：上一帧保持 + 10 周期确认0x153 / 0x154 Counter 异常Debounce 不是滤波小技巧，而是避免幽灵刹车的系统护栏
图 5：仲裁真空期与 10 周期 Debounce。没有这段缓冲，系统会把通信毛刺误判成整车死亡。
五、硅谷的影子模式与中国重装体系：HARA 评估里的哲学分歧
在功能安全这件事上，全球自动驾驶行业其实在走两条完全不同的路。
从公开行业信息看，以特斯拉为代表的硅谷路线更接近“概率论与数据驱动”。他们倾向于把系统当成一个整体，依靠 Shadow Mode 和海量真实路测数据去碰撞长尾场景，失效后再靠高频 OTA 迭代去修正。
与之对照，国内主流无人车平台、华为 MDC、比亚迪三电系统等方案，更接近“确定性与重装防御”。它们对 ISO 26262 的敬畏更深：每个功能都要拆出明确的 S / E / C，每一条 ASIL D 安全目标，都要对应到具体硬件电路、独立传感器、安全电源芯片和三层 E-GAS 架构。
两种哲学都不是免费的。硅谷路线开发快、BOM 轻、组织反应快，但在极端长尾失效上，往往更难给出逻辑完备的法律与工程自证；中国式重装路线在合规性、可追溯性上更扎实，但代价是研发周期长、架构负担重、系统响应链路更长，测试用例往往动辄上千项——比如文中提到的 790项测试用例。
**真正的分歧，不在于谁更先进，**而在于谁愿意为了确定性，支付硬件、验证、组织复杂度和时间成本。
六、架构师的下一步：从静态 HARA 走向动态 ODD 风险实时度量
如果站在下一代 L4 架构的位置回头看，我们今天做的大多数 HARA，本质上仍然是静态预判。我们在会议室里把城市拥堵标成 E4，把大坡道标成 E3，把无人场景统一锁死为 C3，然后算出一个 ASIL，写进文档，写进 ROM。
但物理世界从来不是静态的。一辆行驶在雨雪混合、路面附着系数突然降到 0.2 的高速公路上的 Robotaxi，它的风险方程和干燥晴天根本不是一回事。
所以真正值得推进的一步，是把静态 HARA 升维为基于 ISO 21448、也就是 SOTIF 的动态 ODD 风险实时度量架构。VCU 与智驾域控不应该只是被动响应静态故障，而应该在 Run-time 结合感知置信度、传感器污损、路面附着力估计、胎压状态等信息，计算整车的 Real-time Risk Index。
当风险指数突破阈值时，系统不该等硬件坏了才触发 MRC，而应主动收缩 ODD：降低最高限速、拉大跟车距离、提前退出高阶无人模式。 真正成熟的 L4 安全架构，不是故障后保命，而是风险升高前先收缩 ODD。
从静态 HARA 到动态 ODD 风险度量静态 HARA会议室里的假设• 城市拥堵 = E4• 大坡道 = E3• 无人场景 = C3升维不是换表格，而是把风险算进运行时动态 ODDISO 21448 / SOTIF• 感知置信度• 路面附着力 / 胎压• Real-time Risk Index风险上升时主动收缩 ODD，而不是等故障击穿后才被动拉 MRC
图 6：静态 HARA 向动态 ODD 风险实时度量的演进。未来的安全，不只是故障分析，而是运行时健康度量。
一台真正能商业化运营的 L4 无人车，不是把故障写进 FMEA 就结束了，而是要把风险持续算进车的每一秒运行状态里。
变现转化区
你会学到什么
无人驾驶场景下,ASIL等级评估该怎么重新做——为什么很多传统方法论直接套用会出问题
没有驾驶员接管时,系统级的失效应对怎么设计,MRC(最小风险状态)到底该怎么落地,不同架构下MRC的实现路径差异在哪
感知、决策、控制、执行几层之间的冗余怎么串起来,单点失效不会变成整车失效
中央计算平台和区域控制器架构下,故障怎么被系统实时感知、隔离、降级处理
Robotaxi真实运营中出过的功能安全相关事故,复盘当时的失效链条和后续改进方案
不讲空对空的标准条文翻译,每一期都落在具体架构和真实案例上——这套课程结束后,你手上应该有的是一套能直接用在项目里的功能安全设计思路,而不是一堆背下来但用不上的定义。
关于作者 | 知猷君
微信公众号：知猷君
近20年造车老兵 · 前自动驾驶整车控制总工 · 前知名主机厂底盘架构总工“我们不制造行业焦虑，我们只提供硬核的工程弹药。”“驭电策新，谋见未来”——关注我，拒绝碎片化，构建你的新能源技术护城河。
© 2026 知猷君. 本内容仅供学习交流，严禁未授权转载。*未经书面授权，任何机构或个人不得通过AI洗稿、切片搬运或抄袭商用。侵权必究。