这一篇沿着一次 AEB 紧急制动的信号路径，看看 ASIL-D 到底在哪里加了钱、加了线、加了芯片——以及每一笔"安全税"背后，OEM、Tier1、芯片厂之间的权力关系是怎么被改写的

开场：打开一块 L2++ 域控板

拿到一块 L2++ ADAS 域控板，翻过来看 PCB，你会看到一个奇怪的现象：

板子上有两颗主芯片。一颗很大——AI SoC（比如 NVIDIA Orin），170 亿晶体管，指甲盖大小的封装下面密密麻麻的 BGA 焊球。另一颗小得多——安全 MCU（比如 Infineon AURIX TC397），6 核 MCU，不到大 SoC 十分之一的面积。

两颗芯片之间有一条 SPI 走线和两条 CAN 走线。除此之外—— 它们各有各的电源管理芯片（PMIC），各有各的晶振，各有各的复位电路 。在 PCB 布局上，它们几乎像是两块独立的板子恰好印在了同一张 FR4 基板上。

为什么不把安全 MCU 的功能集成到 AI SoC 里面？以 Orin 为例，它有 12 个 ARM A78 核心和 FSI 上的 4 对 Cortex-R52 锁步核——算力绰绰有余。

为什么要给两颗芯片各配一颗 PMIC？共用一颗不是更省钱？

答案不在芯片手册里。答案在 ISO 26262 的 ASIL 分解规则和 FFI（Freedom from Interference）要求里——而这些要求的背后，是一场关于"出了事谁负责"的供应链权力重构。

这篇文章要沿着一次 AEB 制动的信号路径走一遍。每到一个节点，看两件事： 工程上加了什么（钱、线、芯片） ，以及 这笔加法改变了谁和谁之间的权力关系 。

第一幕：ASIL-D 是一张账单——谁来买单

HARA ：技术推导，政治后果

AEB 制动执行的 ASIL 等级是 HARA 推导出来的。

S3（高速碰撞可致命）× E4（高速行驶是日常工况）× C3（驾驶员来不及反应）=  ASIL-D 。

查 ISO 26262 Part 3 的表就行，技术上半天搞定。

但 HARA 评审会上，三方利益完全不同。

Tier1 倾向于评高。不是因为喜欢给自己找麻烦——而是如果后来出了事而 HARA 当初评低了，"你当初做的 HARA 就有问题"这句话在法庭上是致命的。评高是自保。

OEM 的项目经理倾向于评低。ASIL 每升一级，项目周期多三到六个月，BOM 成本涨 15-30%（行业经验值，具体依项目复杂度和供应商而定）。他的 KPI 是 SOP 日期和成本。

OEM 的功能安全部门倾向于评高。他们和项目经理在同一家公司，但 KPI 完全不同——"零安全事故"。评低了出事，他们内部问责。

三方用同一张表，但 Severity 的"合理最坏情况"有弹性、Controllability 依赖对驾驶员反应能力的假设——同样的场景，三方能推导出不同的 ASIL 等级。

ASIL-D 不是"客观推导"的结果。它是博弈后的共识。  通常是安全部门和 Tier1 联手推高了等级，项目经理在压力下接受。

ASIL-D 到底贵在哪——逐项拆解

ASIL-D 一旦敲定，账单生效。钱花在具体的冗余机制上：

双核锁步——CPU 面积 ×2。  AURIX TC397 有 4 个锁步核，每个主核旁边一个 checker 核，每个时钟周期比对输出。Checker 核不干活，只检查。4 个锁步核 = 8 个物理核心的面积，只提供 4 核算力。大约  40-50% 的额外硅面积 。

而且 AURIX 做了 Diverse Lockstep——checker 核和主核微架构故意不同（不同的门电路、不同的流水线时序）。如果两个一模一样的核有同一个设计 bug，它们会犯同样的错，锁步抓不住。微架构差异降低 共因失效 。再加 2 个时钟周期的延迟偏移——防止同一个宇宙射线同时打翻两核。

ECC 内存——每 8 bit 数据多存 5-7 bit 校验。  AURIX 全部 16 MB Flash + 6912 KB SRAM 都有 ECC。1 bit 错误自动纠正，2 bit 错误检测报警。存储面积增加约 **40-75%**。标称 16 MB Flash 的芯片，硅片上实际阵列可能近 25 MB。

独立看门狗——一个专门盯着 CPU 的硬件定时器。  CPU 必须每个周期"喂狗"，跑飞了没人喂，看门狗超时 → 触发安全动作。看门狗有独立时钟——主晶振坏了 CPU 停了，看门狗还在计时。额外一颗晶振或 RC 振荡器。

独立 PMIC——两颗芯片不能共用电源。  Orin 和 AURIX 各有各的 PMIC。如果共享电源，PMIC 一挂两颗芯片同时死——共因失效，分解失效。额外 BOM $3-5。

E2E 校验——每条消息多几个字节。  CRC + 序列号 + Alive Counter。在 CAN 上（8 字节载荷），安全协议头可能占掉一半带宽。

