目录
-
- 先有安全目标，才有架构
- HARA：先问三个问题，再定安全目标
- 安全状态：故障来了，系统该如何"体面离场"？
- 安全架构的三大支柱：冗余、多样性、监控
-
- [1. 冗余（Redundancy）：不把鸡蛋放在一个篮子里](#1. 冗余（Redundancy）：不把鸡蛋放在一个篮子里)
- [2. 多样性（Diversity）：避免"共因失效"](#2. 多样性（Diversity）：避免“共因失效”)
- [3. 监控机制（Monitoring）：故障必须被"看见"](#3. 监控机制（Monitoring）：故障必须被“看见”)
- 一张安全架构图里藏着的信息
- 一个实战推演：电动助力转向（EPS）的安全架构
- 常见的架构设计陷阱
- 结语：安全架构是"预见失败的艺术"
你刚接到一个线控制动项目，要求达到ASIL D。功能安全团队递给你一句话："车辆在任何单点故障下，都必须能安全停车。" 然后，会议室安静了。从哪里开始？
先有安全目标，才有架构
很多人误以为功能安全就是"堆冗余"：两个MCU、两个电源、两路CAN......那请问：冗余应该加在哪里？不加行不行？加三个会不会过度？
答案取决于一个更上游的东西------安全目标（Safety Goal）。
安全目标是整个安全架构的"宪法人"。它用一句话定义了："系统必须避免什么灾难性行为。" 例如：
- "防止非预期的车辆加速。"
- "防止在行驶中丧失转向助力。"
- "防止制动踏板信号丢失后制动失效。"
每个安全目标都附带着一个 ASIL等级（A~D），这个等级决定了后续所有设计动作的"强度"。ASIL D的目标意味着：单点故障的覆盖率要超过99%、硬件随机失效率要低于10 FIT（1 FIT = 每十亿小时失效1次）、软件开发要采用最严格的编码规范......
那么，安全目标是怎么来的？靠拍脑袋吗？不------靠一套标准化的推导方法 HARA。
HARA：先问三个问题，再定安全目标
HARA（危害分析与风险评估）是一套"脑暴+结构化打分"的流程。通常由系统工程师、功能安全工程师、测试工程师甚至法务一起完成。
步骤1：识别危害事件
想象这辆车可能在什么场景下、因什么故障、导致什么后果。例如：
高速公路上（场景），制动控制器内部的电源芯片突然过压（故障），导致MCU输出的制动压力指令变成最大值（失效模式），车辆突然紧急制动（危害），后车追尾（事故）。
步骤2：给三个维度打分
ISO 26262要求评估三个参数：
- 严重度（S）：一旦发生事故，伤害有多重？S0（无伤）到S3（致命）。
- 暴露率（E）：这个场景发生的概率？E1（极低）到E4（高）。
- 可控性（C）：驾驶员还能不能靠自己避免事故？C1（完全可控）到C3（几乎不可控）。
步骤3：计算ASIL等级
通过查表（标准第3部分有矩阵），三个维度综合得出 ASIL QM, A, B, C, D。
继续上面的例子：
- 高速紧急制动导致追尾 → S2（重伤）
- 高速场景天天遇到 → E4
- 突如其来的全制动，普通人根本来不及反应 → C3
查表：S2+E4+C3 → ASIL C
于是，你得到了一个白纸黑字的安全目标：
SG001：在制动控制器发生电源过压故障时，系统必须避免输出超过30Nm的制动压力（ASIL C）。
安全状态：故障来了，系统该如何"体面离场"？
有了安全目标，下一步要定义：当探测到这个故障时，系统应该进入什么状态 ？这叫安全状态（Safe State）。
常见的三种安全状态：
| 安全状态 | 含义 | 适用场景 |
|---|---|---|
| 静默（Fail‑Silent） | 完全关闭输出 | 非安全相关的信息娱乐系统 |
| 降级（Fail‑Degraded） | 保留部分功能，限制性能 | 转向助力失效后仍保留机械转向 |
| 跛行回家（Limp‑Home） | 以极低速度运行，仅够开到维修点 | 电机控制器过热 |
对于ASIL D的线控制动，静默意味着车轮完全没刹车------这反而更危险。所以往往采用冗余设计：主系统故障后，备用系统（可能是另一个通道或纯机械备份）接管制动。
定义安全状态时必须回答一个时间问题：从故障发生到进入安全状态，最长允许多久？ 这个时间叫 FTTI（Fault Tolerant Time Interval，故障容错时间间隔）。对于制动，FTTI通常只有几十毫秒------比眨眼还快。
安全架构的三大支柱：冗余、多样性、监控
有了目标和安全状态，终于可以画架构图了。工业界最通用的安全架构设计原则可以总结为三条：
1. 冗余（Redundancy）：不把鸡蛋放在一个篮子里
最基本的形式是1oo2（一取二）架构：两个相同的通道并行计算，只有两者一致时才输出。任何一个失效，系统切换或停止。
1oo2D（带诊断的一取二） 更进一步：两个通道互相监控，还能定位是哪一个坏了。这是ASIL D最爱的架构。
真实案例：博世的iBooster（电子制动助力器）内部有两个独立的永磁同步电机绕组和两套功率管------一个坏了，另一个还能提供50%的助力。
2. 多样性（Diversity）：避免"共因失效"
冗余如果两个通道一模一样，可能会被同一个原因干倒（比如一个电源尖峰同时烧坏两路芯片）。多样性就是强制要求：
- 不同型号的MCU（比如英飞凌+瑞萨）
- 不同代码工具链编译的软件
- 不同算法计算同一结果（比如转向角估算用两种原理）
3. 监控机制（Monitoring）：故障必须被"看见"
冗余通道不会自己报警，需要一个独立的监控单元。它在硬件上表现为：
- 看门狗（Watchdog）
- 电压/温度监控芯片
- 硬件安全模块HSM（Hardware Security Module）
在系统层面，监控单元往往被称为 "安全岛"（Safety Island）------一个独立的小型处理器或逻辑电路，专门负责：
- 心跳检测：定期问主MCU"你还活着吗？"
- 程序流监控：检测代码是否跑飞或卡死在循环里
- 内存CRC校验：静态数据有没有被篡改
一张安全架构图里藏着的信息
下图是一个典型的ASIL D制动控制器的安全架构表示：
信号A
信号B
计算结果
计算结果
仲裁通过
故障检测
故障时切断/切换
可选直接切断
踏板位移传感器
主MCU通道A
监控MCU通道B
安全岛
逻辑仲裁
电机驱动
故障响应
注意几个关键点：
- 双通道输入：踏板传感器通常有两路独立信号（甚至不同原理：霍尔+电位计）。
- 独立电源：通道A和通道B使用不同的电源芯片，避免共因失效。
- 交叉对比：主MCU和监控MCU通过SPI或共享RAM交换计算结果，不一致时安全岛切断输出。
- ASIL分解：安全目标ASIL D，但分配给主MCU的是ASIL B(D)，监控MCU也是ASIL B(D)------两者组合起来达到ASIL D。这是合法且常用的降成本技巧(前提是是通过相关失效分析（DFA）证明独立性否则分解不成立)
一个实战推演：电动助力转向（EPS）的安全架构
让我们用上面的原则快速推演一个EPS案例。
安全目标 ：防止在车速>80km/h时丧失转向助力（ASIL D）。
安全状态 ：丧失助力，但保留机械连接（驾驶员仍能用力转动方向盘，属于降级模式）。
FTTI：< 100ms（否则驾驶员可能来不及稳住方向）。
架构决策：
- 冗余供电：主电源12V + 备份电容阵列，确保主供电跌落时仍能工作100ms。
- 双三相电机绕组：一组绕组短路，另一组仍能输出70%扭矩。
- 监控架构：扭矩传感器有两路独立信号（主+辅），主MCU和监控MCU通过锁步核（Lockstep）实现硬件级比较。
- 安全状态进入：一旦比较出错，立即切断功率管的PWM输出，并点亮仪表盘红灯提示"转向助力失效"。
常见的架构设计陷阱
初学者容易犯的几个错误：
- 只加冗余，不加诊断：两个通道各干各的，坏了也不知道。没有监控的冗余等于没有。
- 忽略共因失效 ：两个通道用同一批次的电容，一个批次缺陷导致两个同时失效。标准要求进行共因失效分析（CCF）。
- 安全状态定义错误：有时候完全切断输出反而更危险。比如EPS如果突然"锁死"而不是"变重"，司机根本打不动方向。
- 忘记FTTI：设计了一个完美的故障检测机制，但需要2秒才能完成自检------车已经撞了。
结语：安全架构是"预见失败的艺术"
顶层安全架构不是从完美出发，而是从"假设一切都会坏"出发。好的架构像一支训练有素的消防队：它知道可能的火源在哪里（HARA），它规定了什么情况下必须疏散（安全状态），它配备了多套水枪和备用电源（冗余），还安排了专门的瞭望哨（监控）。
当你画完那张让TÜV审核员点头的架构图时，你实际上已经预见了几千种可能的失效，并且为每一种都安排了退路。
下一篇预告：架构画完了，现在需要把安全需求落实到每一个硬件和软件模块。第3篇《系统级安全设计 ------ 监控者与被监控者的"猫鼠游戏"》将带你设计具体的监控机制------看门狗、程序流监控、E2E通信保护------让你的系统真正"看住自己"。
思考题：如果你负责一个ASIL B的电动尾门控制器，安全目标是"防止尾门在行驶中意外打开"。你会选择哪种安全状态：A) 完全禁止尾门电机供电；B) 降级为手动开启但仍可电动关闭；C) 允许电动开闭，但增加机械锁冗余？为什么？