如果功能安全不是补文档,那么它到底应该交付什么?

这套体系的核心，不是把 HARA、FMEA、Safety Case 当作孤立文件，而是把安全目标、安全需求、安全机制、安全验证和安全证据串成一条完整链路。

可以把安全交付体系理解为六个层次。

一、Requirement Input：安全相关需求输入

安全交付首先要有输入。

这些输入可能来自法规标准、客户要求、行业规范、实际使用场景、历史故障数据，也可能来自企业内部的安全策略。

对于汽车电子和智能产品来说，安全需求不能只写成“系统应安全可靠”这种泛化表述，而要明确到具体场景、具体风险和具体约束。

例如，在传感器异常、通信中断、电源波动、执行器卡滞、控制指令异常时，系统应该检测什么、判断什么、限制什么、进入什么状态。

没有清晰的安全输入，后续所有设计和验证都会失去判断基准。

二、Product Definition：产品边界与使用场景

安全分析必须基于产品定义。

产品能做什么，不能做什么；在哪些环境中使用，不在哪些环境中使用；由谁操作，和谁交互；正常工况是什么，异常工况是什么。

这些边界如果不清楚，风险分析就会失焦。

很多安全问题并不是来自某一个技术点，而是来自产品边界不清。例如系统本来只适用于限定速度、限定区域、限定环境，但在产品描述、客户沟通或实际使用中被扩大了能力边界，安全机制却没有随之扩展。

所以，产品定义不是市场文案，而是安全分析的前提。

三、Technical Contract：技术合同

安全目标不能停留在需求文档中，必须进入技术合同。

所谓技术合同，就是系统架构、接口、状态机、诊断机制、降级策略、故障响应和验证方式之间的明确约定。

它回答的是：这个系统如何实现安全？

例如，异常检测由哪个模块完成，诊断结果如何传递，故障等级如何划分，降级策略由谁执行，安全状态如何保持，恢复条件是什么，相关日志和证据如何记录。

没有技术合同，安全需求就容易在架构和实现中丢失。

四、Phase Target / Task Contract：阶段目标与任务契约

功能安全交付不能等到最后才检查。每个阶段都应该有明确的安全任务和验收边界。

需求阶段要完成安全输入和追溯关系。架构阶段要完成安全机制分解和接口约束。设计阶段要完成机制设计、异常路径和降级策略评审。实现阶段要完成代码、配置、诊断逻辑和状态机实现。测试阶段要完成安全需求对应的验证证据。交付阶段要形成可审计的安全论证材料。

阶段目标越清楚，后期补救越少。

五、Verification Evidence：验证证据

安全验证不是简单说明“已经测试通过”，而是要形成证据。

证据应能够回答：测试覆盖了哪个安全需求？触发了哪个异常场景？观察到了什么系统行为？结果是否满足预期？日志、截图、数据、测试报告是否能支撑结论？

证据越具体，Safety Case 越可信。

六、Safety Case：安全论证

Safety Case 不是最后写出来的总结文档，而是前面所有活动自然沉淀出来的论证结果。

它应该基于完整链路：安全目标 → 安全需求 → 安全机制 → 设计实现 → 验证结果 → 证据材料 → 安全结论。

如果前面没有过程证据，Safety Case 就只能是文档拼接。如果前面有完整证据链，Safety Case 就是安全交付的自然结果。

因此，真正的安全交付体系，交付的不是一堆文件，而是一套可以证明系统安全性的工程证据链。