ASIL-D 成本堆叠

一颗 ASIL-D capable 的 AURIX TC397 大约  。 功 能 相 当 但 不 需 要 锁 步 和 的 普 通 只 要 3-8。乘以百万辆，每多 $10 就是千万美元。

ASIL-D 的 BOM 溢价不是"一张认证标签"——是硅面积、PCB 面积、物料数量的实打实增加。  而这笔账单怎么分摊——是谁来扛芯片溢价、谁来扛测试人力、谁来扛周期延误——就是接下来三幕的核心。

幕间：权力地图 circa 2010——Tier1 时代

在讲 ASIL 分解之前，先看看安全责任在供应链里的权力地图——就像 EE 架构那篇文章里的"权力地图"一样，安全领域也有一张。

2010 年，分布式 EE 架构。

AEB 系统里，博世提供 ESP（ASIL-D，制动执行），Mobileye 提供视觉感知 ECU（ASIL-B），大陆提供毫米波雷达（ASIL-B）。每家供应商独立认证自己的 ECU——从芯片选型到 FMEDA 到故障注入到 Safety Case，全部在供应商内部闭环完成。

OEM 做什么？定义安全需求（HARA），定义接口（DBC 文件），做系统级集成测试。但具体的安全实现——在供应商的黑盒里，OEM 看不到代码，也看不到 FMEDA 细节。

谁拥有安全知识，谁就拥有权力。而在 2010 年，安全知识全在 Tier1 手里。

OEM 想改一个 AEB 的触发逻辑？请找博世。想优化 ESP 的制动响应曲线？请提需求给博世，等下一个版本。想了解 ESP 内部的 ASIL-D 安全机制细节？对不起，商业机密。

这个格局和 EE 架构那篇的结论一模一样： 谁写代码谁有权力。  安全领域加了一层： 谁签 Safety Case 谁有责任——而签字的是 Tier1，因为他们既写代码又做认证。

FFI 在这个时代容易得多。每颗 ECU 物理独立——不同芯片、不同 PCB、不同电源、不同线束。你不需要证明"博世 ESP 的代码不会影响 Mobileye 的感知"——它们之间唯一的连接就是 CAN 总线上的几条消息。 FFI 通过物理隔离自然实现，论证工作量很小 （但并非零——CAN 总线上的消息仍需 E2E 保护，接口处的 FFI 仍需论证）。

代价你知道：150 个 ECU、3-5 公里线束、六家供应商的 18 个月同步地狱。但至少安全的事，每家管好自己那颗 ECU 就行，清清楚楚。

到了 2024 年，这张权力地图被彻底重写。但先看看 ASIL 分解是怎么把这张图炸开的。

第二幕：ASIL 分解——一场精心设计的责任拆分

整个 AEB 做 ASIL-D？没人签得起这张支票

回到那张账单。如果整个 AEB 系统从传感器到算法到执行器都按 ASIL-D 做——BOM 翻倍、测试周期翻倍、认证费翻倍。

所以 ISO 26262-9 给了一条出路： ASIL 分解 。

核心思想：一个 ASIL-D 的安全需求，拆成两个独立通道，每个通道只需要更低的 ASIL 等级。

行业最常用的方案：**ASIL-D = ASIL-B(D) + ASIL-B(D)**。括号里的 D 是原始等级——追溯用，提醒你这不是普通的 ASIL-B，是从 ASIL-D 拆下来的。两个 ASIL-B 通道，各自只需要 PMHF < 100 FIT（每十亿小时不超过 100 次安全违背）、SPFM ≥ 90%（单点故障覆盖率）——认证难度降一个量级。

但 ISO 26262-9 Clause 7 写得很清楚：分解的前提是两个通道满足独立性要求。  具体来说——无共因失效（Common Cause Failure）、满足 FFI（Freedom from Interference）。如果两个通道共享硬件（同一颗 SoC）、共享软件（同一个 OS）、共享供应商（同一个代码库），独立性就被削弱。独立性不是声明出来的，是论证出来的——而论证本身就是 Safety Case 里最重的一部分。

ASIL 分解原理

数学上说得通。但这个"分解"在组织上做了一件事： 它把一整块 ASIL-D 的责任切成了两半，然后这两半可以给不同的人。

NVIDIA 的教科书级责任切割

看看 NVIDIA 怎么操作 Orin 的安全认证。

TÜV SÜD 给 Orin 的认证：

• 系统性能力（Systematic Capability）：ASIL-D ——设计流程达标
• 随机硬件故障：ASIL-B ——整颗 SoC 的随机故障率只到 ASIL-B

翻译成大白话：**"我的芯片设计没问题（流程是 ASIL-D 的），但芯片本身可能随机出错（只到 ASIL-B）。你要系统级 ASIL-D？请自己想办法。"**

怎么想办法？加一颗外部安全 MCU。Orin（ASIL-B）做感知决策 + AURIX（ASIL-B）做安全监控 = 系统级 ASIL-D。

