2.17 支撑过程与安全档案——如果没有写下来，就没有发生过

场景：评估员的笔放下了

2025年6月，慕尼黑。TÜV南德的一位资深功能安全评估员走进你们的评审会议室。他在这里做了16年的ISO 26262评估，见过125个项目的安全档案：其中31个在第一次评审中被拒绝。你提前48小时把安全档案的电子包发给了他。今天，他要把你的ASIL D转向系统放在显微镜下审视。

他没有打开你的代码仓库。没有看你的Simulink模型。没有跑你的硬件测试台。

他打开了一个Excel文件。你的Safety Case矩阵。

然后指向第174行：“HARA #17: 转向助力在驾驶员请求转向扭矩时意外丧失（ASIL D）。请出示这个危害事件到TSR-042的验证报告的审计链。”

你的安全工程师翻了5分钟。FSR-031 → TSR-042的追溯关系在V模型左边的追溯矩阵里有。TSR-042的软件单元测试报告……在Confluence的某个页面上，但链接已经失效了。硬件SPFM的计算报告在另一个共享目录里，但文件名没有包含TSR编号，只能通过创建日期推测。

评估员的笔放了下来。“先生们，“他说，“我看到了很多证据。但我没有看到一条完整的链。如果追溯性在评审时不可验证，那我就无法确认它在开发时是否被真正执行过。”

评审中止。这不是技术失败。这是过程透明度的失败。

在功能安全领域，没有记录等于没有发生。

ISO 26262-8（支撑过程）和Part 2的6.4.8节（安全档案要求）联合定义了这条铁律。它不在V模型的任何一层。它在V模型的背后，贯穿所有层，确保上一层“说了要做“的事在下一层“真的做了“，并且这个“做了“的事实可以被任何第三方的审计者在任何时候独立验证。

配置管理：所有安全物的第一根锚链

如果你的设计团队有12个软件工程师、8个硬件工程师、6个系统工程师，他们同时工作在HARA、功能安全概念、技术安全概念、软件架构和硬件架构上。你怎么确保每个人用的都是同一个版本的假设？

你怎么确保软件团队在开发TSR-042的MC/DC测试用例时，基于的是三天前更新的ASIL筛选规则，而不是上周的那个版本？

你怎么确保硬件团队在计算SPFM时，引用的失效率数据库是JEDEC的JESD89E而不是已经过期的JESD89C？

答案是配置管理（Configuration Management, CM）。ISO 26262-8第5章对此提出了系统的要求。

配置管理的核心是三个概念：基线（Baseline）、变更控制（Change Control）、可追溯性（Traceability）。

基线是“在特定时刻被冻结的工作产品集合“。你必须在项目的关键节点建立基线：安全计划评审完成后、HARA获批后、安全概念获批后、技术安全概念获批后、硬件详细设计完成后、软件单元测试完成后、整车验证完成后。每一个基线都记录：在这个时刻，哪些工作产品（文档、模型、代码、测试用例、测试报告）以什么版本共同构成了安全论证的一个“切片“。

为什么要建立基线？设想如果没有基线：当你在2024年11月提交了HARA的最终版本，但在12月又对其中一个危害事件的ASIL等级做了微调：而功能安全概念（FSC）团队在11月底已经基于“旧HARA“完成了全部工作。这个差异如果不被发现，可能导致一个ASIL C的安全目标被按ASIL A的要求实现：整个安全概念向下偏离了两个等级。基线就是你的“同步点“：它不仅记录版本，更在流程上强制要求“在基线B释放之前，所有依赖它的下游活动必须基于B执行，不得使用B之前或之后的任何非基线版本“。

变更控制是实现基线一致性的机制。ISO 26262-8要求：对任何已被基线的安全相关元素的变更，必须执行影响分析（Impact Analysis）。影响分析不是简单的“改了一行代码，影响对应的单元测试“。它沿着依赖链向上追溯：

