系统级设计：技术安全概念、系统架构设计、FMEA/FTA分析、安全机制设计
各位工程师，欢迎来到系统级设计这一章。说实话，很多团队在功能安全上栽跟头，就是栽在系统级设计这个环节。你想想看，需求分析做得再好，如果系统架构设计有漏洞，后面的软件、硬件设计再完美，也是白搭。
我个人习惯把系统级设计比作盖房子的蓝图。蓝图画歪了，后面装修得再好，房子也是危房。这一章，我们就来聊聊怎么把这张“蓝图”画对、画好。
4.1 从安全目标到技术安全概念
安全目标（Safety Goal）是顶层的安全要求，比如“车辆在行驶中不能非预期加速”。但怎么实现这个目标？这就需要技术安全概念（Technical Safety Concept, TSC）了。
TSC说白了，就是把抽象的安全目标，翻译成具体的技术实现方案。它要回答三个问题：
- 检测什么？——哪些故障需要被探测到？
- 怎么响应？——探测到故障后，系统要做什么？
- 如何避免？——怎么设计才能让故障不发生，或者发生时危害最小？
我在项目中遇到过这样一个案例：一个ASIL D的线控制动系统，安全目标是“制动失效概率低于某个阈值”。团队一开始只关注了电子控制单元的冗余，却忽略了机械执行机构的单点故障。结果FMEA一分析，发现一个简单的弹簧断裂就能导致制动失效。这就是TSC没做透的典型问题。
关键点：技术安全概念不是简单的“加个冗余”或“加个监控”，它需要系统性地考虑所有可能的故障模式，并分配对应的安全机制。
4.2 系统架构设计：安全与功能的平衡
系统架构设计，是技术安全概念的物理载体。你不可能在架构里塞满冗余和监控，那样成本太高，性能也会受影响。怎么平衡？我建议遵循几个原则：
- 独立性：安全相关功能与非安全相关功能要隔离。比如，制动系统的控制单元，最好不要和娱乐系统的控制单元共用同一个芯片。
- 故障隔离：一个部件的故障，不能蔓延到其他部件。这通常通过硬件分区、软件分区、以及通信协议的错误检测机制来实现。
- 可诊断性：架构要设计得方便诊断。比如，关键信号要有测试点，关键路径要有回读通道。
嗯，这里要注意，架构设计不是一蹴而就的。它需要反复迭代。我记得有一次，我们设计一个ADAS的感知融合架构，最初方案是把所有传感器数据都送到一个中央域控制器处理。结果一算，通信带宽和算力需求都爆了。后来改成边缘计算+区域融合的架构，才把问题解决。
下面这张图，展示了一个典型的系统架构设计流程，以及它与安全分析的关系：
4.3 FMEA与FTA：安全分析的双刃剑
FMEA（失效模式与影响分析）和FTA（故障树分析）是系统级安全分析的两大工具。很多新人会问：“到底用哪个？”我的回答是：两个都要用，但侧重点不同。
| 分析工具 | 分析方向 | 核心问题 | 输出结果 |
|---|---|---|---|
| FMEA | 自下而上（Bottom-Up） | 如果这个部件失效了，会发生什么？ | 失效模式、影响、严重度、探测度 |
| FTA | 自上而下（Top-Down） | 这个顶层故障是怎么发生的？ | 故障树、最小割集、失效概率 |
我个人习惯是：先用FMEA做一遍全面的“扫描”，找出所有可能的单点故障和潜在风险。然后，针对FMEA中识别出的高风险项，再用FTA做“深度剖析”，找出故障的根本原因和组合路径。
实战技巧：做FMEA时，不要只盯着硬件。软件逻辑错误、通信超时、甚至人为操作失误，都要考虑进去。我曾经见过一个FMEA，把“软件跑飞”这个失效模式漏掉了，结果在实车测试时，一个意外的中断导致系统进入了死循环，差点出事。
4.4 安全机制设计：把理论变成代码
安全机制，就是用来检测、响应和避免故障的具体实现。它是技术安全概念的落地。常见的系统级安全机制包括：
- 冗余设计：比如双通道制动系统，一个通道失效，另一个通道还能工作。
- 监控与看门狗：监控程序运行状态，如果程序卡死或跑飞，看门狗会触发系统复位。
- 错误纠正码（ECC）：用于内存和通信数据，可以检测并纠正单比特错误。
- 比较器：两个独立的计算单元执行相同任务，比较结果是否一致。
- 故障响应策略：比如降级模式（Degraded Mode）、安全状态（Safe State）、故障容错（Fail-Operational）。
设计安全机制时，有一个坑要特别注意：安全机制本身也可能失效。比如，看门狗芯片自己坏了怎么办？所以，安全机制也需要被监控，这就是所谓的“诊断覆盖率”问题。
避坑指南：我曾经设计过一个安全机制，用软件来监控另一个软件模块的输出。结果FTA分析发现，如果监控软件和被监控软件因为同一个原因（比如供电电压异常）同时失效，这个安全机制就形同虚设。后来我们改成了硬件监控，才解决了这个问题。记住：安全机制要有独立性，不能有共因失效。
下面是一个简单的安全机制设计示例，用于监控一个关键传感器的输出是否合理：
// 传感器值合理性检查
// 假设传感器正常范围是 0-100，变化率不超过 50/s
bool sensor_plausibility_check(float current_value, float previous_value, uint32_t time_diff_ms) {
// 1. 范围检查
if (current_value < 0.0f || current_value > 100.0f) {
return false; // 超出范围，故障
}
// 2. 变化率检查
float delta = current_value - previous_value;
float max_delta = 50.0f * (time_diff_ms / 1000.0f);
if (fabs(delta) > max_delta) {
return false; // 变化过快，故障
}
// 3. 如果都通过，返回正常
return true;
}这个例子虽然简单，但它体现了安全机制设计的核心：明确故障模型（范围超限、变化率超限），然后设计对应的检测逻辑。在实际项目中，你还需要考虑检测的周期、故障确认的延时（比如连续几次检测到故障才确认）、以及故障后的响应动作。
好了，系统级设计的内容就讲到这里。记住，这一阶段的工作质量，直接决定了后续开发的风险和成本。多花点时间在架构和安全分析上，绝对是值得的。