4. 安全生命周期模型
系统级开发，是整个功能安全落地的核心环节。说白了，就是把安全需求变成实实在在的设计。我见过不少项目，前期需求写得漂亮，一到系统设计就乱了套。为什么？因为技术安全概念没想透，架构设计没考虑安全机制，FMEA和FTA更是流于形式。
这一章，我们就来聊聊系统级开发的三个关键输出：技术安全概念（TSC）、系统架构设计，以及FMEA与FTA分析。这三者不是孤立的，而是环环相扣的。
4.1 技术安全概念（TSC）
技术安全概念，是把功能安全需求（FSR）转化为具体技术实现的第一步。我个人习惯，把TSC看作一座桥梁——桥的一头是功能安全需求，另一头是硬件和软件的实现。
4.1.1 TSC的核心要素
一个完整的技术安全概念，至少需要包含以下内容：
- 安全机制的定义：每个安全目标，都需要对应的安全机制来实现。比如，针对“防止非预期加速”这个安全目标，你可能需要“监控油门踏板信号合理性”这个安全机制。
- 故障检测与响应：安全机制如何检测故障？检测到故障后，系统如何响应？是降级、报警，还是进入安全状态？
- 安全状态的定义：系统进入安全状态后，具体表现是什么？比如，电机控制器进入“主动短路”状态，或者转向系统进入“机械锁止”状态。
- 故障容错时间间隔（FTTI）：从故障发生到系统进入安全状态，允许的最大时间。这个时间必须被分解到各个子系统。
关键点：TSC不是写文档，而是做设计。每个安全机制都要落实到具体的硬件引脚、软件函数、通信报文上。
4.1.2 我的实战经验
我曾经在一个EPS（电动助力转向）项目中，遇到过一个典型的TSC设计问题。安全目标是“防止非预期转向”，对应的安全机制是“监控扭矩传感器信号”。
一开始，团队只写了“监控扭矩传感器信号”几个字。我问他们：怎么监控？用硬件比较器还是软件算法？监控的阈值是多少？检测到故障后，是切断助力还是保持助力？
嗯，这里要注意。TSC必须具体到可执行的程度。后来我们重新定义了TSC：
- 安全机制：软件冗余校验（主核与校验核交叉比较扭矩值）
- 检测阈值：偏差超过5%持续10ms
- 响应：切断助力，进入“手动转向”安全状态
- FTTI：从故障发生到切断助力，不超过100ms
这样，硬件工程师和软件工程师拿到TSC，就知道该做什么了。
4.2 系统架构设计
系统架构设计，是TSC的载体。一个好的架构，能让安全机制高效运行；一个糟糕的架构，会让安全机制变成累赘。
4.2.1 架构设计原则
我个人总结了几条架构设计原则：
- 独立性：安全相关功能与非安全相关功能要隔离。比如，ASIL D的功能不能和QM功能共用同一个内存区域。
- 模块化：每个安全机制要封装成独立的模块，便于分析和测试。
- 可诊断性：架构要支持故障注入和诊断。你想想看，如果连故障都模拟不了，怎么验证安全机制？
- 可扩展性：架构要预留接口，方便后续增加新的安全功能。
4.2.2 架构设计中的安全分解
有时候，一个ASIL D的功能，可以通过架构分解来实现。比如，把ASIL D分解为ASIL B(D) + ASIL B(D)，两个冗余通道互相监控。
| 分解方式 | 说明 | 典型应用 |
|---|---|---|
| 同质冗余 | 两个相同的通道，互相校验 | 传感器信号校验 |
| 异质冗余 | 两个不同的通道，实现同一功能 | 主核+校验核 |
| 功能分解 | 把高ASIL功能拆成多个低ASIL子功能 | ASIL D分解为ASIL B(D)+ASIL B(D) |
小技巧：做架构分解时，一定要考虑“共因失效”。两个通道如果共用同一个电源或时钟，那分解就失去了意义。
4.3 FMEA与FTA分析
FMEA和FTA，是系统级开发中最重要的两种分析方法。它们不是用来应付审核的，而是用来发现设计缺陷的。
4.3.1 FMEA（失效模式与影响分析）
FMEA是一种“自下而上”的分析方法。从每个组件的失效模式出发，分析它对系统的影响。
我建议，FMEA要在架构设计完成后立即开始。为什么？因为这时候设计还没定型，发现问题还能改。等设计冻结了再改，成本就高了。
FMEA的核心步骤：
- 识别失效模式：每个组件可能发生什么故障？比如，电阻开路、电容短路、软件跑飞。
- 分析影响：这个失效模式会导致什么后果？是功能丧失，还是安全目标被违反？
- 评估严重度（S）：后果有多严重？从S1（轻微）到S3（致命）。
- 评估发生度（O）：这个失效模式发生的概率有多大？从O1（极低）到O10（极高）。
- 评估探测度（D）：现有的安全机制能检测到这个故障吗？从D1（极易检测）到D10（极难检测）。
- 计算风险优先级数（RPN）：RPN = S × O × D。RPN越高，越需要采取措施。
避坑指南：我曾经见过一个团队，把FMEA做成了“填空题”。每个失效模式都写“无影响”，RPN全是1。这样的FMEA，还不如不做。FMEA的核心是“找问题”，不是“填表格”。
4.3.2 FTA（故障树分析）
FTA是一种“自上而下”的分析方法。从顶事件（安全目标被违反）出发，逐层分解，找到所有可能的故障原因。
FTA的典型步骤：
- 定义顶事件：比如，“非预期加速”。
- 构建故障树：用“与门”和“或门”连接各种故障事件。
- 定性分析：找出所有最小割集（导致顶事件发生的最小故障组合）。
- 定量分析：计算顶事件的发生概率（如果已知底事件的失效率）。
FTA和FMEA是互补的。FMEA帮你发现“这个组件坏了会怎样”，FTA帮你回答“这个故障是怎么发生的”。
4.4 知识体系总览
下面这张图，展示了系统级产品开发的核心逻辑。你可以看到，从安全目标出发，经过TSC、架构设计、FMEA/FTA，最终形成可落地的系统设计。
4.5 本章小结
系统级产品开发，是功能安全落地的关键。技术安全概念要具体到可执行，架构设计要遵循独立性和模块化原则，FMEA和FTA要真正用来发现设计缺陷。
我个人觉得，很多项目在系统级开发上栽跟头，不是因为技术难，而是因为态度不端正。把FMEA当成“交作业”，把TSC写成“空话”，这样的项目，审核能过，但产品不安全。
嗯，这一章的内容就到这里。记住，系统级开发不是流程，是工程实践。多问自己几个“为什么”，多想想“如果这个坏了会怎样”，你的设计就会越来越扎实。