• 如果扭矩传感器的采样率从1kHz改为800Hz，影响分析必须评估：
  • 对TSR的影响：FTTI为200ms，1kHz采样率对应的最大检测延迟为1ms，改为800Hz则变为1.25ms：仍在FTTI内吗？检查你的时序预算表。
  • 对软件架构的影响：ADC DMA的中断频率从1kHz变为800Hz，对调度表的影响是什么？是否有任务会因为中断频率降低而错过截止时间？
  • 对硬件设计的影响：ADC的采样电容取值是否需要因采样频率变化而调整？
  • 对HARA的影响：采样率降低是否会影响危害暴露时间的计算，进而影响ASIL等级判定？

这就是变更影响分析的广度。它跨越V模型的所有层次。而且，变更影响分析的结果本身也必须被记录和评审。你不要低估这个“记录“的动作：一份没有记录的影响分析等于没有做。

可追溯性是配置管理的最终产出。它回答一个问题：“我能从危害事件走到对应的测试用例，再从测试用例走回危害事件吗？“ISO 26262-8第6.4.3.2条规定了安全需求之间的可追溯性要求：从安全目标到功能安全要求的追溯、从功能安全要求到技术安全要求的追溯、从技术安全要求到硬件/软件安全要求的追溯、从硬件/软件安全要求到验证测试用例的追溯。这是一个双向追溯链：追溯既要是向前的（从需求到实现），也要是向后的（从测试回到需求）。

在大型项目中，双向追溯通常由一个追溯矩阵（Traceability Matrix）来管理。对于一个ASIL D系统，这个矩阵可能包含数千行：每个HARA危害事件对应多个安全目标，每个安全目标对应多个FSR，每个FSR对应多个TSR，每个TSR对应多个软件需求（SWR）/硬件需求（HWR），每个需求对应多个测试用例。矩阵的每一行都必须有“已验证“的标志：意味着对应的测试已经执行并通过。

文档管理：安全论证的骨与肉

如果说安全论证（Safety Argument）是你们的“演讲“：向评估员、OEM、监管机构证明系统足够安全。那么支撑它的工作产品（Work Products）就是“凭证“。没有凭证的演讲是空洞的。没有组织的凭证是无用的。

ISO 26262-8第7章要求建立文档管理系统，明确定义：

1. 工作产品模板：每种类型的安全工作产品：HARA报告、FSC、TSC、硬件安全分析报告、软件安全分析报告、验证报告、安全档案汇总：必须有标准化模板。模板不只是格式化工具，更是完整性检查清单：模板中的每一个章节标题都在提醒你“这一项不能漏“。

2. 评审与批准工作流：安全工作产品必须经过独立评审（Independent Review）。ISO 26262-2定义了三种独立性等级：I0（自评审，仅适用于QM或ASIL A的非关键工作产品），I1（独立于被评审内容的团队成员评审），I2（独立于整个开发团队的评审）。对于ASIL D的安全档案，评审人必须达到I2级。他/她不能参与过该系统的任何设计或开发活动。评审人的签名、评审意见、结论（通过/有条件通过/不通过）必须被归档。

3. 版本控制与发布管理：每一个安全工作产品都必须有明确的版本号、修订历史、作者、批准人、生效日期。当有人引用“FSR-031 v2.1“时，每个人都能确切地知道那个版本的内容是什么。

4. 文档结构分类：ISO 26262-8将工作产品分为几类：安全计划类（项目安全管理计划、DIA等）、分析类（HARA、FMEA、FTA、DFA）、设计类（安全概念、架构设计）、验证类（测试计划、测试报告）、汇总类（安全档案）。每一类有各自的存放位置、访问权限和保留期限要求。

关于保留期限，ISO 26262没有直接规定：但通常，OEM的采购条款要求安全档案至少保留到车辆停产（EOP）后15年。这意味着你今天的HARA文档，在2039年仍然必须可读、可访问、可理解。所以：不要用个人文件夹保存安全文档。不要用没有备份的服务器。不要用已经不支持的文档格式。如果你今天用Office 2019的宏来跟踪追溯矩阵，确保2039年还有人能打开那个格式。

