RAS安全分析提出的改进措施，目前已完成多少项？——像管理风险和进度一样管理FMEA与STPA措施
01摘要（TL;DR）
02分析已获批准，谁在跟进这些措施？
分析报告获批之日，对分析团队而言是终点，但从风险的角度看却是起点。只有当分析中确定的改进措施真正落实到设计、测试和维护文件中，风险才会降低。
下图是VisualPro中变速器DFMEA示例项目的第6步（优化）。措施优先级（AP）为H或M的12个失效原因均已填写预防措施和探测措施，且措施后的AP全部预测为L。就分析本身而言，已经整理得很完善。
选中一行措施后，其下方会显示责任人、目标完成日期和状态字段。最下方还有一个“已采取的措施及证据指引”字段。
查询该示例中的12项措施，目标完成日期均已填写，但12项的责任人字段全部为空。这可能因为它是示例数据。不过，实际工作中也会出现同样的情况。分析会议上大家以“由控制团队负责”之类的共识草草带过，而这一共识始终没有落实到文件的字段中。
从措施内容中还能看出另一点。12项措施中，有些工作需要在设计团队之外处理，例如“在维护手册中明确滤清器更换周期”。此外，两个失效原因（液压阀卡滞导致的无法换挡，以及液压控制丧失）共用完全相同的措施。它们在分析表中是两行，实际上却是同一项工作。
03这些措施对PM意味着什么：风险登记册和问题进度中缺失的条目
PM维护的风险登记册和问题日志中，通常每项风险都有负责人、应对计划、状态和期限。FMEA发现的失效原因属于产品风险，而风险登记册主要处理项目风险，因此对象不同。但需要管理的信息是相同的。失效原因就是风险，预防与探测措施就是应对计划，目标完成日期就是期限。
然而，这两份清单通常各自独立。安全分析存放在分析工具中，项目进度则存放在PM的甘特图或问题跟踪工具中。因此，PM想知道“AP曾为H的措施中有多少项本月到期”，或者“集中在测试评价团队的措施是否与测试进度冲突”，都必须去问分析人员。安全措施一旦延误，最终会演变为进度风险，但这一信号到达PM界面时已经晚了。
04现有体系要求什么，又没有要求什么
管理措施的体系早已存在。我们先来承认这些体系已经提出的要求。
| 现有体系 | 要求的内容 | 未要求的内容 |
|---|---|---|
| AIAG-VDA FMEA手册 第6步（优化） | 每项措施是否记录了负责人、目标完成日期、状态、已采取的措施及证据，以及措施后的S·O·D和AP | 分析结束后由谁每周检查这些字段，以及在哪里一目了然地查看跨多个团队的措施 |
| STPA Handbook (Leveson & Thomas, 2018) | 是否已从损失场景中完整地导出要求和约束 | 导出的要求和对策在项目中由谁、在何时之前完成 |
| ISO 26262-8 第6章（安全要求的定义和管理） | 安全要求是否得到定义、追溯和验证 | 不属于软件要求的措施（维护文件、供应商确认）应在何处管理 |
| 项目风险登记册与问题日志 | 每项风险和问题是否都有负责人、应对措施、状态和期限 | 该风险源自哪个失效原因，以及应对措施能使分析中的AP降低多少 |
| ALM与问题跟踪工具（Polarion、codebeamer、Jira等） | 已登记的要求和问题的状态及可追溯性 | 从未登记的措施，以及由软件团队以外人员负责的措施 |
AIAG-VDA手册已经要求记录负责人和证据。风险登记册也已经要求负责人和期限。无需再提出新的要求。应该追问的是“这些字段是否真的已填写，是否有人每周查看？”以及“安全分析的措施和项目进度是否在同一界面上？”差距不在于要求，而在于执行。
05三条规则
规则先于工具。只要遵守以下三条，无论使用Excel还是ALM，追踪都能奏效。
可以将其视为一种机制，使AIAG-VDA第6步中已有的原则在分析文件之外同样得到遵守。这三条规则也与PM风险登记册的规则一致。
06实操演示：变速器DFMEA → Recoble
我们从VisualPro的变速器DFMEA中读取了AP为H和M的12个失效原因及其措施，并将其迁移到Recoble工作空间。分析数据通过VisualPro MCP查询，Recoble端的笔记、工作看板和链接也通过MCP创建。手动迁移得到的结构相同。
1) 失效原因转为笔记（安全工程师的依据）
每个失效原因作为笔记中的一个标题，其下用表格列出结构、功能、失效模式、S/O/D、AP以及当前的预防控制和探测控制。分析背后的依据保留在这份笔记中。
2) 措施转为工作看板条目（措施与问题清单）
一项措施对应一个条目。共用同一措施的两个失效原因（FC-01和FC-03）合并为一个条目，因此12项变为11项。自定义字段包括失效原因编号、负责团队、措施前后的AP、严重度、完成标准和验证证据（文件）。目标完成日期和进展状态（计划 → 未开始，进行中 → 进行中）直接沿用VisualPro中的值。负责团队是为本文按各措施内容分配的示例值。
负责人（个人）列被特意留空，因为原始数据中没有责任人。关键在于，这一空列在看板上一眼可见。在每周例会上，只需一个界面就能确认“11项措施没有负责人”。
3) 用链接连接失效原因与措施，用追溯表找出空缺
我们创建了名为“对策 / 对应失效原因”的链接类型，将笔记中的失效原因标题与工作看板条目相链接。Recoble追溯界面的表格视图会按顺序排列文档，并为每个链接展开一行。
12项全部显示为“已链接”，还可以看到FC-01和FC-03指向同一项措施。最后一行的“缺失 1”并不是失效原因，而是代表整篇笔记文档的行。打开顶部的缺失链接筛选器，就只剩下没有处置结果的失效原因，因此这就是会前检查规则1的界面。
4) 用甘特图呈现相同条目（PM的进度视图）
PM需要一个以进度形式查看相同措施的视图。在工作看板中添加甘特视图后，11项措施会以延伸至目标完成日期的条形展开。这不是另一份进度计划，而是以不同视图呈现的同一份数据，因此分析端修改期限时，PM的界面也会随之变化。
在本例中，11月30日（更改箍紧弹簧槽形状）是最早的期限，期限集中在12月中旬至2027年1月中旬之间。如果在条目之间设置依赖关系，还可以在进度上看到哪些条目（例如测试时段）阻碍了其他措施。
5) 每周通过仪表板复查（PM与质量经理的每周检查）
措施总数、完成率、逾期数和已完成数，以及按状态、负责团队和AP变化的分布，都集中在一个仪表板上。截至今天，11项全部未完成，尚无逾期。按负责团队划分，机械设计团队5项，控制软件团队4项，液压设计团队2项。
需要在会议上做出决定的条目（例如决定不采取措施）记录在会议笔记中，并链接到相应条目。日后，“当初为什么这样决定？”可以直接从条目中找到答案。
07如果已在使用ALM或问题跟踪工具
软件安全要求的权威数据源应放在ALM中，并应避免重复管理。此时，工作看板只承担两项职责。一是作为一个场所，按照相同规则管理维护文件、供应商确认等不太适合放入ALM的措施。二是作为一个工作空间，按失效原因记录每项措施在ALM中以哪个ID登记。没有ALM的小型团队或研究项目，仅靠工作看板即可运行全部流程。
08明天要检查的事项
分析负责人（安全工程师）
- 在上一次分析中，AP为H和M的失效原因（或损失场景）中，有多少项没有处置结果？
- 决定不采取措施的条目，是否记录了理由和决策人？
- 每项措施是否都写明了完成标准，即具备什么才算完成？
项目经理与质量经理
- 有多少项措施的责任人字段为空？
- 安全分析的措施是否已纳入项目风险登记册或进度计划？
- 本月到期的AP为H的措施有多少项，是否与负责团队的其他日程冲突？
- 设计团队以外（维护、供应商、测试）措施的负责人是否知道自己的条目？
09结语
安全分析的产出不是一份报告，而是一份需要完成的改进措施清单；从项目的角度看，则是一份带有进度的风险清单。为每个失效原因附上处置结果，为每项措施附上负责人、期限和证据，分析就不会在获批之日结束，而是在最后一项措施关闭之日结束。请打开上一次的分析，先数一数有多少项措施的责任人字段为空。
10常见问题（FAQ）
· AIAG & VDA, FMEA Handbook, 1st Edition, 2019.
· Nancy G. Leveson, John P. Thomas, STPA Handbook, MIT Partnership for Systems Approaches to Safety and Security, 2018. — STPA Handbook（PDF）— MIT PSASS
· ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes.
· Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide).
VisualPro FMEA | VisualPro STPA | 免费开始使用Recoble | VisualPro Lite