1. 功能安全基础：什么是功能安全？为什么需要冗余？ISO 26262 标准概述

1.1 到底什么是功能安全？

说实话，我刚入行那会儿，也以为功能安全就是「系统别坏」。后来被一个项目狠狠教育了——系统确实没坏，但一个软件逻辑错误，直接让执行器在高速上误动作。嗯，从那以后我才真正理解：功能安全不是防故障，而是防「故障带来的危害」。

用一句话说清楚：功能安全 = 当系统出现故障时，它依然能保证不伤害人、不损坏财产、不污染环境。

它关注的是「系统性失效」和「随机硬件失效」这两类问题。你想想看，一个刹车系统，芯片本身没坏，但软件把刹车力度算错了——这叫系统性失效。反过来，芯片内部一个晶体管被高能粒子打穿，这叫随机硬件失效。功能安全要同时管住这两头。

1.2 为什么需要冗余？

这个问题，我在给团队做培训时经常被问到：「既然芯片可靠性已经很高了，为什么还要搞冗余？」

我的回答很简单：单点故障是躲不开的物理现实。你用的车规级芯片，失效率可能是 10 FIT（1 FIT = 10⁻⁹ 小时⁻¹），听起来很低对吧？但一辆车上有上百个芯片，整个车队跑下来，故障就是必然事件。

冗余的本质，就是给系统装一个「备胎」。当主通道失效时，备份通道能立刻接管，让系统进入安全状态。

我个人习惯把冗余分成三个层次：

• 硬件冗余：双芯片、双传感器、双执行器。最直接，也最贵。
• 信息冗余：同样的数据用不同算法算两遍，比如 ECC 校验、CRC 校验。
• 时间冗余：同一个任务在时间上错开执行两次，比如软件自检、回滚机制。

我曾经在一个线控制动项目里，遇到过传感器单点失效导致误触发的情况。当时客户要求 ASIL D，我们不得不把轮速传感器从单路改成双路冗余，再加一个异构的霍尔传感器做交叉校验。成本确实上去了，但安全等级也实打实达标了。

1.3 ISO 26262 标准概述

ISO 26262 是汽车行业的功能安全国际标准，全称叫「Road vehicles — Functional safety」。它从 2011 年发布第一版，2018 年更新到第二版，现在已经是行业硬门槛。

这个标准覆盖了从概念阶段到生产退役的全生命周期。我把它拆成几个核心部分：

部分	内容	我的理解
Part 1-2	术语、定义、总体框架	先搞清楚你在说什么
Part 3	概念阶段（HARA、安全目标）	最关键的起点，错了后面全白干
Part 4-6	系统、硬件、软件层面开发	落地干活的地方
Part 7-9	生产、运行、支持、ASIL 分解	别以为设计完就完了
Part 10-12	指南、半导体、摩托车	第二版新增的扩展

标准里最核心的概念是 ASIL（Automotive Safety Integrity Level），分四个等级：A、B、C、D。ASIL D 是最严格的，要求失效率低于 10 FIT，而且必须有冗余架构。我做过一个 ASIL D 的转向系统，光安全机制就写了 200 多条，评审会开了整整两周。

1.4 功能安全与冗余的关系图

下面这张图，是我自己画的功能安全与冗余的顶层关系。你可以看到，从「危害」出发，经过「风险分析」得到「安全目标」，然后通过「安全机制」落地，而冗余是安全机制中最核心的手段之一。

1.5 我的经验总结

做了这么多年功能安全，我最大的体会是：冗余不是万能药，但没有冗余万万不能。你设计冗余架构时，一定要想清楚三个问题：

1. 冗余给谁用？ 是给传感器、控制器还是执行器？
2. 冗余怎么切？ 是热备份还是冷备份？切换时间能不能满足安全要求？
3. 冗余怎么验证？ 故障注入测试做了吗？共因失效分析做了吗？

我记得有一次评审，一个年轻工程师问我：「既然冗余这么重要，那是不是所有信号都要冗余？」我反问他：「你愿意为每个无关紧要的指示灯多付一倍的成本吗？」功能安全讲究的是「合理」，不是「过度」。ASIL 等级决定了你的冗余深度，别盲目堆料。