ISO 26262要求的不是“你做了安全”而是“你能证明你做了安全”。安全档案就是这份“证明”。安全档案到底是什么官方定义ISO 26262对安全档案的定义是“一种结构化的、基于证据的论证证明一个E/E系统对于其预期用途是足够安全的。”拆开来看三个关键词关键词大白话结构化的“不是一堆文件乱堆是有逻辑、有层次的”基于证据的“不是空口说白话每个论点都有测试报告、分析文档支撑”论证“不只是‘展示证据’而是‘用证据讲一个完整的安全故事’”安全档案的核心逻辑你说“我的软件是安全的”——凭什么凭这些证据测试报告、分析文档、评审记录……而且这些证据是有逻辑地组织在一起的形成了一个完整的“安全论证链条”。安全档案 vs 普通文档有什么区别对比维度普通项目文档安全档案Safety Case目的记录项目过程证明系统安全结构按文档类型组织按论证逻辑组织内容事实陈述主张 论据 证据读者项目团队成员审核员、认证机构核心问题“我们做了什么”“凭什么说它是安全的”核心区别普通文档回答“做了什么”安全档案回答“凭什么说安全”——后者需要把证据组织成一个有说服力的论证链条。安全档案的“三块基石”主张、论据、证据安全档案的核心结构可以简化为一个“三段论”第一块基石主张Claim主张是你要证明的核心论点。ACC示例“ACC控制器的软件是安全的符合ISO 26262 ASIL-D要求”第二块基石论据Argument论据是支持主张的逻辑链条——“为什么这么说”。ACC示例“因为所有软件安全需求SSR都被正确实现了”“因为所有安全机制看门狗、E2E、程序流监控都经过了验证”“因为软件架构实现了免于干扰FFI”“因为单元测试达到了100%的MC/DC覆盖率”第三块基石证据Evidence证据是支撑论据的具体材料——“有什么证据支持这个说法”。ACC示例论据证据“所有SSR都被正确实现了”需求追溯矩阵、设计文档、代码审查记录“所有安全机制都经过了验证”单元测试报告、集成测试报告、故障注入测试报告“软件架构实现了FFI”架构设计文档、MPU配置记录、内存分区分析报告“单元测试达到了100% MC/DC”覆盖率报告Tessy输出、测试用例清单安全档案的“全貌”ISO 26262要求哪些证据ISO 26262-6软件开发要求在整个软件V模型开发过程中产生大量的验证报告Verification Reports这些报告都是安全档案的重要组成部分。Part 6要求的验证报告清单软件开发阶段ISO 26262条款需要的验证报告软件安全需求规范6.5.4软件安全需求验证报告️软件架构设计7.5.6软件架构验证报告软件单元设计与实现8.5.3软件单元设计验证报告软件单元测试9.5.3软件单元测试验证报告软件集成与测试10.5.4软件集成测试验证报告✅软件安全需求验证11.5.3软件安全需求验证报告每一个验证报告都是一块“证据砖”。安全档案就是把所有砖块按逻辑砌成一面完整的“证据墙”。安全档案还需要哪些“非软件”证据除了Part 6的软件验证报告安全档案还需要包含来自其他部分的证据证据来源包含内容概念阶段Part 3相关项定义、HARA分析报告、安全目标SG、功能安全概念FSC️系统阶段Part 4技术安全概念TSC、系统架构设计、HSI规范、系统集成测试报告、安全确认报告⚡硬件阶段Part 5硬件安全需求HSR、硬件架构设计、FMEDA报告SPFM/LFM/PMHF软件阶段Part 6SSR、软件架构、单元测试报告、集成测试报告、覆盖率报告生产与运营Part 7生产计划、操作手册、维护手册安全档案是跨整个V模型的——从概念到生产每一个阶段的工作产品都是安全档案的证据来源。怎么构建安全档案两种主流方法方法一GSN目标结构符号GSNGoal Structuring Notation是构建安全档案最常用的图形化方法。GSN的核心元素符号含义大白话目标Goal要证明的论点“系统是安全的”策略Strategy如何分解目标“通过证明所有SSR都被实现”证据Evidence支撑论点的具体材料“单元测试报告#001”上下文Context论证的假设条件“假设MCU是ASIL-D认证的”GSN示例ACC安全档案顶层结构GSN的优势把“安全论证”可视化审核员一眼就能看出你的逻辑链条是否完整。方法二基于模板的结构化文档对于大多数项目更实用的方法是按照ISO 26262的工作产品清单逐项准备文档然后用一个“索引文档”把它们串起来。关键原则安全档案不是“把所有文档堆在一起”而是用索引文档把所有证据按逻辑组织起来让审核员能快速找到“某个主张对应的证据在哪里”。实战ACC控制器软件安全档案完整构建把以上所有内容整合起来ACC控制器软件安全档案的完整构建过程如下Step 1定义安全主张Claims主张ID主张内容对应安全目标C-01ACC软件满足所有软件安全需求SSRSG-01, SG-02C-02ACC软件的安全机制已通过验证SG-01, SG-02C-03ACC软件架构实现了免于干扰FFISG-01, SG-02C-04ACC软件的单元测试达到100%覆盖率SG-01, SG-02Step 2构建论证Arguments以C-01为例“ACC软件满足所有软件安全需求SSR”论据ID论据内容支撑证据A-01-01SSR-01跟车距离计算已被正确实现设计文档、代码审查记录、单元测试报告A-01-02SSR-02安全状态管理已被正确实现设计文档、代码审查记录、单元测试报告A-01-03SSR-03程序流监控已被正确实现设计文档、代码审查记录、集成测试报告Step 3收集证据Evidence证据ID证据名称位置关联论据E-01软件安全需求规范SSR文档库/SSR_v2.3.docxA-01-01~03E-02软件架构设计文档文档库/Arch_v1.2.docxA-01-01~03E-03代码审查记录工具/GitLab/MR-123A-01-01~03E-04单元测试报告Tessy输出工具/Tessy/Report_2026-07A-01-01~03E-05集成测试报告文档库/Integration_Test_v1.0.docxA-01-03E-06覆盖率报告100% MC/DC工具/Tessy/Coverage_2026-07C-04Step 4建立可追溯性矩阵这是审核员必查的内容。安全目标SG功能安全需求FSR软件安全需求SSR测试用例测试结果SG-01FSR-01SSR-01TC-001~010✅ PASSSG-01FSR-02SSR-02TC-011~020✅ PASSSG-01FSR-03SSR-03TC-021~030✅ PASSSG-02FSR-04SSR-04TC-031~040✅ PASS追溯矩阵的价值审核员问“SG-01怎么证明实现了”——你从矩阵里找到SG-01 → FSR-01 → SSR-01 → TC-001~010 → 全部PASS证据链完整。安全档案管理工具手动管理安全档案尤其是可追溯性在大型项目中非常困难。行业里有一些专业工具可以帮忙工具功能特点Ansys MediniHARA、FTA、FMEA、FMEDA、需求追溯一体化功能安全专用模板丰富AVL ComplyGuard安全计划、安全档案、VV计划生成加速认证流程safeTboxFraunhofer IESEGSN安全论证文档化支持GSN图形化Axivion Suite静态代码分析架构验证直接贡献安全档案证据通过SGS-TÜV认证支持ASIL-D工具选择原则工具本身需要有功能安全认证或已被评估为可用于功能安全开发否则它产出的报告不能作为安全档案的证据。安全档案构建中容易踩的“坑”坑1把“文档堆”当成“安全档案”❌ 把所有项目文档放在一个文件夹里说“这就是安全档案”✅ 安全档案是有逻辑结构的论证——有主张、有论据、有证据三者之间有清晰的追溯关系坑2证据和主张对不上❌ 主张说“所有SSR都被实现了”但证据里只有部分SSR的测试报告✅每个主张必须有对应的证据支撑——缺一个都不行坑3忘了建立可追溯性❌ 测试用例和需求之间没有关联✅ 建立SG ↔ FSR ↔ SSR ↔ 测试用例 ↔ 测试结果的完整追溯链坑4安全档案做完了就不管了❌ 安全档案是一次性工作做完就锁起来了✅ ISO 26262要求当系统发生变更时必须评估变更对安全档案的影响并相应更新安全档案
ISO 26262要求的不是“你做了安全”而是“你能证明你做了安全”。安全档案就是这份“证明”。安全档案到底是什么官方定义ISO 26262对安全档案的定义是“一种结构化的、基于证据的论证证明一个E/E系统对于其预期用途是足够安全的。”拆开来看三个关键词关键词大白话结构化的“不是一堆文件乱堆是有逻辑、有层次的”基于证据的“不是空口说白话每个论点都有测试报告、分析文档支撑”论证“不只是‘展示证据’而是‘用证据讲一个完整的安全故事’”安全档案的核心逻辑你说“我的软件是安全的”——凭什么凭这些证据测试报告、分析文档、评审记录……而且这些证据是有逻辑地组织在一起的形成了一个完整的“安全论证链条”。安全档案 vs 普通文档有什么区别对比维度普通项目文档安全档案Safety Case目的记录项目过程证明系统安全结构按文档类型组织按论证逻辑组织内容事实陈述主张 论据 证据读者项目团队成员审核员、认证机构核心问题“我们做了什么”“凭什么说它是安全的”核心区别普通文档回答“做了什么”安全档案回答“凭什么说安全”——后者需要把证据组织成一个有说服力的论证链条。安全档案的“三块基石”主张、论据、证据安全档案的核心结构可以简化为一个“三段论”第一块基石主张Claim主张是你要证明的核心论点。ACC示例“ACC控制器的软件是安全的符合ISO 26262 ASIL-D要求”第二块基石论据Argument论据是支持主张的逻辑链条——“为什么这么说”。ACC示例“因为所有软件安全需求SSR都被正确实现了”“因为所有安全机制看门狗、E2E、程序流监控都经过了验证”“因为软件架构实现了免于干扰FFI”“因为单元测试达到了100%的MC/DC覆盖率”第三块基石证据Evidence证据是支撑论据的具体材料——“有什么证据支持这个说法”。ACC示例论据证据“所有SSR都被正确实现了”需求追溯矩阵、设计文档、代码审查记录“所有安全机制都经过了验证”单元测试报告、集成测试报告、故障注入测试报告“软件架构实现了FFI”架构设计文档、MPU配置记录、内存分区分析报告“单元测试达到了100% MC/DC”覆盖率报告Tessy输出、测试用例清单安全档案的“全貌”ISO 26262要求哪些证据ISO 26262-6软件开发要求在整个软件V模型开发过程中产生大量的验证报告Verification Reports这些报告都是安全档案的重要组成部分。Part 6要求的验证报告清单软件开发阶段ISO 26262条款需要的验证报告软件安全需求规范6.5.4软件安全需求验证报告️软件架构设计7.5.6软件架构验证报告软件单元设计与实现8.5.3软件单元设计验证报告软件单元测试9.5.3软件单元测试验证报告软件集成与测试10.5.4软件集成测试验证报告✅软件安全需求验证11.5.3软件安全需求验证报告每一个验证报告都是一块“证据砖”。安全档案就是把所有砖块按逻辑砌成一面完整的“证据墙”。安全档案还需要哪些“非软件”证据除了Part 6的软件验证报告安全档案还需要包含来自其他部分的证据证据来源包含内容概念阶段Part 3相关项定义、HARA分析报告、安全目标SG、功能安全概念FSC️系统阶段Part 4技术安全概念TSC、系统架构设计、HSI规范、系统集成测试报告、安全确认报告⚡硬件阶段Part 5硬件安全需求HSR、硬件架构设计、FMEDA报告SPFM/LFM/PMHF软件阶段Part 6SSR、软件架构、单元测试报告、集成测试报告、覆盖率报告生产与运营Part 7生产计划、操作手册、维护手册安全档案是跨整个V模型的——从概念到生产每一个阶段的工作产品都是安全档案的证据来源。怎么构建安全档案两种主流方法方法一GSN目标结构符号GSNGoal Structuring Notation是构建安全档案最常用的图形化方法。GSN的核心元素符号含义大白话目标Goal要证明的论点“系统是安全的”策略Strategy如何分解目标“通过证明所有SSR都被实现”证据Evidence支撑论点的具体材料“单元测试报告#001”上下文Context论证的假设条件“假设MCU是ASIL-D认证的”GSN示例ACC安全档案顶层结构GSN的优势把“安全论证”可视化审核员一眼就能看出你的逻辑链条是否完整。方法二基于模板的结构化文档对于大多数项目更实用的方法是按照ISO 26262的工作产品清单逐项准备文档然后用一个“索引文档”把它们串起来。关键原则安全档案不是“把所有文档堆在一起”而是用索引文档把所有证据按逻辑组织起来让审核员能快速找到“某个主张对应的证据在哪里”。实战ACC控制器软件安全档案完整构建把以上所有内容整合起来ACC控制器软件安全档案的完整构建过程如下Step 1定义安全主张Claims主张ID主张内容对应安全目标C-01ACC软件满足所有软件安全需求SSRSG-01, SG-02C-02ACC软件的安全机制已通过验证SG-01, SG-02C-03ACC软件架构实现了免于干扰FFISG-01, SG-02C-04ACC软件的单元测试达到100%覆盖率SG-01, SG-02Step 2构建论证Arguments以C-01为例“ACC软件满足所有软件安全需求SSR”论据ID论据内容支撑证据A-01-01SSR-01跟车距离计算已被正确实现设计文档、代码审查记录、单元测试报告A-01-02SSR-02安全状态管理已被正确实现设计文档、代码审查记录、单元测试报告A-01-03SSR-03程序流监控已被正确实现设计文档、代码审查记录、集成测试报告Step 3收集证据Evidence证据ID证据名称位置关联论据E-01软件安全需求规范SSR文档库/SSR_v2.3.docxA-01-01~03E-02软件架构设计文档文档库/Arch_v1.2.docxA-01-01~03E-03代码审查记录工具/GitLab/MR-123A-01-01~03E-04单元测试报告Tessy输出工具/Tessy/Report_2026-07A-01-01~03E-05集成测试报告文档库/Integration_Test_v1.0.docxA-01-03E-06覆盖率报告100% MC/DC工具/Tessy/Coverage_2026-07C-04Step 4建立可追溯性矩阵这是审核员必查的内容。安全目标SG功能安全需求FSR软件安全需求SSR测试用例测试结果SG-01FSR-01SSR-01TC-001~010✅ PASSSG-01FSR-02SSR-02TC-011~020✅ PASSSG-01FSR-03SSR-03TC-021~030✅ PASSSG-02FSR-04SSR-04TC-031~040✅ PASS追溯矩阵的价值审核员问“SG-01怎么证明实现了”——你从矩阵里找到SG-01 → FSR-01 → SSR-01 → TC-001~010 → 全部PASS证据链完整。安全档案管理工具手动管理安全档案尤其是可追溯性在大型项目中非常困难。行业里有一些专业工具可以帮忙工具功能特点Ansys MediniHARA、FTA、FMEA、FMEDA、需求追溯一体化功能安全专用模板丰富AVL ComplyGuard安全计划、安全档案、VV计划生成加速认证流程safeTboxFraunhofer IESEGSN安全论证文档化支持GSN图形化Axivion Suite静态代码分析架构验证直接贡献安全档案证据通过SGS-TÜV认证支持ASIL-D工具选择原则工具本身需要有功能安全认证或已被评估为可用于功能安全开发否则它产出的报告不能作为安全档案的证据。安全档案构建中容易踩的“坑”坑1把“文档堆”当成“安全档案”❌ 把所有项目文档放在一个文件夹里说“这就是安全档案”✅ 安全档案是有逻辑结构的论证——有主张、有论据、有证据三者之间有清晰的追溯关系坑2证据和主张对不上❌ 主张说“所有SSR都被实现了”但证据里只有部分SSR的测试报告✅每个主张必须有对应的证据支撑——缺一个都不行坑3忘了建立可追溯性❌ 测试用例和需求之间没有关联✅ 建立SG ↔ FSR ↔ SSR ↔ 测试用例 ↔ 测试结果的完整追溯链坑4安全档案做完了就不管了❌ 安全档案是一次性工作做完就锁起来了✅ ISO 26262要求当系统发生变更时必须评估变更对安全档案的影响并相应更新安全档案