软件工具鉴定：谁为你的工具链担保？

你用来生成代码的Simulink模型编译器通过了ISO 26262认证吗？你的静态分析工具（Polyspace）能保证不遗漏你代码中的除零错误吗？你的HIL测试平台在注入故障信号时，时间精度能达到毫秒级吗？

软件工具鉴定（Software Tool Qualification） 是ISO 26262-8第11章的专属领域。它的基本逻辑是：如果工具的输出被直接用作安全论证的证据：例如编译器生成的二进制代码就是最终运行的代码，那么工具的可靠性直接影响安全论证的可信度。如果工具出错，你的证据就被污染了。

ISO 26262-8将工具分为三个置信度等级（Tool Confidence Level, TCL）：

• TCL1：工具不可能引入安全相关的错误，或者工具的输出被另一个独立工具验证。例如，一个仅用于格式检查的脚本。它最多告诉你“代码缩进不对“，不会影响安全功能。

• TCL2：工具可能引入安全相关错误，但其输出可以被检测到。例如，模型到代码的自动生成器（Embedded Coder）。如果它错误地将加法运算生成为减法，你在软件单元测试的MC/DC覆盖中几乎一定会发现（因为预期输出与实际输出不匹配）。TCL2工具的鉴定要求包括：工具用户手册中明确描述已知问题和使用限制，定义工具的安全使用场景，以及在项目中记录工具的配置和用例。

• TCL3：工具可能引入安全相关错误，且这种错误无法或极其困难在后续测试中被检测。这是最高风险等级。一个经典例子是故障注入工具（Fault Injection Tool）：如果工具声称“已将扭矩传感器信号注入为开路故障“，但实际注入的是接地短路。你无法在HIL台的常规测试中区分这两种故障，因为两者的系统响应可能是相同的（输出力矩变为0）。TCL3工具必须进行最严格的鉴定：包括工具供应商提供的鉴定证书（ISO 26262:2018 Clause 11.4.8）、对工具安全手册的评估、使用该工具的项目的历史数据、以及可能需要的独立验证测试。

工具分类的决定流程是你需要经历的关键步骤：

1. 列出项目中使用的每一个软件工具：编译器、链接器、代码生成器、静态分析工具、单元测试框架、HIL脚本引擎、CAN通信测试工具……
2. 对每个工具执行TCL分析：
   • TD1（Tool impact）：工具的输出是否直接影响安全相关元素？如果“是“，则TD1=高。否则=低。
   • TD2（Tool error detection）：工具的错误是否可以在后续开发或验证活动中被检测到？如果“否“，则TD2=高。否则=低。
   • TD3（Tool confidence determination）：如果TD1+TD2都是高：TCL3。如果TD1高、TD2低：TCL2。如果TD1低：TCL1。
3. 对TCL2和TCL3工具，选择合适的鉴定方法并执行鉴定活动。

在实际项目中，工具鉴定经常被低估。你可能觉得“我用的都是业界主流工具，不会有问题“。但评估员要的是证据，不是感觉。如果你说不出你的编译器属于哪个TCL等级、有没有做过鉴定。他会在评估报告中写下一个弱项（Weakness），甚至一个不合格项（Non-conformity）。

软件组件鉴定与分布式开发

ISO 26262-8还涵盖了两个重要主题：软件组件鉴定（Qualification of Software Components, 第12章）和分布式开发接口（Interfaces within Distributed Developments, 第5.3.2节）。

软件组件鉴定回答一个问题：我能不能把一个已有的软件：比如一个在以前项目中用过的CAN协议栈、一个从开源社区拿来的AES加密库、一个供应商提供的电机控制算法：直接用于我的ASIL D系统？

答案是可以，但有条件。ISO 26262-8第12章定义了“安全相关软件组件的复用“（Reuse of Software Component with Safety Evidence）的要求：

