功能安全基础（ISO 26262）：ASIL等级划分、安全目标定义、功能安全概念与安全机制

各位工程师朋友，咱们直接进入正题。功能安全这块，说白了就是回答一个问题：系统出故障了，人会不会出事？ ISO 26262 就是回答这个问题的标准答案集。我最早接触它的时候，觉得这玩意儿就是一堆文档活，后来在项目里吃过亏才明白——它其实是帮你把「万一出事怎么办」这件事，提前想清楚、写明白。

ASIL等级划分：你的系统有多「危险」？

ASIL，全称 Automotive Safety Integrity Level，汽车安全完整性等级。它不是拍脑袋定的，而是基于三个维度算出来的：

• Severity（严重度）：人受伤有多重？
• Exposure（暴露概率）：这种情况发生的频率高不高？
• Controllability（可控性）：驾驶员能不能自己救回来？

每个维度分四级（S0-S3, E0-E4, C0-C3），组合起来得到 ASIL A、B、C、D 四个等级。D 最高，A 最低。还有个 QM（Quality Management），意思是「按质量管理做就行，不用额外安全措施」。

我遇到过最典型的例子：某款车的中控屏黑屏了，但仪表盘正常。这算不算安全风险？算，但 ASIL 等级很低，因为驾驶员还能看仪表。可如果黑屏的是仪表盘呢？那至少是 ASIL B 起步。

维度	等级	说明
Severity	S0-S3	无伤 → 致命
Exposure	E0-E4	几乎不暴露 → 几乎每次驾驶都暴露
Controllability	C0-C3	完全可控 → 几乎不可控

安全目标定义：把「危险」翻译成「要求」

有了 ASIL 等级，下一步就是定义安全目标（Safety Goal）。安全目标是一句话：「防止某某危险事件发生」。

举个例子：

• 危险事件：倒车影像延迟超过 2 秒，导致驾驶员撞到后方行人。
• 安全目标：倒车影像的端到端延迟不得超过 200ms。

你看，安全目标必须具体、可测量、可验证。不能写「倒车影像要快」，要写「从摄像头采集到屏幕显示，总延迟 ≤ 200ms」。

我见过最坑的写法是：「系统应保证安全」。这等于没写。安全目标要像需求文档里的验收标准一样，能拿秒表去测。

功能安全概念：怎么实现安全目标？

安全目标定好了，接下来就是功能安全概念（Functional Safety Concept, FSC）。它回答的是：用什么样的功能机制来保证安全目标达成？

FSC 通常包含：

• 故障检测机制：怎么发现出问题了？
• 故障响应机制：发现问题后怎么办？
• 降级模式：系统还能不能继续用？
• 驾驶员通知：要不要告诉驾驶员？

拿刚才的倒车影像举例：

• 检测机制：每帧图像打时间戳，监控延迟是否超过阈值。
• 响应机制：延迟超标时，立即显示「摄像头故障」提示，并发出声音警告。
• 降级模式：影像不可用，但倒车雷达继续工作。
• 通知方式：中控屏弹窗 + 蜂鸣器。

安全机制：把概念落地成技术

安全机制（Safety Mechanism）是 FSC 的具体实现。它可以是硬件、软件，或者软硬结合。常见的座舱安全机制包括：

• 看门狗定时器：监控主芯片是否「死机」。
• 内存保护单元（MPU）：防止不同进程互相干扰。
• 双核锁步：两个核跑同样的代码，结果不一致就报错。
• 数据校验（CRC/ECC）：确保传输和存储的数据没被篡改。
• 心跳监控：模块之间定期互报「我还活着」。

我个人的习惯是：安全机制不要贪多。够用就行，多了反而增加复杂度，引入新的失效点。曾经有个项目，工程师给一个 QM 功能加了双核锁步，结果导致系统启动时间超标，最后不得不去掉——这就是典型的「过度设计」。

知识体系总览

下面这张图把本章的核心逻辑串起来了。你可以把它当作一个「功能安全入门地图」：

这张图从左到右、从上到下展示了功能安全的核心流程。你仔细看：ASIL 等级决定了安全目标的严格程度，安全目标决定了功能安全概念的设计范围，功能安全概念又决定了安全机制的选择。一环扣一环，不能跳步。