第4章：安全目标定义
各位工程师朋友，今天我们来聊聊安全目标定义。说实话，这是功能安全开发中最关键的一环。我见过太多项目，前期安全目标没定清楚，后期改得死去活来。嗯，咱们今天就把这块掰开揉碎了讲。
4.1 安全目标(Safety Goal)的制定
安全目标是什么？说白了，就是「系统出了故障，也不能让用户受伤」。它是对每个危害事件提出的最高层级安全要求。
我个人习惯，在制定安全目标时，会先问自己三个问题：
- 什么情况会出人命？（危害事件）
- 怎么避免出人命？（安全目标）
- 出了事怎么办？（安全状态）
举个例子。我在做EPS（电动助力转向）项目时，有个危害事件是「转向系统非预期助力输出」。对应的安全目标就是：「防止转向系统产生非预期的助力扭矩，导致车辆偏离预期路径。」
这里有几个关键点，我踩过坑，你们注意：
我曾经犯过一个错误——安全目标写得太笼统。比如「系统不能失效」，这等于没写。安全目标必须具体到：什么功能、什么故障、什么后果、什么等级。
安全目标的ASIL等级怎么定？直接继承自危害分析和风险评估（HARA）的结果。比如上面那个EPS的例子，如果HARA分析出来是ASIL D，那安全目标就是ASIL D。
4.2 安全状态定义
安全状态，就是系统出了故障后，要进入一个「不会造成伤害」的状态。你想想看，车在高速上跑着，突然转向系统报故障了，总不能直接锁死方向盘吧？
常见的几种安全状态：
| 安全状态类型 | 说明 | 典型场景 |
|---|---|---|
| 降级模式 | 部分功能受限，但能安全运行 | EPS降为纯机械转向 |
| 安全关闭 | 系统有序关闭，进入休眠 | BMS检测到过温，切断高压 |
| 故障容错 | 冗余通道接管，维持功能 | 双MCU互为备份 |
| 紧急操作 | 执行预设的安全动作 | 安全气囊点爆 |
我在项目中遇到过一个问题：安全状态定义得太理想化。比如要求「系统在10ms内进入安全状态」，但实际硬件响应时间根本达不到。所以，安全状态一定要结合硬件能力来定义。
定义安全状态时，最好拉上硬件工程师一起讨论。我曾经自己拍脑袋定了安全状态，结果硬件说「这个状态我实现不了」，只能返工。嗯，血的教训。
4.3 容错时间间隔(FTTI)设定
FTTI，全称Fault Tolerant Time Interval。说白了，就是从故障发生到系统进入安全状态，这段时间不能超过某个阈值。超过这个阈值，就可能出人命。
FTTI怎么定？我一般分三步走：
- 分析危害的时间窗口：故障发生后，多久会产生危害？
- 考虑人的反应时间：驾驶员需要多久才能做出反应？
- 留出安全余量：不能卡着极限值设计，要留余量。
举个例子。制动系统的FTTI，通常要求在100ms以内。为什么？因为100ms之后，车辆可能已经发生了不可控的偏移。我做过一个项目，FTTI要求50ms，结果诊断电路设计得特别复杂。后来发现，其实100ms也够用，白白增加了成本。
FTTI ≥ 故障检测时间 + 故障响应时间 + 进入安全状态的时间
注意：这个不等式必须成立，否则安全目标无法满足。
FTTI的设定，还要考虑ASIL等级。ASIL D的系统，FTTI通常更严格。我见过一个ASIL B的系统，FTTI给了500ms，因为危害本身发展得慢。所以，不要盲目追求短FTTI，够用就行。
4.4 三者之间的关系
安全目标、安全状态、FTTI，这三者是铁三角。安全目标告诉你「要做什么」，安全状态告诉你「做成什么样」，FTTI告诉你「多快做到」。
我画了一张图，帮你们理解这个关系：
你看，这三者缺一不可。安全目标定得再好，没有安全状态，系统就不知道往哪走。安全状态定义得再清楚，FTTI不满足，危害照样发生。
4.5 实战中的常见问题
我总结几个实战中容易踩的坑：
- 安全目标与安全状态脱节：目标说「防止过温」，状态却只做了「报警」，没有切断电源。这等于白做。
- FTTI过于乐观：不考虑诊断电路的延迟、通信的延迟、执行器的响应时间。我曾经吃过这个亏，后来老老实实加了20%的余量。
- 忽略多故障场景：只考虑单点故障，没考虑多点同时失效。嗯，ISO 26262要求考虑双点故障，别偷懒。
安全目标、安全状态、FTTI，这三者必须在安全概念阶段就确定下来。不要等到详细设计阶段再补，那时候改起来成本太高了。
好了，这一章的内容就到这里。安全目标定义是整个功能安全开发的基石，希望大家在实际项目中能灵活运用。记住，安全不是做给别人看的，是真正保护生命的。
公众号:蓝海资料掘金营，微信deep3321