TN-21 · 2026-09-12 · XiL 领域系列 · 第 7 篇

功能安全三视角：ASIL、安全 MCU 与 NCAP

同一个词”安全”，在汽车行业至少有三种东西在管它：ISO 26262 给风险分级、定开发测试的规矩；域控里那颗不起眼的小芯片在物理上兜底；NCAP 把”安全”翻译成消费者看得懂的星级和场景。三者的目标一致——车不能伤人——但说话的方式完全不同。这篇文章把三个视角各讲清楚，最后拼成一张图。

一、ASIL：风险有多高，规矩就有多严（标准视角）

ASIL（Automotive Safety Integrity Level，汽车安全完整性等级）是 ISO 26262 给功能安全风险分的级，回答一个问题：这个功能失效可能出人命吗？出多大的命？——风险越高，开发测试的规矩越严。

等级怎么定：HARA 三要素

不是拍脑袋，是危害分析与风险评估（HARA）打分，三个维度查表组合：

1. S（Severity，严重度）：失效造成的伤害多重？S0 无伤 ~ S3 致命；
2. E（Exposure，暴露率）：这个运行场景多常见？E0 几乎不发生 ~ E4 高频日常；
3. C（Controllability，可控性）：失效时驾驶员救得回来吗？C0 可控 ~ C3 难以控制。

例子：AEB 高速误触发（不该刹时全力刹）——S 高（可能追尾致死）、E 高（高速天天跑）、C 中高（驾驶员难瞬间接管）→ 往往落在 C 甚至 D。这就是 ADAS 功能测试证据要求严的原因。注意暴露率的影响：同一个失效模式，发生在高速和发生在停车场，等级不同。

等级意味着什么：不是荣誉，是规矩的严格度

• 流程：ASIL D 要求更严格的评审、验证独立性（测试的人不能是开发的人）；
• 覆盖率：单元测试结构覆盖率分级——ASIL D 要 MC/DC（修正条件判定覆盖：每个条件独立影响判定结果，比分支覆盖严一档），往下逐级放宽到分支覆盖、语句覆盖；
• 工具鉴定（TCL）：高 ASIL 要求论证”你的工具不会悄悄引入或漏掉错误”——测试平台要做 TCL 评估，并保留需求—用例—判定链路；
• 追溯链：需求 → 用例 → 结果必须双向可追溯，审核时要拿得出来。

两个邻居概念别混

• ASIL（ISO 26262，功能安全）：管”系统坏了（故障/失效）怎么办”；
• SOTIF（ISO 21448，预期功能安全）：管”系统没坏但能力不够“（感知漏检、算法边界）——ADAS 时代两个都要。

二、安全 MCU：给域控兜底的安全岛（架构视角）

ASIL 定的是”规矩多严”，落地到硬件上有个绕不开的问题：智驾域控的主 SoC 拿不到 ASIL D，但刹车、转向指令要 ASIL D。行业的标准解法是：挂一颗”小而可信”的看门人（安全 MCU，又叫安全岛），把最后签发权交给它。

五个非挂不可的理由

1. SoC 复杂到无法论证安全。 Orin、骁龙 Ride 级 SoC 有上百亿晶体管：多级缓存、缓存一致性、GPU/NPU 共享内存、复杂电源管理——每一个都是系统性失效与随机硬件失效的论证噩梦。现实是 SoC 本体通常只能论证到 ASIL B，而 AEB 制动请求、L2 转向控制是 ASIL C/D。解法是 ASIL 分解：SoC（ASIL B）负责算，安全 MCU（ASIL D）负责审，系统级拿 ASIL D。

2. “统计上的低抖动” ≠ “可论证的确定性”。 Linux + PREEMPT_RT 能把最大延迟压到几十微秒——那是统计结果，没人能为内核几百万行代码的每一条执行路径打包票。安全 MCU 跑 AUTOSAR CP 或裸机静态调度表，代码量小、无动态内存、无复杂驱动，每条路径的最坏执行时间（WCET）可分析、可写进安全手册。ASIL D 要的是后者。

3. 监控者必须独立于被监控者（共因失效）。 监控线程若跑在 SoC 上，一次电源毛刺、内存控制器故障或死锁，监控者与业务一起死，等于没有监控。安全 MCU 有独立供电域、独立时钟、独立看门狗，且单向持有 SoC 的复位线——它能重启 SoC，SoC 无权碰它。

4. SoC 会死机、会重启，车不能没人管。 Linux 启动要几秒到十几秒，行驶中内核 panic 重启是现实场景。安全 MCU 上电毫秒级跑起来，SoC 启动、崩溃、OTA 刷写重启的全部空窗期都由它值守：维持基础安全功能、执行最小风险策略（MRM）、亮灯报警。法规里也有对应场景：倒车影像要求挂入倒挡后 2 秒内出图（FMVSS 111）。

5. 执行器的”最后一棒”需要确定性 IO。 发给制动 ESP、转向 EPS 的 CAN 报文，时序必须硬确定。MCU 原生带 CAN FD 控制器，发报时刻可论证；SoC 发 CAN 要走以太网/PCIe 转接，延迟抖动不可控。由此形成一条行业潜规则：安全相关输出必须由 MCU 签发——SoC 算出的只是”建议”，MCU 审过才变”命令”。

安全岛的职责清单

• 心跳监控：收 SoC 及关键应用的周期心跳，超时即判死（通常 100ms 量级）；
• 合理性校验：对 SoC 输出的转角、减速度做物理可行性检查（范围、变化率），疯了一律否决；
• 最小风险策略（MRM）：判死后接管——保持车道、缓刹、靠边，亮灯报警；
• 车辆状态与电源管理：整车上下面、网络管理（AUTOSAR CP 的老本行）；
• 安全日志：黑匣子记录，事故追溯用。

