3、安全生命周期管理：功能安全管理、安全计划制定、安全案例编写

聊到安全生命周期管理，很多工程师第一反应就是「做文档」。嗯，这话对了一半。文档是载体，但核心是管理思路。我做了这么多年功能安全，最大的体会是：安全不是测出来的，也不是写出来的，是管出来的。

这一节，我们聚焦三个实操点：功能安全管理、安全计划制定、安全案例编写。说白了，就是告诉你「怎么管」、「管什么」、「怎么证明你管好了」。

3.1 功能安全管理——别让安全变成「打补丁」

功能安全管理，不是搞个流程挂在墙上。它要落地到项目里。我个人习惯，在项目启动阶段就把安全管理的角色和职责定死。谁负责危害分析？谁负责安全需求评审？谁负责测试验收？这些必须白纸黑字写清楚。

我在项目中遇到过一种情况：安全经理和系统架构师各干各的，结果安全需求跟系统设计对不上。返工？那都是小事，关键是项目延期，成本翻倍。

你想想看，如果安全管理和项目管理是两张皮，那安全活动永远是被动的。我建议把安全活动嵌入到项目里程碑里。比如，Gate Review的时候，安全评审必须通过，否则不能进入下一阶段。

3.2 安全计划制定——别让计划变成「废纸」

安全计划，是安全生命周期管理的「宪法」。它规定了整个项目怎么做安全。但很多公司的安全计划，模板一抄，改个项目名就完事了。这不行。

我制定安全计划时，会问自己三个问题：

1. 这个项目的ASIL等级是多少？ —— 决定了安全活动的深度和广度。
2. 我们有哪些安全活动要做？ —— 从HARA开始，到安全确认结束，每个活动的时间节点、责任人、交付物。
3. 出了偏差怎么办？ —— 安全计划的变更管理流程。

安全计划里，必须包含以下内容：

安全活动	输入	输出	责任人
危害分析与风险评估（HARA）	系统定义、功能列表	安全目标、ASIL等级	安全经理 + 系统工程师
安全需求定义	安全目标	功能安全需求、技术安全需求	系统工程师
安全设计	安全需求	安全架构、安全机制	硬件/软件工程师
安全测试	安全需求、安全设计	测试报告、覆盖率分析	测试工程师
安全确认	所有安全交付物	安全案例	安全经理

这里有个细节：安全计划不是一成不变的。项目过程中，需求变了、架构改了，安全计划也得跟着调整。我习惯在安全计划里专门写一节「变更管理」，明确什么级别的变更需要重新评审。

3.3 安全案例编写——用证据说话

安全案例，是安全生命周期管理的「毕业设计」。它要证明：这个系统是安全的。说白了，就是把你做过的所有安全活动，整理成一份有逻辑、有证据的报告。

我写安全案例时，遵循一个原则：「你说你安全，证据呢？」

安全案例的结构，我推荐用GSN（目标结构符号）来组织。但实际项目中，很多客户要求的是表格形式。没关系，核心逻辑是一样的：

• 安全目标：从HARA里来的，比如「转向系统在单点故障下，仍能保持50%的助力」。
• 安全论据：为什么这个目标是安全的？比如「我们设计了冗余供电回路」。
• 安全证据：证明论据成立的文档或数据。比如「冗余供电回路的FMEA报告」、「故障注入测试报告」。

下面是一个简化的安全案例片段：

安全目标：SG-01 转向助力在单点故障下，仍能提供至少50%的助力。
ASIL等级：ASIL D

安全论据：
  1. 供电系统采用双冗余设计（主电源 + 备份电源）。
  2. 主电源失效时，备份电源在10ms内接管。
  3. 备份电源的容量足以提供50%助力持续30秒。

安全证据：
  - 供电架构设计文档（v2.3）
  - 备份电源切换时间的仿真报告（Sim-2024-001）
  - 故障注入测试报告（Test-2024-015），测试结果：切换时间平均8.5ms
  - 备份电源容量计算书（Calc-2024-003）

写安全案例，最怕什么？最怕证据和论据对不上。我见过一个项目，安全案例里写「通过了所有测试」，但测试报告里有一项没通过，也没解释。这种安全案例，审核员一看就摇头。

3.4 知识体系总览

为了让你更直观地理解安全生命周期管理的全貌，我画了一张图。这张图展示了从安全计划到安全案例的完整逻辑链条。

这张图你看懂了吗？安全计划是起点，安全活动是过程，安全案例是终点。但别忘了，中间还有反馈循环。项目做完了，安全案例写完了，不代表就结束了。经验教训要反馈到下一个项目的安全计划里。

嗯，这一节的内容就到这里。安全生命周期管理，说白了就是「说到做到，还要有证据」。你只要把计划、执行、证据这三个环节打通了，安全就不再是负担，而是项目的护城河。