NVIDIA 在 Orin 内部还留了一手—— FSI（功能安全岛） ：4 对锁步 Cortex-R52，独立电压轨，独立晶振，可以独立达到 ASIL-D。FSI 只有 10K DMIPS——跑不了 AI 感知，只能跑安全监控。

FSI 是 NVIDIA 给客户的一个选项：你可以用 FSI 代替外部 MCU，在 Orin 内部完成 B + B 分解。很多参考设计确实这么做。

但量产中，很多 Tier1 选了  Orin + 外部 AURIX 。为什么？

共因失效。  FSI 虽然有独立电压轨，但它在 Orin 这颗 die 上——共享硅片、共享封装、共享散热路径。芯片过温、焊接缺陷、封装开裂——FSI 和主计算区同时失效。外部 AURIX 是完全不同的封装、不同的 PCB 位置、不同的散热路径——一颗挂了不影响另一颗。

FFI 论证难度。  如果用 FSI，你需要论证"FSI 和 Orin 主计算区虽然在同一颗 die 上，但满足 FFI"——共享衬底、共享封装、共享供电（PMIC 可能相同）……论证工程量巨大。用外部 AURIX？不同芯片、不同封装、不同电源、不同代码库——FFI 是物理事实，不需要复杂论证。

多花 $15-25（AURIX TC3xx 量产价格区间）买一颗外部安全 MCU，省下的是几个月的 FFI 论证和更低的 Safety Case 风险。  汽车行业算这笔账，划算。

"ASIL-D capable" vs "ASIL-D compliant"——行业里最精妙的权力术语

这里要讲一对术语。外行很难分辨，但内行一看就知道背后的权力含义。

ASIL-D capable （具备 ASIL-D 能力）：芯片提供了达到 ASIL-D 所需的硬件机制（锁步核、ECC、SMU），但是否真的达到 ASIL-D 取决于你怎么用。

ASIL-D compliant （符合 ASIL-D）：整个系统已被证明满足 ASIL-D 所有要求。

芯片厂几乎从来不说自己的产品 "ASIL-D compliant"。他们说 "ASIL-D capable"。

区别既是技术的，也是责任的。

技术上说——"capable"意味着芯片提供了所有必要的安全机制（锁步核、ECC、SMU），但系统级安全还依赖于正确的配置和集成。"Compliant"意味着整个系统已被证明满足所有 ASIL 要求。芯片是零件，不是系统——芯片厂认证零件，系统级合规是集成商的事。

责任上说——这个区分同时也划定了追责边界。

AURIX TC397 数据手册上写 "ASIL-D capable"。Infineon 提供了锁步核、ECC、SMU。但你必须正确配置 MPU（内存保护）、正确编写安全监控代码、正确实现看门狗协议。MPU 配置漏了一个内存区域？那是集成层的问题。

Safety Manual 既是技术指导，也是责任界面。  上面写满了"假设使用条件"（Assumptions of Use）：你必须这样配置时钟、必须这样使用 ECC、必须在多少微秒内响应 SMU 中断。这些条件定义了芯片厂的安全承诺边界——在条件内，芯片厂为硬件安全机制负责；在条件外，集成商为正确使用负责。

Tier1 的工程师管这个叫"芯片厂在用 Safety Manual 保护自己"。 芯片厂的 FAE 管这个叫"我们在帮客户正确使用产品"。

两种说法都对。Safety Manual 本质上是安全认证体系中的责任分层机制——芯片厂负责"零件能不能做到"，集成商负责"系统有没有做到"。只是当出了事需要追责时，这条线的位置就变得微妙了。

幕间：权力地图 circa 2024——三方博弈

分布式时代的权力地图很清楚：Tier1 掌握安全知识和代码，OEM 是集成商。

L2++ 中央计算时代，权力地图被重写了：

芯片厂（NVIDIA、Infineon）成了新的"安全知识地主"。

Orin 的 FMEDA 数据是 NVIDIA 的核心 IP——故障率、诊断覆盖率、安全机制的详细设计——Tier1 拿不到全部细节，只能拿到 Safety Manual 和汇总数据。想要更细粒度的 FMEDA？签 NDA，付费，等三个月。

AURIX 的锁步核如何实现 Diverse Lockstep？门电路级的多样性细节？Infineon 不公开。你只需要知道它能到 ASIL-D capable，怎么做到的是我的 IP。

芯片厂掌握了安全认证的"原材料"（FMEDA 数据、安全机制细节），但不承担系统级安全责任。  它们提供的是 "capable" 的零件 + Safety Manual。系统级怎么组合、怎么论证、怎么测试——不关它的事。

Tier1 成了"夹心层"。

Tier1 拿着 NVIDIA 的 Safety Manual 和 Infineon 的 Safety Manual，把两颗芯片集成到一块板上。FFI 论证——Tier1 做。FMEDA 系统级汇总——Tier1 做。故障注入测试——Tier1 做。MC/DC 覆盖率——Tier1 做。Safety Case——Tier1 写。

芯片厂给的是原材料。OEM 给的是需求和压力。 中间那些脏活累活——全是 Tier1 的。

