第四章：文档体系总览——ISO26262要求的文档清单、文档生命周期、文档间的追溯关系
好，咱们进入第四章。这一章我打算聊聊文档体系的总览。说实话，很多工程师一听到“文档”两个字就头疼，觉得是形式主义。但我做了这么多年功能安全，可以负责任地告诉你：文档不是负担，而是你的护身符。
ISO26262对文档的要求，说白了就三件事：该有的得有、该管的得管、该连的得连。咱们一个一个说。
4.1 文档清单：到底要写哪些文档？
标准里其实没有一张“必须写的文档列表”。它只告诉你：每个阶段，你得产出什么证据。我个人习惯把文档分成三大类：
- 计划类：项目计划、安全计划、验证计划、确认计划。这些是“承诺”，告诉别人你要怎么做。
- 技术类：危害分析与风险评估（HARA）、功能安全概念（FSC）、技术安全概念（TSC）、软硬件设计文档。这些是“干货”，记录你的设计决策。
- 证据类：测试报告、评审记录、分析报告（如FMEA、FTA）。这些是“证明”，告诉别人你真的做了。
我在项目中遇到过最典型的问题：项目快结束了，发现安全计划还没签批。嗯，这其实很要命。因为安全计划是整个文档体系的“宪法”，它定义了文档的模板、评审流程、变更管理。没有它，后面的文档就像没头苍蝇。
核心原则：每个安全活动，都必须有对应的文档输出。别想着“先干再说”，标准不认这个。
4.2 文档生命周期：文档不是写一次就完事
很多人以为文档是“写出来、存档、再也不看”。错了。文档是有生命周期的，它跟项目一样，会经历创建、评审、批准、发布、变更、归档这几个阶段。
我建议你记住一个模型：V模型左侧的文档，会随着右侧的验证活动不断更新。举个例子：
- 你一开始写的技术安全概念（TSC），可能只是草稿。
- 等到硬件设计完成，你发现有些安全机制实现不了，得改TSC。
- 改完之后，得重新评审、重新批准。
- 最后项目结束，所有文档进入归档状态，不能再改。
为什么会这样？因为功能安全是迭代的。你不可能一开始就把所有细节都想清楚。我曾经在一个项目中，TSC改了7版——不是因为设计差，而是因为客户需求变了。嗯，这很正常。
我的小技巧：给每个文档加一个“版本状态”字段。比如“草稿”、“评审中”、“已批准”、“已发布”、“已废弃”。这样一眼就能看出文档当前处于什么阶段。
4.3 文档间的追溯关系：把散落的珍珠串起来
这是ISO26262文档体系里最容易被忽视、也最容易出问题的地方。标准要求：从需求到设计、从设计到实现、从实现到测试，必须双向可追溯。
说白了，就是你要能回答三个问题：
- 这个安全需求，对应哪个设计元素？（正向追溯）
- 这个测试用例，验证了哪个安全需求？（反向追溯）
- 如果某个安全机制被删了，会影响哪些文档？（影响分析）
我见过最惨的案例：项目做完了，审核员问“这个安全机制对应的测试报告在哪？”工程师翻了半天，找不到。最后发现测试做了，但文档里没写关联关系。嗯，这属于典型的“做了但没证据”，审核直接给了一个严重不符合项。
所以，我建议你在项目一开始就建立追溯矩阵。可以用Excel，也可以用专门的工具（比如DOORS、Polarion）。关键是要把以下关系理清楚：
| 源文档 | 目标文档 | 追溯关系 |
|---|---|---|
| HARA | 功能安全概念（FSC） | 每个危害事件 → 对应的安全目标 |
| FSC | 技术安全概念（TSC） | 每个安全目标 → 对应的技术安全需求 |
| TSC | 硬件/软件设计 | 每个技术安全需求 → 对应的设计元素 |
| 设计 | 测试用例 | 每个设计元素 → 对应的测试用例 |
避坑指南：我曾经在一个项目中，因为追溯矩阵没及时更新，导致一个安全需求被遗漏了。最后在集成测试阶段才发现，返工成本极高。所以，追溯矩阵要跟文档同步更新，别等到最后再补。
4.4 文档间的依赖关系：谁先谁后？
文档不是独立存在的。它们之间有明确的依赖关系。我画个简单的依赖链给你看：
项目计划 → 安全计划 → HARA → FSC → TSC → 硬件/软件设计 → 测试报告 → 安全案例这个链条的意思是：前面的文档没完成，后面的文档就别急着写。比如，你还没做HARA，就急着写FSC，那FSC里的安全目标从哪来？拍脑袋吗？
当然，实际项目中可以有一些并行。比如硬件设计和软件设计可以同时进行，但前提是TSC已经定下来了。我建议你做一个文档依赖图，贴在项目办公室的墙上。谁先谁后，一目了然。
4.5 文档评审与批准：别让文档变成“写了没人看”
文档写出来，不是用来存档案的。它需要被评审、被批准。ISO26262要求：每个文档都必须经过独立评审。独立的意思是：评审人不能是文档的作者，也不能是作者的直接领导。
我个人的习惯是：
- 技术文档：找同级工程师评审，重点看技术正确性。
- 计划类文档：找项目经理和功能安全经理评审，重点看可行性和完整性。
- 测试报告：找测试经理和系统工程师评审，重点看覆盖率和结论。
评审完之后，一定要有评审记录。记录里要写清楚：谁评审的、评审了什么、发现了什么问题、问题怎么解决的。我曾经见过一个项目，评审记录里只写了“通过”，没有任何细节。审核员一看就问：“你们真的评审了吗？”
记住：没有评审记录的文档，等于没评审。没有批准签字的文档，等于没发布。
4.6 文档的变更管理：改文档比写文档更需要规范
项目进行中，文档变更是家常便饭。但变更不能随意。ISO26262要求：任何文档变更，都必须走变更管理流程。流程包括：
- 提出变更申请（谁想改、改什么、为什么改）
- 评估变更影响（会影响哪些其他文档？会影响安全目标吗？）
- 审批变更（功能安全经理签字）
- 执行变更（修改文档）
- 重新评审和批准（变更后的文档要重新走评审流程）
- 通知相关人员（让所有受影响的人知道文档变了）
我遇到过最头疼的事：一个工程师偷偷改了设计文档，没通知任何人。结果测试团队拿着旧版本做测试，测了半天发现对不上。最后查出来是文档版本不一致。嗯，从那以后，我要求所有文档必须上版本管理工具，改完必须发邮件通知。
4.7 文档的归档与保存：项目结束了，文档不能丢
项目交付后，所有安全文档必须归档保存。ISO26262要求：保存期限至少覆盖产品的整个生命周期。对于汽车来说，一般是10到15年。
归档时要注意：
- 版本完整性：所有历史版本都要保留，不能只留最终版。
- 可读性：文档格式要通用，别用那种十年后打不开的专有格式。我建议用PDF/A。
- 访问权限：归档后的文档只能读，不能改。如果有人想改，必须走正式的“文档恢复”流程。
我的经验：归档时最好做一个“文档清单总表”，列清楚每个文档的编号、名称、版本、归档日期、保存位置。这样以后找起来方便。别问我为什么知道——我曾经花了两天时间找一个三年前的安全案例。
4.8 小结：文档体系的核心就三句话
好了，这一章的内容差不多就这些。我帮你总结一下：
- 文档清单：计划类、技术类、证据类，一个都不能少。
- 文档生命周期：创建→评审→批准→发布→变更→归档，每一步都要有记录。
- 文档追溯：从需求到测试，双向可追溯，别让文档变成孤岛。
下一章，我会带你深入看看安全计划这个文档——它是整个文档体系的“总指挥”。咱们到时候细聊。