3、功能安全基础（ISO 26262）：ASIL等级定义、安全目标设定、线控转向的ASIL D要求
好，咱们进入正题。功能安全，说白了就是「万一出错了，车也不能乱来」。ISO 26262 这个标准，搞底盘电控的工程师没人不知道。今天我就结合线控转向，聊聊 ASIL 等级、安全目标，以及为什么线控转向必须上 ASIL D。
3.1 ASIL 等级：从 A 到 D，危险程度递增
ASIL，全称 Automotive Safety Integrity Level，汽车安全完整性等级。它分四个级别：A、B、C、D。D 是最严苛的，要求故障率低到几乎不可能发生。
怎么定级？看三个参数：
- 严重度（Severity）：出事后，人受伤有多重？
- 暴露概率（Exposure）：这种情况发生的频率高不高？
- 可控性（Controllability）：驾驶员能不能在出事前救回来？
举个例子。线控转向如果突然失效，方向盘和车轮脱开了。你想想看，高速上突然没转向，那是什么后果？严重度肯定是 S3（生命危险），暴露概率 E4（几乎每次开车都会用到转向），可控性 C3（普通人根本控制不住）。三个参数一组合，ASIL D 就跑不掉了。
核心结论：线控转向的转向执行功能，默认就是 ASIL D。这不是拍脑袋定的，是风险评估算出来的。
3.2 安全目标设定：从「失效」反推「要求」
安全目标，就是「系统不能出现什么情况」。比如：
- 「不能发生非预期的转向」
- 「不能丢失转向能力」
- 「不能输出错误的转向角度」
每个安全目标都要分配一个 ASIL 等级。线控转向里，我见过最典型的两个安全目标：
| 安全目标编号 | 描述 | ASIL等级 |
|---|---|---|
| SG-01 | 避免非预期的转向执行 | ASIL D |
| SG-02 | 避免转向功能完全丧失 | ASIL D |
我个人习惯，在项目初期就把安全目标写进系统需求文档里。这样后续的硬件设计、软件架构、测试用例，全都有据可依。
一个小技巧：安全目标不要写得太笼统。比如「转向要可靠」这种话，没法验证。要写成「当检测到主控制器失效时，备份控制器必须在 50ms 内接管，且转向角度误差不超过 ±1°」。
3.3 线控转向的 ASIL D 要求：到底严在哪？
ASIL D 的要求，说白了就是「双倍冗余 + 全面诊断」。我拆开来讲：
3.3.1 硬件冗余
线控转向的 ECU、传感器、执行器，至少得有两套。一套坏了，另一套立刻顶上。我曾经在一个项目里见过，客户要求三冗余——主、副、应急，三套独立供电。嗯，成本确实高，但安全裕度也真的大。
3.3.2 软件诊断
软件里要跑各种监控：
- 看门狗定时器（监控程序是否跑飞）
- 内存校验（ECC 或 CRC）
- 通信校验（比如 CAN 的 CRC 和序列计数器）
- 逻辑自检（比如输入输出一致性检查）
我举个例子，诊断覆盖率要求：
| 故障类型 | 最低诊断覆盖率 |
|---|---|
| 单点故障 | ≥ 99% |
| 潜伏故障 | ≥ 90% |
说白了，ASIL D 要求你几乎能发现所有可能的故障。漏掉一个，就可能出大事。
3.3.3 安全机制示例
我画了一张图，帮你理解线控转向的安全架构：
你看，主控制器和备份控制器是独立的。传感器也是两组。执行器本身有容错设计。最底下还有一层诊断监控，时刻盯着有没有异常。这就是 ASIL D 的典型架构。
避坑指南：我曾经在一个项目里，备份控制器和主控制器共用了一路电源。结果主控制器短路，备份也跟着掉电。嗯，这就是典型的「共因失效」。ASIL D 要求必须做共因失效分析，把这种坑提前填上。
3.4 小结
功能安全不是写写文档就完事的。它贯穿整个开发流程。线控转向的 ASIL D 要求，逼着我们从架构设计、硬件选型、软件开发到测试验证，每一步都得考虑「如果这里坏了，怎么办？」。说白了，安全是设计出来的，不是测试出来的。
好，这一章就聊到这儿。下一章我们聊聊功能安全的具体实现方法——故障树分析（FTA）和失效模式与影响分析（FMEA）。