第2章安全生命周期

2、安全生命周期：整体安全生命周期、产品开发安全生命周期、安全活动与工作产品

聊到功能安全，绕不开的一个核心概念就是「安全生命周期」。

说实话，我见过不少团队，一上来就急着写代码、做测试。结果呢？做到一半发现需求没对齐，或者测试用例根本覆盖不了安全目标。最后只能返工，成本翻倍。嗯，这就是典型的「跳过生命周期」的教训。

ISO 26262 把安全生命周期分成了三个阶段：概念阶段、产品开发阶段、生产与运行阶段。说白了，就是从你脑子里冒出「我要做个安全系统」这个念头开始，一直到这产品报废为止，每一步都有明确的活动。

我个人习惯把整体生命周期画成一个闭环。为什么是闭环？因为安全不是一锤子买卖。你想想看，产品在运行中发现了新 hazard，或者法规变了，你得回头去改。所以生命周期是迭代的。

  核心要点：整体安全生命周期覆盖了从项目启动到退役的全部活动。它确保每个阶段的安全活动都有输入、有输出、有评审。

我记得有一次做 ADAS 项目，客户要求我们提供完整的生命周期文档。当时团队里有人觉得「这不就是走流程吗？」结果审核时，审核员直接问：「你们概念阶段的 hazard 分析，跟系统设计阶段的 safety goal 是怎么 trace 的？」—— 嗯，没有生命周期管理，这种问题根本答不上来。

产品开发安全生命周期，其实就是我们常说的 V 模型。左边是设计，右边是验证，中间是安全活动。

V 模型长什么样？我简单画一下：

需求分析 → 系统设计 → 硬件/软件设计 → 实现
   ↑                                    ↓
   └──── 系统集成测试 ← 硬件/软件测试 ←┘

但这里有个关键点：安全生命周期不是简单的 V 模型。它要求你在每个 V 的节点上，都嵌入安全活动。比如：

我曾经在一个项目中，看到硬件团队和软件团队各自为政。硬件做了 FMEDA，软件做了单元测试，但没人去验证「硬件故障时软件能不能正确响应」。结果呢？集成测试时发现一堆接口问题。这就是典型的「V 模型断裂」。

我的建议：在 V 模型的每个阶段，都明确一个「安全交付物」。比如系统设计阶段，必须输出「安全机制设计文档」。没有这个文档，不准进入下一阶段。

很多工程师问我：「做功能安全，到底要写多少文档？」

我的回答是：文档不是目的，证据才是。ISO 26262 要求的是「工作产品」（work product），说白了就是能证明你做了安全活动的证据。

下面这张表，是我自己整理的核心安全活动与对应的工作产品：

你可能会问：「这么多文档，怎么管理？」

嗯，这里有个坑。我曾经见过一个项目，文档倒是写了一大堆，但内容互相矛盾。HARA 里说某个故障是 ASIL C，到了 TSC 里却变成了 ASIL B。审核时直接被开了严重不符合项。

避坑指南：我曾经犯过一个错误——把安全活动当成「一次性任务」。做完 HARA 就扔一边了。后来产品改版，hazard 变了，但没人更新文档。结果审核时被问得哑口无言。记住：安全活动是持续的过程，不是交作业。

安全活动之间不是孤立的。我习惯用一张依赖图来理清关系：

说白了，每一步的输出都是下一步的输入。如果你跳过了某一步，后面就会像多米诺骨牌一样全倒。

我记得有一次做转向系统项目，团队觉得「FSC 太抽象了，直接写 TSC 吧」。结果 TSC 写出来，跟 safety goal 对不上。最后花了三周时间返工，重新梳理 FSC。嗯，从那以后，我再也不敢跳过任何一步了。

安全生命周期不是什么玄学。它就是一套方法论，告诉你什么时候该做什么事，做完要留下什么证据。

我个人觉得，理解安全生命周期最好的方式，就是拿一个实际项目去走一遍。哪怕是一个简单的 BMS 或 EPS 系统，走完一遍 V 模型，你就能体会到「为什么要有这些活动」。

下一章，我们会深入讲 HARA 怎么做。到时候我会分享一个真实的案例，告诉你 hazard 分析时最容易踩的坑是什么。

  一句话总结：安全生命周期不是流程负担，而是保护你和你的产品不出事的「安全带」。