第4章：安全目标定义——为LKA系统定义具体、可量化的安全目标

好，咱们进入正题。

上一章我们做了HARA，拿到了ASIL等级。但说实话，那只是第一步。你想想看，光知道「这个功能要ASIL B」有什么用？你得把它翻译成工程师能干活的语言。这就是安全目标。

我个人习惯，把安全目标叫做「功能安全的总开关」。它不直接写代码，但它决定了你所有设计的上限和下限。我见过不少项目，HARA做得漂漂亮亮，一到安全目标就含糊其辞——结果后期返工，苦不堪言。

4.1 安全目标长什么样？

先给个直观印象。安全目标不是「系统要安全」这种废话。它必须满足三个条件：

• 具体：什么场景？什么失效？
• 可量化：多少时间？多少概率？
• 可验证：测试能不能证明它达成了？

举个例子，LKA系统的安全目标，我通常会写成这样：

你看，这里面有具体数值（0.5秒）、有判定标准（压线外沿）、有触发条件（驾驶员未干预）。这才叫安全目标。

4.2 从HARA到安全目标的映射

我记得有一次评审，有人问我：「你这些安全目标是怎么从HARA里变出来的？」

其实没那么玄。HARA里每个危害事件，至少对应一个安全目标。但要注意，不是一一对应。有时候一个安全目标可以覆盖多个危害事件，有时候一个危害事件需要拆成多个安全目标。

我习惯用一张表来做映射：

危害事件ID	危害描述	ASIL	安全目标ID	安全目标描述
H-01	弯道中LKA误激活，导致车辆转向不足	B	SG-01	系统应避免在弯道中施加超过物理极限的转向扭矩
H-02	直道上LKA无响应，车辆偏离车道	B	SG-02	系统应在检测到偏离趋势后500ms内输出纠正扭矩
H-03	传感器故障导致LKA误判车道线位置	C	SG-03	系统应能在100ms内检测到传感器信号异常并降级

嗯，这里要注意：ASIL等级是从HARA继承过来的。但如果你发现某个安全目标覆盖了多个危害事件，那就取最高的ASIL。别想着取平均，功能安全不吃这套。

4.3 安全目标的量化指标

光有文字描述还不够。你得给每个安全目标配上量化指标。我个人最常用的三个指标：

• FTTI（容错时间间隔）：从失效发生到系统做出反应的最大允许时间。LKA一般500ms~1s。
• FHTI（故障处理时间间隔）：系统从检测到故障到进入安全状态的时间。这个通常比FTTI短。
• PMHF（随机硬件失效率）：对于ASIL B，通常要求小于10^-7/h。但LKA这种非安全关键功能，有时候客户会放宽。

4.4 安全目标的分解

安全目标定好了，接下来要分解到子系统。我习惯用「安全目标→功能安全需求→技术安全需求」这个链条。

举个例子，SG-02（500ms内输出纠正扭矩）可以分解成：

1. 感知层：车道线检测算法必须在200ms内输出偏离概率。
2. 决策层：控制算法必须在100ms内计算出目标扭矩。
3. 执行层：转向系统必须在200ms内响应扭矩请求。

加起来正好500ms。但别忘了留余量。我一般会留20%的余量，也就是实际设计按400ms来搞。为什么？因为测试的时候总有意外，你想想看，温度、老化、电磁干扰，哪个都能让你的延迟往上飙。

4.5 安全目标的验证与确认

安全目标不是写出来就完事了。你得证明它实现了。怎么证明？

• 验证：通过测试、仿真、分析，证明设计满足安全目标。
• 确认：通过整车测试、用户场景测试，证明安全目标在真实世界中有效。

我举个例子。SG-02的验证，我会做三件事：

1. MIL/SIL仿真：在模型里注入车道偏离场景，看系统响应时间。
2. HIL测试：接上真实的转向执行器，测整个闭环延迟。
3. 实车测试：在测试场地上画好车道线，让车以不同速度偏离，记录响应时间。

4.6 常见坑点与经验总结

做了这么多年，我总结几个常见坑：

• 坑1：安全目标太模糊。比如「系统应保证安全」——这种话等于没说。一定要量化。
• 坑2：忽略组合失效。LKA失效的同时，驾驶员也在打瞌睡怎么办？安全目标要考虑多重失效叠加。
• 坑3：FTTI拍脑袋。不跟执行器沟通就定时间，最后发现根本做不到。
• 坑4：安全目标之间冲突。比如SG-01要求快速响应，SG-02要求避免误触发——这两个目标天然矛盾。你得在安全目标里明确优先级。

最后说一句。安全目标定义，说白了就是给整个项目画红线。红线画好了，后面设计、测试、评审都有据可依。红线画歪了，后面全是坑。

我个人习惯，安全目标定稿之前，一定要拉上系统、软件、硬件、测试四个团队一起过一遍。哪怕多花两天时间，也比后期改需求强十倍。

好，这一章就到这儿。下一章我们聊聊功能安全需求怎么写——那才是真正开始干活的地方。