而且 Tier1 的 Safety Case 签字栏上写的是 Tier1 安全经理的名字。出了事，法庭上调出 Safety Case，签名栏上不是 NVIDIA 的人，不是 OEM 的人——是 Tier1 的人。

OEM 拿回了"定义权"，但也扛上了"最终责任"。

域集中和中央计算时代，OEM 不再满足于当集成商。他们自己定义 EEA、自己定义安全架构（HARA、ASIL 分解策略、FFI 方案）、甚至自己做域控的硬件设计。

但定义权带来了责任。消费者告的是 OEM，不是 Tier1，更不是 NVIDIA。OEM 是安全责任链的终点。

最讽刺的权力格局出现了：  芯片厂掌握安全认证的核心数据但不承担系统责任；Tier1 做最重的集成工作并签字；OEM 定义架构并承担最终法律责任——但 OEM 对芯片内部的安全机制细节，了解程度可能是三方里最浅的。

掌握最少安全细节的人，承担最大的法律责任。  这就是 L2++ 时代安全供应链的核心张力。

安全权力地图演进

第三幕：沿着信号路径看冗余——以及冗余背后的 EEA 代价

AEB 一次制动的信号路径

AEB 制动信号路径

从左到右：传感器把数据交给 AI SoC（ASIL-B），AI SoC 把制动请求交给安全 MCU（ASIL-D），安全 MCU 授权后交给 ESP/iBooster（ASIL-D）执行。注意那条绕过 AI SoC 直连安全 MCU 的独立雷达——它是整个 ASIL 分解的关键独立信源。

每个节点，看两件事：加了什么冗余，对 EE 架构有什么影响。

传感器 → AI SoC：多模态不是豪华配置，是安全刚需

8 路摄像头 + 5 路毫米波雷达 + 1 路 LiDAR。

多模态的核心不是"看得更多"——是 失效模式独立 。摄像头在逆光下失效，但雷达不受光照影响。雷达对横向静止物体不敏感，但 LiDAR 不管什么条件都给你 3D 点云。三种传感器因为同一个原因同时失效的概率极低—— 除非电源断了 。

所以 EEA 上，三种传感器的供电路径必须分开。摄像头走 PoC（Power over Coax，通过 GMSL 同轴线供电），雷达走独立供电，LiDAR 走独立供电。在线束设计里，它们是不同的分支，不共享连接器。

对 EEA 的代价 ：8 路 GMSL 需要 2-4 颗解串器芯片（每颗最多 4 路输入），每颗通过 MIPI CSI-2 接 Orin——这些高速走线在域控 PCB 上占了大量面积和层数。5 路雷达通过以太网或 CAN 接入。1 路 LiDAR 通过以太网接入。 光是传感器数据接入，就要求域控板至少 12-16 层 PCB ，板子尺寸和成本直接受影响。

这些传感器数量不是产品经理拍脑袋定的——是 SOTIF 的论证需要。纯视觉方案在 SOTIF 论证上极其困难：你怎么论证摄像头在所有光照、天气条件下都能正确检测？多模态传感器互补是 SOTIF 场景覆盖的基础。

这就是 SOTIF 对 EEA 的第一层影响：传感器数量和多样性被安全论证需求推高，直接推高了数据链路复杂度和线束成本。

Orin 内部：GPU 与 ASIL-D 的距离

Orin 主计算区跑 AI 感知、BEV 融合、轨迹预测。输出一条制动请求。

这一段没有 ASIL-D 冗余。  GPU 没有锁步核。为什么？

Orin 的 GPU 有 2048 个 CUDA core。给每个加一个 checker core = 4096 个物理 core，面积翻倍，功耗从 ~60W 到 ~120W，散热方案要全部重做。而且 GPU 的线程调度是非确定性的——锁步要求每个周期输出一致，GPU 做不到。

理论上，ASIL-D 不是只有"外挂 MCU"一条路。至少有三种架构思路：

1. 片内安全岛 ——Orin 自带的 FSI（前面讲过）就是这个思路，在 SoC 内部划出一块 ASIL-D 区域做监控。好处是省一颗芯片，但共因失效（共享硅片、封装、散热）的论证很重。
2. 外挂安全 MCU ——Orin + AURIX，两颗完全独立的芯片。FFI 论证最简单，但 BOM 多 $15-25。
3. 双 SoC 互监控 ——两颗同款 SoC 互为备份。算力冗余最强，但成本最高，且共因失效风险大（同一代码、同一供应商）。

行业主流选了方案 2——Orin + 外部 AURIX。  不是因为其他方案不存在，而是在 FFI 论证难度、BOM 成本、Safety Case 风险三者之间，这个方案的综合账算得最划算。

对 EEA 的影响 ：这就是为什么大多数 L2++ 域控板上有两颗主芯片。不是因为一颗算力不够——Orin 的 254 TOPS 足以包办一切计算——而是因为  ASIL 分解要求两个独立通道，GPU 的物理特性让它极难同时扮演裁判和运动员 。

