3. 安全计划制定：安全计划的目的与内容、安全计划模板、安全计划的评审与更新
好，咱们进入第三个话题——安全计划。说实话，这是整个功能安全管理的“地基”。你想想看，没有一份靠谱的安全计划，后面所有的安全活动都会乱套。我见过不少项目，一开始觉得“先干再说，计划后面补”，结果到了项目后期，安全档案缺胳膊少腿，评审的时候被审计师问得哑口无言。嗯，那滋味可不好受。
3.1 安全计划的目的与内容
安全计划到底用来干嘛？说白了，它就是一份“作战地图”。它告诉你：
- 我们要做什么安全活动？（比如HARA、安全分析、验证测试）
- 谁来做？（安全经理、系统工程师、硬件/软件工程师）
- 什么时候做？（对应V模型的哪个阶段）
- 产出什么？（安全档案、安全案例）
我个人习惯，在项目启动的第一周就把安全计划的初稿拉出来。哪怕后面要改，也比没有强。为什么？因为安全计划是ISO 26262第2部分明确要求的产出物（参考条款6.4.2）。没有它，你连第一轮评审都过不去。
安全计划的核心内容，我归纳为以下几个模块：
| 模块 | 包含内容 | 我的经验 |
|---|---|---|
| 项目范围与安全目标 | 系统描述、ASIL等级、安全目标 | 这里最容易犯的错是ASIL定得太高或太低。我建议早期就做一轮预HARA |
| 角色与职责 | 安全经理、安全工程师、评审员 | 一定要明确“谁对安全档案签字负责”，否则后面扯皮 |
| 安全活动时间表 | 每个阶段的交付物与里程碑 | 我习惯用甘特图，但至少要有Excel表格 |
| 安全档案结构 | 文档清单、模板、版本控制策略 | 文档命名规则要统一，不然审计时找文件找到崩溃 |
| 评审与确认措施 | 评审计划、独立评审员安排 | ASIL C/D的项目，独立评审员必须提前约好档期 |
| 偏差与变更管理 | 安全计划变更流程、偏差处理 | 我曾经遇到一个项目，安全计划改了5版都没通知团队，结果大家按旧计划干活，全白做了 |
重点提醒：安全计划不是写一次就完事的。它应该是一个“活文档”。项目每进入一个新阶段，你都要回头看一眼，看看计划是否还适用。
3.2 安全计划模板
好，接下来聊聊模板。很多公司都有自己内部的安全计划模板，但如果你是从零开始，我建议你参考ISO 26262-2附录B中的建议结构。我自己也整理了一个常用模板，分享给你参考：
# 安全计划模板（精简版）
## 1. 项目概述
- 项目名称：XXX
- 系统描述：XXX
- 最高ASIL等级：ASIL X
## 2. 安全目标与假设
- 安全目标列表（引用HARA结果）
- 运行场景与边界条件
## 3. 组织与职责
- 安全经理：[姓名]
- 安全工程师：[姓名]
- 独立评审员：[姓名/外部机构]
## 4. 安全活动计划
| 阶段 | 活动 | 交付物 | 责任人 | 截止日期 |
|------|------|--------|--------|----------|
| 概念阶段 | HARA | 安全目标 | 系统工程师 | 第4周 |
| 系统阶段 | 安全分析 | FTA/DFA | 安全工程师 | 第8周 |
| 硬件阶段 | 硬件安全需求 | 硬件安全档案 | 硬件工程师 | 第12周 |
| 软件阶段 | 软件安全需求 | 软件安全档案 | 软件工程师 | 第16周 |
| 测试阶段 | 安全验证 | 测试报告 | 测试工程师 | 第20周 |
## 5. 安全档案清单
- 文档编号规则：PROJ-SAF-XXX-YYY
- 文档存储路径：\\server\safety\project_xxx
## 6. 评审与确认计划
- 评审节点：P1（概念评审）、P2（系统评审）、P3（最终评审）
- 确认措施：功能安全审计、安全案例评审
## 7. 变更管理
- 安全计划变更需经安全经理审批
- 重大变更需通知独立评审员
嗯，这个模板看起来简单，但够用了。我建议你根据自己项目的复杂度去裁剪。比如，如果项目只涉及ASIL B，那独立评审员的安排可以灵活一些；如果是ASIL D，那每一步都要严格按计划走。
小技巧：模板里的日期不要写死。我习惯用“相对日期”，比如“T0+4周”。这样项目延期时，你只需要调整T0，不用改所有日期。
3.3 安全计划的评审与更新
安全计划写完了，不是扔到共享文件夹里就完事了。你得评审它，还得定期更新它。
评审怎么做？
- 内部评审：安全经理组织，系统、硬件、软件工程师参加。主要看计划是否可行，时间是否合理。
- 独立评审：对于ASIL C/D项目，ISO 26262要求有独立评审员参与。独立评审员会重点检查安全活动是否覆盖了所有安全目标。
- 客户评审：有些OEM会要求看你的安全计划。我遇到过客户直接说“你这个时间表太乐观了，加两周缓冲”。听客户的，没错。
什么时候需要更新？
我总结了几个典型场景：
- 项目范围变了：比如新增了一个功能，或者删除了一个功能。安全目标可能跟着变。
- ASIL等级调整：HARA做完后，发现某个功能的ASIL需要升级或降级。这时候安全活动的工作量会变。
- 人员变动：安全经理换人了，或者独立评审员离职了。职责必须重新明确。
- 进度严重偏离：项目延期超过2周，我建议你重新审视安全计划的时间表。
避坑指南：我曾经犯过一个错——项目中期发现安全计划需要更新，但我只在邮件里口头通知了团队，没有正式走变更流程。结果审计时，审计师指着旧计划问：“你们为什么没按计划做安全分析？”我解释了半天，最后还是被开了不符合项。所以，安全计划的每一次更新，都要有版本号、变更记录和审批签字。
最后，我想说一句：安全计划不是用来应付审计的，它是你项目安全工作的“导航仪”。你花一周时间把计划做扎实，后面能省下一个月返工的功夫。这个账，你算算看。