• 你必须对复用组件进行Gap Analysis：该组件在之前的应用场景中满足ASIL X（比如ASIL B），但你现在要用在ASIL D的环境中。差距在哪里？是额外需要MC/DC覆盖？是额外的时序约束要求？是更高的代码审查深度？
• 你必须评估该组件在新使用环境中的适用性：之前的AES加密库用于传感器数据加密（ASIL A），现在你要用它来加密关键安全消息（ASIL D）。这需要的密钥管理、侧信道攻击防护、自测试覆盖都完全不同。
• 你必须提供该组件的使用历史数据：这个组件在多少台车上跑过？运行了多少小时？出现了多少次相关故障？这些数据是它在新项目中“安全信用“的依据。

分布式开发接口处理的是OEM-供应商之间的责任边界。在典型的汽车项目中，OEM定义了功能安全概念和整车级安全目标，Tier-1负责技术安全概念和系统设计，Tier-2提供芯片和基础软件。这个链条上的每一环都有各自的安全责任。但如果没有清晰的接口协议，安全就会从缝隙中漏掉。

ISO 26262要求OEM和每个Tier-1供应商之间签署开发接口协议（Development Interface Agreement, DIA）。DIA中必须明确定义：

• 双方各自的安全职责：谁负责哪一部分的安全分析、谁负责哪一部分的验证、谁负责哪一部分的安全档案维护；
• 安全要求的分发：OEM下发FSR给Tier-1，Tier-1据此生成TSR。如果Tier-1认为某个FSR在技术上无法实现（比如“EPS必须在天线失效后50ms内进入安全状态“：但通信周期是100ms，物理上不可能），DIA中必须描述升级/协商机制；
• 工作产品的交换格式、交换频率和验收标准：Tier-1交付安全档案碎片给OEM时，OEM如何验证这些碎片符合ISO 26262标准？
• 安全评估的独立性要求：Tier-1的内部安全评审是否能被OEM接受，还是必须由第三方评估机构对Tier-1的工作进行独立评审？

DIA不只是一张签了字的纸。它是OEM和供应商在安全责任上的“宪法“。当出问题时，DIA告诉各方“谁该做什么“，以及“谁没有做什么“。

安全档案：所有证据的最终归宿

现在，我们把所有线索拉回来：配置管理保证了每个工作产品的版本一致性。变更管理保证了每一次修改都有影响分析。文档管理保证了所有工作产品格式统一、评审充分、归档完好的方式存在。工具鉴定保证了生成和验证这些工作产品的工具本身是可信的。软件组件鉴定保证了复用的“外来物“不会破坏安全论证的完整性。分布式开发接口保证了供应链上的安全责任无缝衔接。

这一切汇聚成一个东西：安全档案（Safety Case）。

ISO 26262-2第6.4.8节定义：安全档案是一个“持续的、有结构性的、论证性的沟通媒介“，它包含安全论证（Safety Argument）以及支撑论证的工作产品（Work Products）。

安全论证的结构是逻辑性的：它由一系列“论点-子论点-证据“的树形结构构成。顶层的论点是：“本系统在整车生命周期内对安全目标实现了可接受的风险水平。“它通过下面这些子论点逐层展开：

1. 危害分析正确且有足够覆盖：证据：HARA报告、FMEA报告、DFA报告、危害事件清单及其评审记录；
2. 安全概念实现了足够风险降低：证据：FSC、TSC、安全机制定义、冗余设计文档；
3. 硬件架构满足随机硬件失效量化目标：证据：SPFM/LFM计算表、PMHF计算表、硬件详细设计文档、失效率数据库引用；
4. 软件架构满足单一故障独立性：证据：FFI分析报告、软件架构图、ASIL分解与共存论证；
5. 硬件/软件验证覆盖了所有TSR：证据：测试计划、测试用例、测试结果（通过/失败）、未关闭缺陷清单、回归测试记录；
6. 系统集成和整车验证确认了安全目标：证据：集成测试报告、HIL测试结果、整车道路测试数据；
7. 生产、运维和退役过程中的安全也被管理：证据：EOL测试规格、现场监控流程、维修手册安全章节。