这个约束穿透到整车 EEA：域控板需要额外的 PCB 面积容纳安全 MCU（如 AURIX）和它的独立供电电路，需要额外的连接器引出安全 MCU 的独立 CAN 总线，需要额外的线束把独立传感器直接接到安全 MCU 而不是经过 Orin。

AI SoC → 安全 MCU：不信任协议的工程实现

AI SoC 发出制动请求。安全 MCU 收到后—— 不信任 。

独立传感器交叉验证。  安全 MCU 直接连接一路独立雷达（通过独立 CAN 总线，不经过 AI SoC）。AI SoC 说"前方 50 米有障碍物"——安全 MCU 检查自己的雷达，50 米处有回波吗？不一致 → 不授权全力制动，降级为轻制动 + 报警。

对 EEA 的影响 ：整车传感器架构里，至少一路雷达不接在 AI SoC 上，而是绕过 AI SoC 直接接在安全 MCU 上。这条走线从车头保险杠穿到驾驶舱域控板，在整车线束里是一条独立通路——不和 AI SoC 的传感器走线共用连接器或线束分支。

这是安全等级对整车传感器布局和线束的直接改写。

Challenge-Response 看门狗。  安全 MCU 每隔 N 毫秒向 AI SoC 发一个随机数，AI SoC 用预共享算法计算返回。超时或答案错误 = AI SoC 失效 → 安全 MCU 接管 → 可控减速停车。

车速/减速度合理性检查。  AI SoC 说"0.8g 紧急制动"——安全 MCU 检查车速、路面估算、前方距离——合理吗？不合理就降级。

安全 MCU 对 AI SoC 的每一条指令，默认假设它是错的——直到验证为止。

安全 MCU → ESP/iBooster：双执行器的成本

安全 MCU 验证通过，授权制动信号。

很多 L2++ 系统用  ESP + iBooster 双执行器 。iBooster 是电控助力器，ESP 是传统液压 ABS 单元。两者可以独立产生制动力——iBooster 挂了，ESP 接管。

对 EEA 的影响 ：双执行器 = 两条独立 CAN 总线、两套独立供电、两根独立液压管路。在底盘线束里，这是实打实的"双路径"。

FFI 如何改写三代 EE 架构

把上面的信号路径放到 EEA 三代演进的背景下：

分布式（2010s）：FFI 论证最轻。

Mobileye ECU、博世 ESP、大陆雷达——不同芯片、不同 PCB、不同电源、不同线束。物理隔离让独立性显而易见，论证工作量极小。代价：150 个 ECU、3-5 公里线束。

域集中（2018+）：FFI 变成必须主动构建的工程。

感知和决策整合到 ADAS 域控器。ASIL-B 的 AI 算法和 ASIL-D 的安全监控可能在同一颗 SoC 上跑——你再也不能说"物理隔离所以独立"。

MPU 配内存保护、AUTOSAR OS 做时间分区、E2E 做通信隔离——这些机制要  主动配置并证明有效 。配错一个 MPU 地址，QM（Quality Management，非安全相关）代码就能越界写入 ASIL-D 数据——而这种 bug 在正常测试中可能永远不触发，只在极端场景下爆发。

对 EEA 的影响 ：域控板上的软件架构变得极度复杂——AUTOSAR OS 的时间分区配置、MPU 区域表、E2E Profile 选型——这些"看不见"的软件配置，和 PCB 布局一样影响安全性。

L2++ 中央计算（2022+）：FFI 成为 EEA 设计的核心约束。

170 亿晶体管共享一块硅片。FFI 从"配几个 MPU"变成了"要不要多花 $15-25 加一颗独立 MCU"的架构级决策。

EEA 的每一代演进让功能更强大、通信更快、线束更短——但同时让安全隔离更难、更贵、更需要系统级思考。

FFI 三代演进

这是 EEA 集中化的暗面：每一次集中，都是"功能效率"的提升和"安全隔离代价"的提升同时发生。  分布式的 150 个 ECU 很低效，但安全隔离通过物理分离自然获得。中央计算的一颗 SoC 很高效，但安全隔离要从硅面积、PCB 布局、线束设计、软件架构四个层面花钱买。

EE 架构师以为自己在设计通信拓扑和算力分配。但 ASIL-D 站在他背后，安静地告诉他：你的电源不能共享，你的总线不能共用，你的芯片不能只有一颗，你的线束不能走最短路径——得走最安全的路径。

第四幕：FuSa 验证——定义"够了"的权力

验证的本质是一条因果链

设计了锁步核、配了独立 PMIC、拉了独立 CAN——然后呢？怎么证明这些机制真的管用？

FuSa 验证是一条反向追溯链：从安全目标到底层证据，链条不能断。

FMEDA （Failure Modes Effects and Diagnostic Analysis）给每个故障模式算概率——芯片里每个功能块的每种故障（stuck-at、bit-flip、短路、断路）的概率、能不能被检测到、检测到后是否进入安全状态。汇总得出三个硬指标：

