3、功能安全管理：整体安全管理、项目级别的安全活动、安全计划的制定与执行

聊到功能安全，很多人第一反应是技术细节——什么诊断覆盖率、硬件随机失效、软件架构分层。但我做了十几年嵌入式安全，想跟你说句实话：技术问题往往不是项目失败的主因，管理问题才是。

你想想看，一个项目里，安全经理不懂怎么分配任务，安全计划写得像天书，评审会开成了甩锅大会……那再好的技术方案也白搭。所以今天这一章，咱们就聊聊功能安全的管理层面。

3.1 整体安全管理：公司的安全文化

整体安全管理，说白了就是公司层面的安全治理。它不针对某个具体项目，而是建立一套长效机制。

我个人习惯把这一层叫做「安全基础设施」。它包括：

• 安全方针：公司高层对功能安全的承诺。不能只是墙上贴个标语，得有资源投入。
• 安全组织：谁负责安全？安全经理、安全工程师、评审员，角色要清晰。
• 能力管理：工程师有没有接受过ISO 26262培训？我记得有一次去客户现场，发现他们的安全经理连ASIL等级都分不清……这项目能做好才怪。
• 持续改进：从项目里学到的教训，要反馈到流程里。

3.2 项目级别的安全活动

项目级别的安全活动，才是我们每天要面对的东西。它贯穿整个V模型开发流程。

我把它拆成几个关键节点：

3.2.1 安全生命周期定义

每个项目都要定义自己的安全生命周期。ISO 26262给了你一个模板，但你不能照搬。为什么？因为不同项目的复杂度、ASIL等级、开发模式都不一样。

举个例子：

• 一个ASIL D的线控转向系统，安全生命周期可能长达3年，包含完整的硬件和软件验证。
• 一个ASIL A的雨量传感器，可能只需要做基本的故障注入测试。

嗯，这里要注意：安全生命周期不是越复杂越好，而是越合适越好。过度工程化也是浪费。

3.2.2 危害分析与风险评估（HARA）

HARA是项目安全活动的起点。没有HARA，后面的所有工作都是盲人摸象。

我曾经在一个项目里，HARA做得太粗糙，漏掉了一个关键危害——电机在堵转时可能过热起火。结果到了系统集成测试阶段才发现，整个安全机制要重做……那叫一个惨。

3.2.3 安全状态定义

每个危害都要对应一个安全状态。比如：

• 电机过温 → 安全状态：切断电机供电
• 通信丢失 → 安全状态：进入降级模式，保持最后有效输出

这里有个坑：安全状态本身也要是安全的。你不能说「切断供电就完事了」，万一切断供电导致车辆失去转向助力，那更危险。

3.3 安全计划的制定与执行

安全计划，是整个项目安全活动的「作战地图」。没有它，团队就像无头苍蝇。

3.3.1 安全计划应该包含什么？

ISO 26262-2 里列了一堆要求，我帮你提炼成几个核心要素：

要素	说明	我的经验
安全活动清单	列出所有要做的安全活动（HARA、评审、测试等）	别漏了「安全评审」和「安全确认」这两项
时间节点	每个活动的开始和结束时间	要留缓冲，评审经常延期
责任人	谁负责做什么	一个人不能同时负责设计和评审
交付物	每个活动要产出什么文档	安全案例、安全计划本身、评审报告
评审机制	什么时候评审、谁来评审	我建议每个里程碑都做一次评审

3.3.2 安全计划的执行

制定计划不难，难的是执行。我见过太多项目，安全计划写得漂漂亮亮，结果一执行就变形。

为什么会这样？

• 计划太理想化：每个活动都排得满满当当，没有考虑意外情况。
• 缺乏跟踪：计划做完了就扔一边，没人跟进进度。
• 责任不清：出了问题，谁该负责？没人知道。

3.3.3 安全计划的动态调整

安全计划不是一成不变的。项目进行中，你会发现新的风险、新的问题，这时候计划要跟着调整。

比如：

• HARA阶段发现了一个新的危害，需要增加额外的安全机制。
• 测试阶段发现某个安全机制失效了，需要重新设计。

调整计划时，要记录变更原因，并且重新评审。不能偷偷摸摸改，否则审计的时候会出大问题。

3.4 我的个人经验总结

做了这么多年功能安全，我最大的体会是：管理比技术更难。技术问题有标准答案，管理问题没有。

给你几个小建议：

• 安全计划要「活」：别把它当成一次性的文档，要定期回顾和更新。
• 沟通要频繁：安全经理要定期和项目经理、系统工程师、测试工程师沟通，别等出了问题再找。
• 文档要简洁：安全文档不是写小说，能一句话说清楚就别写三段。我见过有人把安全计划写了200页，结果没人看。

嗯，这一章就聊到这里。下一章咱们会深入讲「安全需求管理」，那是从管理到技术的桥梁，很有意思。