4. 系统级设计：技术安全概念、系统架构设计、安全机制与故障处理
系统级设计，说白了就是把安全需求落地成具体的技术方案。这一步做不好，后面的硬件软件设计全是空中楼阁。我个人习惯，拿到安全目标后，先不急着画框图，而是问自己三个问题：系统怎么检测故障？故障发生后怎么办？怎么保证诊断覆盖率够高？
4.1 从安全目标到技术安全概念
技术安全概念（TSC）是连接安全目标和系统架构的桥梁。它把抽象的安全目标，转化为具体的技术要求。比如安全目标是“防止非预期加速”，TSC就要明确：用什么传感器检测踏板信号？用几路冗余？故障容错时间间隔是多少？
核心要点：TSC必须包含以下要素：
- 故障检测机制（检测什么、怎么检测）
- 故障响应措施（降级、关断、报警）
- 故障容错时间间隔（FTTI）
- 安全状态定义（系统进入什么状态才算安全）
我在项目中遇到过，有些工程师把TSC写成了需求文档的翻版，全是“系统应具备故障检测功能”这种空话。这不行。TSC要具体到：用ADC采样还是数字接口？采样频率多少？故障确认用软件滤波还是硬件去抖？
4.2 系统架构设计原则
系统架构设计，我建议遵循几个基本原则：
- 模块化：每个功能模块职责单一，接口清晰
- 独立性：安全相关模块与非安全模块隔离
- 可诊断性：每个关键路径都要有故障注入点
- 可测试性：安全机制要能在整车或台架上验证
你想想看，如果安全模块和非安全模块共用同一个电源域，一旦非安全模块短路，安全功能也跟着失效，这设计就白费了。
下面这张图展示了典型的系统安全架构分层：
4.3 安全机制分类与设计
安全机制是系统自我保护的“免疫系统”。我习惯把它们分成三类：
| 类别 | 典型机制 | 覆盖的故障模式 | 诊断覆盖率 |
|---|---|---|---|
| 检测机制 | 看门狗、CRC校验、电压监控 | 硬件随机失效、数据损坏 | 90%-99% |
| 响应机制 | 安全关断、降级运行、故障锁定 | 检测到故障后的行为 | N/A |
| 避免机制 | 物理隔离、冗余设计、多样性设计 | 系统性失效、共因失效 | N/A |
我的经验：检测机制要优先考虑硬件实现。软件看门狗容易被“绕过”，硬件看门狗才是真保险。我曾经在一个项目中，软件看门狗被中断服务程序“喂”得妥妥的，CPU都跑飞了还在喂狗，最后不得不改成硬件窗口看门狗。
4.4 故障处理与安全状态
故障处理不是简单的“出错了就停机”。你得考虑：
- 故障确认时间：是瞬时故障还是永久故障？一般用软件去抖或硬件滤波确认
- 故障分级响应：轻微故障可以报警提示，严重故障必须立即进入安全状态
- 安全状态定义：明确什么状态是安全的——比如电机断电、阀门关闭、系统休眠
注意：安全状态不是一成不变的。同一个系统，在不同工况下安全状态可能不同。比如车速120km/h时突然切断动力，反而比不切断更危险。所以安全状态要结合系统上下文定义。
4.5 实战案例：EPS系统安全架构
拿电动助力转向（EPS）系统举个例子。安全目标是“防止非预期转向”，ASIL等级通常是D。我们来看看怎么设计：
- 传感器冗余：扭矩传感器用双路输出，一路模拟、一路数字
- 控制器冗余：主核和监控核锁步运行，互相校验
- 执行器回读：电机位置传感器回读，与指令值对比
- 故障响应：检测到偏差超过阈值，立即切断电机驱动，进入机械转向模式
嗯，这里要注意：EPS的FTTI一般是50-100ms。也就是说，从故障发生到系统进入安全状态，不能超过这个时间。所以安全机制的执行路径要尽量短，不能绕来绕去。
4.6 避坑指南
我这些年踩过的坑，总结几条：
- 诊断覆盖率别拍脑袋：FMEDA里填的覆盖率要有依据，要么来自标准手册，要么来自实测数据
- 安全机制别互相打架：两个安全机制同时触发，可能产生冲突。比如一个要降级，一个要关断，谁优先级高？
- 别忘了故障注入测试：设计阶段就要留好故障注入接口，不然后期验证时哭都来不及
一句话总结：系统级设计不是画几张框图就完事了。每个安全机制都要能回答三个问题——检测什么？怎么响应？覆盖率多少？