• SPFM （Single-Point Fault Metric，单点故障覆盖率）≥ 99%——每 100 个可能的单点故障，至少 99 个能被安全机制检测到
• LFM （Latent Fault Metric，潜伏故障覆盖率）≥ 90%——那些不会立刻暴露、可能潜伏到下次需要时才爆发的故障，至少 90% 能被周期性诊断发现
• PMHF （Probabilistic Metric for random Hardware Failures）< 10 FIT——每十亿小时运行，因随机硬件故障导致安全违背不超过 10 次

这三个数字就是 ASIL-D 的"及格线"。任何一个不达标，Safety Case 就签不下去。

Fault Injection  主动制造故障，分三个层面验证安全机制：

• 硬件级 ：通过 JTAG 翻转寄存器 bit（模拟宇宙射线 SEU），看锁步核能不能在下个时钟周期检测到。拉低供电电压，看 brownout 检测能不能触发。EMC 辐照下系统是否进入安全状态。
• 软件级 ：注入任务延迟，看看门狗和时间监控能否正确响应。翻转内存数据，看 ECC 能否纠正或报警。
• 接口级 ：往 SPI/CAN 注入错误帧，看 E2E CRC 能不能拒绝。中断通信链路，看超时检测是否触发安全降级。

MC/DC  测 ASIL-D 软件——不是"每行代码跑过"就够，而是"每个布尔条件独立影响判决"。Branch Coverage 需要 100 个用例的代码，MC/DC 100% 可能要 2000 个。

验证的战场不在实验室——在会议室

技术上每一步都清楚。但"做到什么程度"——这是权力问题。

FMEDA 的粒度之争。  芯片厂提供模块级 FMEDA（CPU core 整体、Flash 控制器整体）。Tier1 安全团队有时要求更细粒度（ALU 单元、寄存器文件）——因为粗粒度可能遗漏特定故障模式。芯片厂说："更细粒度涉及 IP 核心细节，签 NDA 付费等三个月。" 又是钱和时间的问题。

Fault Injection 的覆盖率之争。  ISO 26262 没有规定"必须注入多少次"。标准说 "Highly Recommended"——不是 Mandatory。安全团队说覆盖所有 FMEDA 故障模式（3000 种）。测试团队说六个月工作量。项目经理说 SOP 不等人，做 500 种。安全团队说 TÜV 可能不过。项目经理说 TÜV 的具体覆盖率要求是多少。安全团队说标准里没写数字。

标准里没有数字。"够不够"变成了权力决定的。  通常是安全团队和项目管理在 SOP 日期压力下的妥协产物。

MC/DC 的范围之争。  安全团队要全部安全代码 MC/DC 100%。测试团队说人力不够——核心安全路径做 MC/DC，辅助功能做 Branch Coverage 行不行？可以——但"哪些是核心安全路径"的定义，又是一场会议。

Safety Case：签字栏

所有证据汇总成 Safety Case——从 HARA → Safety Concept → FMEDA → DFA（共因失效分析）→ Verification Report 的因果链。行业常用  GSN（Goal Structuring Notation）  来组织这条链：顶层是安全目标，逐层分解为子目标，每个叶子节点挂一份具体证据（测试报告、分析报告、设计文档）。TÜV 审核的不是"你测了多少"，而是"论证结构有没有逻辑断裂"——这是一种  argument-based safety  方法，Safety Case 的核心是论证的完整性，不是证据的数量。

因果链上任何一环断了——HARA 说 ASIL-D，Safety Concept 说 B(D) + B(D) 分解，但 DFA 里没有充分证明两个 B 通道独立？链条断了。故障注入显示某个检测延迟超过 FMTI（故障容忍时间间隔）？链条断了。即使其他指标全达标。

Safety Case 签名栏上写的是 Tier1 功能安全经理的名字。  出了人命事故，法庭上调出来的第一份文件就是这份 Safety Case。法官看签名栏。

这就是为什么功能安全经理是汽车行业里最难招的岗位之一。技术要懂、标准要熟——最关键的是， 你得愿意在一份可能上法庭的文件上签自己的名字 。

第五幕：SOTIF——没有终点线的马拉松

FuSa 的边界就是 SOTIF 的起点

FuSa 全部验完了。芯片不会出错。就算出错，安全机制纳秒级检测。

但 2016 年佛罗里达那辆 Tesla——芯片全好，算法在跑，白色卡车与天空融为一体，感知没有检测到。

零件没坏但判断错了——SOTIF（ISO 21448）的领地。

FuSa vs SOTIF

SOTIF 关注三类问题来源：

• 功能不足（Functional Insufficiency） ——算法本身的能力局限。AI 模型的训练数据分布有边界，雷达的角分辨率有物理极限，融合算法的优先级逻辑有盲区。零件都好好的，但能力本身不够。
• 触发条件（Triggering Condition） ——特定环境让功能不足暴露出来。强逆光 + 白色大面积物体 → 摄像头过曝。暴雨 + 前车溅水 → LiDAR 点云噪声。施工区 + 临时标线 → 车道线误检。这些环境不是"故障"，但是"陷阱"。
• 可预见的误用（Reasonably Foreseeable Misuse） ——驾驶员在 L2 下完全放手、在 ODD 外强行使用系统。系统没坏，人在错误地使用它。