评估员翻开安全档案时，他能看到这棵“论证树“的完整结构。他能点击任何一个子论点，钻取到它的证据层：看到版本号、作者、评审人、批准日期、测试结果的确切数据。他能反向追溯：看到任何一个测试用例覆盖了哪个TSR、追溯到哪个FSR、最终追溯到HARA中的哪个危害事件。

这就是“如果没写下来，就没有发生过“的真正含义。 它不是一句口号。它是ISO 26262对你的工程逻辑体系完整性的唯一客观评价方式。你可以有世界上最先进的故障检测算法、最精妙的三重冗余架构：但如果它们不能被独立第三方，在任何时间、只凭你的安全档案就能完整地被理解和验证。那么它们在评估的世界中，就等于不存在。

免疫隐喻：组织记忆与免疫接种记录

如果之前Part 3到Part 6讲的是免疫系统的“效应机制“：T细胞如何识别抗原、抗体如何中和病毒。那么Part 8讲的是免疫系统的组织记忆。

• 配置管理 ≈ 免疫系统的基因重排记录。B细胞和T细胞在成熟过程中经历了V(D)J基因重排，产生天文学数量的抗原受体多样性。每一次重排都被精确“记录“在细胞的DNA中，不可丢失、不可混淆。配置管理确保每一个安全相关的工作产品在每一个时间点的状态都被记录。你可以随时“回放“到项目任意时刻的安全论证状态。

• 变更管理 ≈ 免疫系统的耐受机制。一个成熟的免疫系统能区分“自我“和“非我“：对自身组织保持免疫耐受，不发动攻击。变更影响分析就是这个耐受机制在功能安全领域的体现：你引入的每一项变更，系统必须评估它是否会导致“自身免疫攻击“（安全论证的某个环节被无意破坏）。如果会，评估机制触发“免疫排斥“：拒绝变更，或要求在变更前补全受影响的安全活动。

• 文档管理 ≈ 免疫接种记录本。你去非洲旅行前需要打黄热病疫苗，医生在你的黄色小本上盖一个章，记录疫苗批号、接种日期、有效期。ISO 26262的文档管理就是这个“黄色小本“。它不直接保护你免受病毒侵害，但它证明你确实接种了疫苗（做了安全分析），并且疫苗还在有效期内（工作产品经过了评审和批准）。

• 工具鉴定 ≈ 检测试剂盒的注册审批。一个PCR检测试剂盒必须经过临床验证（检测灵敏度和特异性达到多少百分比），才能被批准用于疾病诊断。一个代码生成器必须经过工具鉴定（被证明在特定使用条件下不会引入不可检测的错误），才能被用于生产安全相关的代码。

• 安全档案 ≈ 免疫系统的状态证明。一个运动员在参加国际比赛前需要提交体检报告、疫苗接种证明、兴奋剂检测结果。安全档案就是功能安全的“体检报告“。它向OEM、向监管机构、向社会证明：“这个系统经过了充分的免疫接种和健康检查，可以安全地运行在公共道路上。”

本篇小结

1. 配置管理是安全论证的时间锚
2. 文档管理是安全论证的载体
3. 工具鉴定防止“检测工具“本身出错
4. 软件组件鉴定保证复用的“外来物“与新环境兼容
5. DIA是供应链安全责任的宪法
6. 安全档案是所有活动的最终汇聚

【下集预告】： 配置管理锁住了每个版本，变更管理控制了每一次修改，工具鉴定保证了工具可信——但你还需要一个全景。下一节是第2章的收官之作：以SG-001“转向助力不得在驾驶员请求时失效“为线索，从HARA出发，穿过FSC、TSC、硬件SPFM计算、软件MC/DC测试、HIL集成、整车道路验证，一直到评估员在安全档案上签字。一条完整的论证链，看它如何从头串到尾。