2. 功能安全生命周期：概念阶段、产品开发阶段、生产发布阶段、安全生命周期模型详解
功能安全不是写写文档就完事。它是一个贯穿产品从想法到报废的全过程。我习惯把这个过程叫做「安全生命周期」。说白了，就是给安全一个完整的「出生证明」和「成长记录」。
ISO 26262 把安全生命周期分成三个阶段：概念阶段、产品开发阶段、生产发布阶段。每个阶段都有明确的目标和产出。你跳过任何一步，后面都会踩坑。
核心观点：安全生命周期不是瀑布模型，而是迭代的。每个阶段都可能因为新发现的问题而回溯到前面的阶段。别想着一步到位。
2.1 安全生命周期模型总览
先看一张整体框架图。我每次做新项目，都会先把这张图贴在白板上。它帮你理清思路，知道现在走到哪一步了。
这张图我用了很多年。每次给团队培训，我都会指着它说：「安全不是测试出来的，是设计出来的，更是管理出来的。」
2.2 概念阶段：打好地基
概念阶段是安全生命周期的起点。很多人觉得这步就是写写文档，没什么技术含量。我告诉你，大错特错。概念阶段做不好，后面全是补丁。
2.2.1 项目定义
项目定义要回答三个问题：
- 这个产品是什么？——功能边界、系统架构、使用场景。
- 用在什么车上？——乘用车、商用车、还是特种车辆？
- 安全目标是什么？——初步的 ASIL 等级预估。
我记得有一次，客户说「我们做个简单的 BMS 监控模块」。结果一聊，发现它要同时监控 400V 高压和 12V 低压，还要支持 OTA 升级。项目定义不清晰，后面 HARA 根本没法做。
2.2.2 危害分析与风险评估（HARA）
HARA 是概念阶段的核心。它的目标是找出所有可能的危害，并给每个危害定一个 ASIL 等级。
HARA 的三要素：
| 要素 | 含义 | 我的经验 |
|---|---|---|
| Severity (S) | 危害的严重程度 | S3 级别的危害，必须重点对待 |
| Exposure (E) | 暴露在危害场景中的概率 | E4 的场景，即使严重度低也要关注 |
| Controllability (C) | 驾驶员或其他人控制危害的能力 | C3 意味着基本失控，必须靠系统自身 |
ASIL 等级由 S、E、C 组合决定：
- ASIL A：最低安全等级
- ASIL B：中等
- ASIL C：较高
- ASIL D：最高安全等级
- QM：质量管理即可，无需功能安全措施
避坑指南：我曾经在一个项目中，把某个危害的 Exposure 估低了。结果到了测试阶段，发现这个场景在实际路试中频繁出现。没办法，只能回头重新做 HARA，整个项目延期两个月。所以，HARA 一定要找有经验的工程师和功能安全专家一起评审。
2.2.3 功能安全概念
有了 HARA 的结果，接下来要定义功能安全概念。说白了，就是针对每个安全目标，设计出对应的安全机制。
举个例子：
- 安全目标：防止电池过充导致起火（ASIL C）
- 功能安全概念：当检测到电池电压超过 4.25V 时，在 100ms 内切断充电回路，并上报故障码。
功能安全概念要写清楚：
- 触发条件是什么？
- 安全动作是什么？
- 响应时间是多少？
- 故障容错时间是多少？
- 降级模式怎么处理？
2.3 产品开发阶段：把安全做进代码里
产品开发阶段是工作量最大的阶段。它又分为系统级、硬件级、软件级三个层级。我主要讲软件部分，因为这是咱们嵌入式工程师的主战场。
2.3.1 系统级设计
系统级设计要做两件事：
- 技术安全概念：把功能安全概念细化成具体的技术实现方案。比如，用双核锁步还是软件自检？用看门狗还是 ECC？
- 系统架构设计：定义模块划分、接口协议、冗余策略。
我习惯在系统级设计阶段就画出安全架构图。哪个模块负责监控，哪个模块负责执行，哪个模块负责诊断，一目了然。
2.3.2 硬件与软件开发
硬件和软件开发是并行的。这里我只说软件。
软件开发要遵循 V 模型：
| 左侧（设计） | 右侧（验证） |
|---|---|
| 软件安全需求 | 软件安全测试 |
| 软件架构设计 | 软件集成测试 |
| 软件单元设计 | 软件单元测试 |
| 编码实现 | 代码评审/静态分析 |
你想想看，V 模型的核心是什么？是「早验证、早发现」。左侧每做一步，右侧就要有对应的验证活动。别等到代码写完了再测试，那时候改 bug 的成本高得吓人。
注意：ASIL 等级越高，对开发流程的要求越严格。ASIL D 要求使用形式化方法或半形式化方法进行验证。ASIL A 可能只需要代码评审就够了。别一刀切，也别偷懒。
2.3.3 安全验证与确认
验证和确认是两个概念：
- 验证：我们做对了吗？（符合需求）
- 确认：我们做的是对的吗？（符合安全目标）
举个例子：
- 验证：看门狗定时器在 100ms 内正确复位了 MCU。✅
- 确认：看门狗定时器确实能防止系统死锁导致的安全事故。✅
两者缺一不可。我见过不少团队只做验证不做确认，结果产品功能都对，但安全目标没达到。白忙一场。
2.4 生产发布阶段：安全不能止于研发
很多人觉得产品开发完了，功能安全就结束了。错。生产发布阶段同样重要。
2.4.1 生产计划
生产计划要定义：
- 生产过程中的安全相关特性如何保证？
- 生产设备的校准和维护周期。
- 生产人员的培训要求。
我曾经遇到一个案例：某款 ECU 在研发阶段通过了所有安全测试，但量产时发现焊接工艺不稳定，导致看门狗芯片虚焊。结果 10% 的产品在客户车上出现随机复位。这就是生产阶段没管好。
2.4.2 生产启动
生产启动阶段要做：
- 首批产品的安全功能 100% 测试。
- 生产流程的审核与批准。
- 生产数据的追溯性建立。
2.4.3 运行与维护
产品上路后，安全生命周期还没结束。你需要：
- 收集现场故障数据。
- 分析安全相关的失效模式。
- 必要时发起安全召回或 OTA 升级。
ISO 26262 要求建立「现场监控机制」。说白了，就是产品卖出去后，你还要盯着它。出了安全问题，要能追溯到哪个批次、哪个零件、哪个软件版本。
2.5 安全生命周期模型的核心要点
最后，我总结几个关键点：
- 迭代性：安全生命周期不是线性的。每个阶段都可能回溯到前面的阶段。别怕改，怕的是不改。
- 可追溯性：每个安全需求都要能追溯到安全目标，每个测试用例都要能追溯到安全需求。没有追溯，就没有安全。
- 独立性：安全评审、安全测试要由独立于开发团队的人来做。自己查自己，查不出问题。
- 文档化：所有安全活动都要有文档记录。不是给审核员看的，是给自己留底的。万一出事，文档能救命。
一句话总结：安全生命周期不是流程负担，而是保护你和你的产品不出事的「安全带」。系好它，再上路。