SOTIF 验证和 FuSa 验证的根本区别

FuSa：故障驱动。列出故障模式 → 设计检测机制 → 注入故障验证。有硬指标：PMHF < 10 FIT。

SOTIF：场景驱动。枚举触发条件 → 构造测试场景 → 观察 AI 判断。 没有像 PMHF < 10 FIT 那样的硬性数值门槛。  但 SOTIF 也不是"随便写个报告就行"——ISO 21448 要求一套基于论证的合规框架（argument-based approach）：

1. 触发条件系统性枚举 ——你用了什么方法（STPA、历史事故库、field data）来确保没有遗漏？方法本身要经得起审。
2. 已知危险场景（Area 2）消除或缓解 ——每个已知的触发条件，你有对应的设计措施吗？
3. 未知危险场景（Area 3）持续缩小 ——你有什么机制在量产后继续发现新的触发条件？（Shadow Mode、OTA 数据回灌）
4. 残余风险论证 ——ISO 21448 Annex C 建议参考 10^-8 /h 级别的残余风险目标（与 FuSa PMHF 对齐），但这不是强制要求，是论证的参考锚点。

"可接受水平"由谁定义？标准给了框架但没给数字。  这意味着 SOTIF 的"够了"比 FuSa 更加取决于组织内部的权力博弈——安全团队要更多场景覆盖，产品团队要更宽 ODD（更强竞争力），项目团队要更快交付。最终拍板的往往是 VP 级别。

SOTIF 对 EEA 的三层影响

第一层：多模态传感器是安全论证的刚需（前面已经讲了）。  三种传感器失效模式独立 → 更多数据链路 → 更多线束 → 更高的 PCB 层数。

第二层：Shadow Mode 需要算力余量。  量产车上跑影子模式 = 额外一套 AI 推理后台运行 = Orin 需要预留 20-30% 算力。这直接影响芯片选型——是用刚好够的 200 TOPS 配置还是留余量的满配 254 TOPS？留余量 = 更贵的 SoC 或更多 SoC。

第三层：ODD 检测需要额外的环境感知传感器。  系统要能判断"当前是否还在 ODD 内"——能见度 > 100m？路面积水？这可能需要额外的雨量传感器、能见度传感器——又是额外的接入和线束。

RAND 的数学和仿真的现实

RAND 2016 年的账：统计上证明自动驾驶比人类安全 20%，需要  88 亿英里  路测。44 万辆车跑一整年。

所以仿真是唯一能接近这个量级的手段——Waymo 跑了 200 亿英里仿真。但仿真覆盖的是"已知参数空间"。真正危险的是"未知的未知"——你连参数维度都没想到的场景。

Shadow Mode 是目前发现"未知的未知"最有效的手段：百万辆量产车在真实道路上跑，新旧版本输出比对，分歧场景自动提取回灌仿真。但 Shadow Mode 需要算力、需要数据标注团队、需要仿真基础设施——每一项都是成本。

FuSa 有终点线：PMHF < 10 FIT，达标就是达标。SOTIF 没有终点线——只有你的论证是否站得住脚，以及签字的人是否睡得着觉。

第六幕：当 AI 重写规则——从 SDV 到 AIDV 的安全断裂

这套体系能撑多久？

前五幕讲的所有机制——锁步核、FMEDA、MC/DC、ASIL 分解、Safety Case 签字——有一个共同前提： 车辆的行为是由人类写的确定性代码定义的。

你可以审查代码、穷举分支、逐行证明行为符合规范。FuSa 的整套工具链就是为这个世界设计的。

但 Tesla FSD v12 之后，这个前提开始松动。

FSD v12 之前——工程师写规则：前方有障碍物，左偏 → 打方向盘。几万条 if-else，逻辑清晰，可审查。FSD v12 之后——摄像头图像进入神经网络，直接输出转向角和油门刹车。没有 pipeline，没有模块，没有人类写的规则树。整个过程是一次 模型推理 。

车辆的行为不是被"编程"的，是被"训练"出来的。

SDV → AIDV 安全范式断裂

这一刻，FuSa 和 SOTIF 的验证范式同时受到冲击。

FuSa 的硬指标遇到了软对手

MC/DC 要求你证明"每个布尔条件独立影响判决"。200 亿参数的神经网络里没有布尔条件——只有浮点权重矩阵。你审查什么？

FMEDA 要求你穷举故障模式——stuck-at、bit-flip、短路、断路。但神经网络的"故障模式"是什么？权重偏移 0.001 导致 corner case 误判？这不是随机硬件故障，是模型本身的能力边界。锁步核检测得了 bit-flip，检测不了"模型在这个场景下就是会输出错误结果"。

FuSa 的工具链是为"零件可能坏"设计的。但 AIDV 的问题是"零件全好，模型就是判断错了"——这恰好是 SOTIF 的地盘。

