第三章：功能安全管理
大家好，我是老张。今天咱们聊聊功能安全管理。说实话，很多工程师一听到「管理」两个字就头疼，觉得这是项目经理的事。但我做了十几年功能安全，可以负责任地告诉你：不懂管理，你的安全设计就是空中楼阁。
3.1 功能安全管理的基本概念
功能安全管理，说白了就是一套「怎么干活」的规矩。它回答三个问题：谁来做？什么时候做？做成什么样？
我见过不少团队，技术方案做得漂漂亮亮，但最后审核过不了。为什么？因为过程文件一塌糊涂。你想想看，审核员怎么知道你确实按照流程做了？他只能看你的文档。
核心要点：功能安全管理 = 技术 + 流程 + 证据。缺一不可。
这里有几个关键角色，我列个表大家看得清楚些：
| 角色 | 职责 | 我的一点经验 |
|---|---|---|
| 功能安全经理 | 统筹整个安全活动 | 这个人最好懂技术，不然容易被工程师忽悠 |
| 安全工程师 | 执行具体的安全分析、设计 | 建议轮岗，别让一个人从头做到尾 |
| 独立评审员 | 审核安全活动的有效性 | 一定要独立！我吃过亏，后面讲 |
3.2 安全生命周期模型
安全生命周期，就是产品从生到死的安全活动路线图。ISO 26262 把它分成了几个阶段。嗯，这里要注意，不是所有项目都要走完所有阶段——你得根据项目的实际情况裁剪。
我个人习惯把生命周期分成三大块：
- 概念阶段：想清楚要做什么，有什么风险
- 开发阶段：把安全要求落实到产品里
- 生产运维阶段：确保批量生产不出问题
为什么会这样分？因为每个阶段的「管理重点」完全不同。概念阶段最怕需求漏了，开发阶段最怕设计错了，生产阶段最怕工艺变了。
我的小技巧：在每个阶段结束时，做一个「阶段退出检查表」。别嫌麻烦，这能帮你省掉后面返工的大麻烦。
3.3 安全计划
安全计划，就是你的「作战地图」。它要写清楚：
- 安全目标是什么（ASIL等级）
- 用什么方法做（FMEA？FTA？）
- 谁负责什么（责任矩阵）
- 什么时候交付（里程碑）
我曾经在一个项目里，安全计划写得特别详细，连每周的评审会都排好了。结果呢？项目经理说「计划赶不上变化」，硬是把评审会取消了。后来出了个低级错误，返工花了三周。
警告：安全计划不是写给审核员看的。它是你团队的行动指南。如果计划定了却不执行，还不如不定。
这里给个安全计划的模板框架，你们可以参考：
1. 项目概述
- 产品描述
- 安全目标
2. 安全活动计划
- 分析方法（FMEA/FTA/STPA）
- 验证方法（评审/测试/仿真）
3. 资源与职责
- 团队组织架构
- 培训计划
4. 时间表
- 里程碑节点
- 交付物清单
5. 裁剪说明
- 为什么裁剪
- 裁剪后的影响分析
3.4 安全案例
安全案例，就是你的「辩护词」。它要证明：我的产品是安全的。
你想想看，如果有一天出了事故，你怎么跟法官说？「我们按流程做了」——这不够。你得拿出证据：安全分析报告、测试报告、评审记录、变更记录……
安全案例的写法，我建议用GSN（目标结构符号）来画。它能把「安全目标」和「证据」之间的关系理得清清楚楚。嗯，这个有点抽象，我举个例子：
- 目标：系统在单点故障时不会失控
- 策略：通过FMEA识别所有单点故障
- 证据：FMEA报告、故障注入测试报告
- 假设：故障检测时间小于10ms
记住：安全案例不是写完了就完事了。产品改了，安全案例也得跟着改。我见过最惨的案例——产品迭代了三版，安全案例还是第一版的，审核直接被拒。
3.5 安全档案
安全档案，就是所有安全相关文档的「大本营」。它包含：
- 安全计划
- 安全分析报告（HARA、FMEA、FTA等）
- 安全需求规范
- 验证与确认报告
- 变更管理记录
- 评审记录
这里我要特别强调一下文档的版本管理。我曾经在一个项目里，两个工程师同时改了同一个安全需求，一个改了没通知，另一个改了也没通知。结果呢？测试的时候发现对不上，查了三天才找到原因。
建议：用工具管理安全档案。别用共享文件夹+文件名版本号的方式，迟早会出乱子。至少用个SVN或者Git，配上权限管理。
安全档案的存放，我建议按这个结构来：
项目名/
├── 01_安全计划/
├── 02_安全分析/
│ ├── HARA/
│ ├── FMEA/
│ └── FTA/
├── 03_安全需求/
├── 04_验证确认/
│ ├── 评审记录/
│ ├── 测试报告/
│ └── 仿真结果/
└── 05_变更管理/
最后说一句：安全档案不是给审核员看的，是给你自己看的。产品出了事，第一个翻档案的就是你。所以，别偷懒，该写的写，该签的字签。
好了，这一章就到这里。下一章咱们聊聊危害分析与风险评估（HARA），这可是功能安全的「第一道防线」。到时候见。