三个失效场景

SoC 内核 panic        → MCU 心跳超时 → 立即降级，进入 MRM
AP 输出 90° 方向盘转角 → MCU 合理性检查否决，只放行合理指令
调度抖动致制动指令晚到 200ms → MCU 指令超时机制兜底，按安全策略执行

这张架构图就是上面所有理由的总和：

┌────────────────────────────┐
│ 高算力 SoC（ASIL B）       │
│ 感知/规划，输出只是建议    │
└─────────────┬──────────────┘
              │ 建议 + 心跳
              ▼
┌────────────────────────────┐
│ 安全 MCU（ASIL D，安全岛） │
│ 心跳监控 / 合理性校验      │
│ 单向复位 SoC，超时即接管   │
└─────────────┬──────────────┘
              │ 签发命令（CAN FD）
              ▼
        ESP / EPS（制动 / 转向）

对测试工程师的含义

这条”生死通道”是 HIL 故障注入的招牌用例区：杀死 SoC 进程或直接断电、注入非法指令、拉长指令延迟，验证 MCU 是否在限定时限内否决并进入 MRM——判定标准全是时序（多久检出、多快降级）。台架上干这个的设备是故障注入单元（FIU）。

三、NCAP：把”安全”翻译成场景（市场视角）

标准视角和架构视角都在工程内部说话；消费者听不到，也听不懂。把安全翻译成市场语言的，是 NCAP。

NCAP 是什么：先分清它和法规

NCAP = New Car Assessment Program（新车评价规程）：

NCAP 名义上自愿，但星级直接进广告和销量——对车企有事实强制力，行业里叫”市场法规”。

各家 NCAP

• US NCAP（1979，NHTSA）：鼻祖；
• Euro NCAP（1997）：最有影响力，全球风向标，每 2~3 年加严一次规程；
• C-NCAP（2006，中汽中心）：中国版，早期给星偏松，曾被戏称”五星批发部”；
• C-IASI（中保研，保险背景）：不是 NCAP 但角色类似——25% 小偏置碰曾让多款”五星车”现形，消费者口碑反而更硬；
• 其他：Latin NCAP、ANCAP（澳）、JNCAP（日）、Global NCAP；
• 美国另有 IIHS（保险业出资），定位介于法规与 NCAP 之间，小偏置碰是它家招牌。

Euro NCAP 测什么：四大支柱（2025 及以前）

Euro NCAP 长期按四大支柱组织评价：

1. 成人乘员保护：碰撞测试——正面全宽/偏置（MPDB）、侧面、柱碰、鞭打；
2. 儿童乘员保护：儿童座椅接口、动态碰撞；
3. 弱势道路使用者（VRU）：行人头部/腿部碰撞 + AEB 行人/自行车；
4. 安全辅助（Safety Assist）：AEB 车对车（CCR）、LKA、速度辅助、驾驶员监测。

各支柱打分，加权折成 1~5 星（单项太差会拖垮总星）。2026 规程起，评价改按安全链条四阶段重新归组——Safe Driving（安全驾驶）、Crash Avoidance（碰撞避免）、Crash Protection（碰撞保护）、Post-Crash Safety（碰撞后安全）——支柱里的具体测试项被拆进这四个阶段，CCR、AEB 等下游内容不变。

AEB 场景矩阵：用例库的公共底座

ADAS 相关测试用标准化场景：

• CCRs（Car-to-Car Rear stationary）：前车静止；
• CCRm（moving）：前车匀速；
• CCRb（braking）：前车制动。

每个场景配一个速度矩阵：以现行 Euro NCAP 规程为例，CCRs 的接近速度从 10km/h 到 80km/h 按 10km/h 步进（具体档位随规程版本调整）；再用标准化道具（GVT 软目标车、假人、驱动机器人）保证全世界测出来可比较。

这个矩阵值得多看两眼，它是三件事的现实样本：

• 权威机构替你做的风险加权采样——它没做全组合，选的是事故统计里最致命的区间；
• 运行设计域（ODD）内采样的现实版本——速度矩阵就是在 ODD 边界内做的一维采样；
• 现成的判定标准——避免碰撞、碰撞时速度降到多少以下，判据全部公开，拿来就是测试用例的验收条件。

局限：应试教育与军备竞赛

NCAP 场景公开、判据明确 → 车企必然针对优化（”应试教育”）→ 真实事故长尾在 NCAP 场景之外 → NCAP 只能不断加场景、提难度。这是一场永动的军备竞赛，也是它每几年改版的原因。

车企的正确姿势是两层：

1. NCAP 场景库做满分——门票，”公共底座”，有标准答案；
2. 自建场景库覆盖长尾——真实数据回灌、定向搜索出来的危险场景，这才是安全竞争力的本体。

四、三视角合一张图

回到开头的问题：谁在说”安全”？

ASIL 定规矩的严度——风险有多高，开发测试的规矩就有多严； 安全 MCU 兜执行的底——规矩说 ASIL D，硬件上由这颗小芯片保证”出事也有人接住”； NCAP 定市场的验收——把以上一切翻译成具体场景和星级，让消费者用钱投票。

三者不是三个孤立话题：NCAP 场景在需求阶段就写进系统需求，HARA 给它定级，ASIL D 的链路在硬件上落到安全 MCU 签发，测试的证据链同时服务两头——审核时要拿得出追溯，上市时要拿得下星级。一个定标准，一个保执行，一个做验收，这就是”功能安全”在汽车行业的完整语法。

附：名词解释（按出场顺序）