SOTIF 的论证被拉到极限

SDV 时代的感知 pipeline 是模块化的——检测、跟踪、融合、预测，每个模块可以独立分析触发条件。摄像头过曝？感知模块的问题。融合冲突？融合模块的问题。你能归因，就能修。

端到端模型把整个 pipeline 压成一个黑盒。输出错了——是摄像头输入有问题？是模型在这个分布外？是训练数据缺这类场景？ 你无法归因，也就无法系统性枚举触发条件。

而 SOTIF 论证的第一步就是"触发条件系统性枚举"。黑盒让这一步从困难变成了接近不可能。

目前行业最有说服力的应对是 算法多样性冗余 ——不是用两份一样的代码互相检查（那叫同构冗余，共因失效风险高），而是用两套完全不同的方法论互相验证：一套传统规则栈（模块化感知 + 规划），一套端到端神经网络。两条路径同时跑，输出不一致就降级。

NVIDIA 的 Halos 安全平台就是这个思路——据公开信息，投入超过 18000 人年工程量，SoC 内置 210 亿安全晶体管，22000 个平台级安全监控器。这不是在旧框架上打补丁，是在建一套新的安全基础设施。

但算法多样性解决的是"两条路径互相兜底"——如果两条路径对同一个 corner case 都判断错了呢？共因失效不再是硬件层面的（不同芯片、不同封装），而是认知层面的（两套算法对同一个罕见场景都没见过）。

权力地图的第三次重写

分布式时代——安全知识在 Tier1 手里，Tier1 签字。

SDV/L2++ 时代——FMEDA 数据在芯片厂手里，Tier1 签字，OEM 扛法律责任。

AIDV 时代—— 训练数据和模型权重成了新的"安全原材料"。

谁掌握百万辆车的真实驾驶数据？谁有能力训练和验证 200 亿参数的端到端模型？谁有 200 亿英里仿真的基础设施？这些能力不在传统 Tier1 手里，甚至不在大多数 OEM 手里——在 Tesla、Waymo、NVIDIA、华为这样同时拥有算力和数据闭环的玩家手里。

安全的"原材料"从 FMEDA 数据变成了训练数据，权力就跟着数据走了。

而最根本的权力争夺在更上游—— 谁来定义 AIDV 时代的安全标准？  ISO 26262 和 ISO 21448 是为确定性系统设计的。新的标准正在酝酿（ISO PAS 8800 针对车载 AI 安全、UL 4600 用 argument-based 方法定义自动驾驶安全），但远未成熟。

谁先写出行业接受的 AI 安全验证方法论，谁就定义了游戏规则。  这场标准制定的竞赛，可能比任何一场芯片算力竞赛都更深远地决定谁赢。

怎么验证一个会学习的大脑是安全的——整个行业还没有答案。这可能是接下来二十年里最重要的工程问题。而 Safety Case 签名栏上的那个位置，正等着一个还不存在的名字。

收束：安全等级穿透了整辆车——从硅片到供应链

沿着一次 AEB 制动的信号路径走下来，你看到了两件事：

第一件：ASIL-D 对 EE 架构的穿透力。

从芯片内部的锁步核（面积 +40%），到 PCB 上的独立 PMIC 和独立晶振，到域控板上的"AI SoC + 安全 MCU"双芯片布局，到整车线束里绕过 AI SoC 直接接安全 MCU 的独立雷达走线，到底盘的 ESP + iBooster 双制动执行器—— ASIL-D 的要求穿透了每一层 EE 架构，在每一层都转化成了具体的硬件、走线和成本 。

SOTIF 从另一个维度施加压力：多模态传感器推高数据链路复杂度，Shadow Mode 推高 SoC 算力需求，ODD 检测推高传感器数量。

你看到的一辆 L2++ 的车比传统车多出的那些传感器、芯片、线束——很大一部分不是为了功能更强，而是为了安全更可信。

第二件：ASIL-D 对供应链权力的重塑。

分布式时代，Tier1 掌握安全知识并签 Safety Case，OEM 是集成商。L2++ 时代，权力三分——芯片厂掌握 FMEDA 核心数据但只提供 "capable" + Safety Manual；Tier1 做集成脏活并签字；OEM 定义架构并承担最终法律责任。

EEA 的每一次集中化，都同时发生了两件事：功能效率提升，安全隔离代价提升。  分布式的 150 个 ECU 低效但 FFI 论证轻松。中央计算的一颗 SoC 高效但 FFI 要从硅面积、PCB、线束、软件四层花钱买。

这是 EE 架构进化的暗面——上一篇讲的是"谁来定义汽车"的权力交接。这一篇讲的是同一个进化过程中的另一条线：**"谁来为你的安全买单"的责任交接。**

两条线，同一个故事：当算力集中，权力就重新分配——无论是功能定义权，还是安全签字权。

AI SoC 是大脑。安全 MCU 是不信任大脑的那个人。整辆车的 EE 架构，是为"不信任"付出的工程代价。而 Safety Case 签名栏上的名字，是为"不信任"付出的人的代价。