汽车电子ISO 26262功能安全系列（第30期）：软件安全档案（Safety Case）——把“我证明我安全”写进文档里
原文链接：https://mp.weixin.qq.com/s/0xz19HND7INl_78B6n72rw
🚗
一句话总结：本文深入拆解ISO 26262软件开发的“终极交付物”——软件安全档案（Software Safety Case），讲清楚它是什么、为什么要做、包含哪些内容、怎么构建，以及如何用它向审核员证明“我的软件是安全的”，用ACC控制器案例完整走一遍从“做安全”到“证明安全”的实战之路。
🤔 先回答一个“项目经理の终极拷问”
前几期我们把软件开发的每一个环节都走了一遍——从SSR导出、架构设计、安全编码、单元测试、集成测试到嵌入式验证。每项工作都做了，每个测试都过了。有读者问了一个特别“致命”的问题：
“所有活都干完了，测试报告堆了一桌子——但怎么向审核员证明‘我的软件是安全的’？总不能把一桌子纸推过去说‘你看，都在这里’吧？”
**问到了点子上！**这就是 “安全档案（Safety Case）” 要解决的问题。
干活 = 你建了一栋楼，装了消防系统、监控摄像头、备用电源 🏗️ 安全档案 = 你拿出一份完整的报告，告诉审核员：“消防系统通过了XX测试，监控覆盖了所有区域，备用电源可以支撑XX小时——这是所有证据，请看” 📋
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 6） | SSR、软件架构、单元测试报告、集成测试报告、覆盖率报告 |
| 🏭 生产与运营（Part 7） | 生产计划、操作手册、维护手册 |
💡 安全档案是跨整个V模型的——从概念到生产，每一个阶段的工作产品都是安全档案的证据来源。
🛠️ 怎么构建安全档案？两种主流方法
方法一：GSN（目标结构符号）
GSN（Goal Structuring Notation） 是构建安全档案最常用的图形化方法。GSN的核心元素：
| 符号 | 含义 | 大白话 |
|---|---|---|
| 🎯 目标（Goal） | 要证明的论点 | “系统是安全的” |
| 📋 策略（Strategy） | 如何分解目标 | “通过证明所有SSR都被实现” |
| 📄 证据（Evidence） | 支撑论点的具体材料 | “单元测试报告#001” |
| 🔗 上下文（Context） | 论证的假设条件 | “假设MCU是ASIL-D认证的” |
GSN示例（ACC安全档案顶层结构） ：
💡 GSN的优势：把“安全论证”可视化，审核员一眼就能看出你的逻辑链条是否完整。
方法二：基于模板的结构化文档
对于大多数项目，更实用的方法是按照ISO 26262的工作产品清单，逐项准备文档，然后用一个“索引文档”把它们串起来。安全档案索引文档结构示例：1. 引言 1.1 文档目的 1.2 适用范围（ACC控制器，ASIL-D） 1.3 术语和缩写 2. 系统概述 2.1 系统功能描述 2.2 系统边界与接口 3. 安全主张（Claims） 3.1 安全目标清单（SG-01~SG-04） 3.2 功能安全需求（FSR） 3.3 软件安全需求（SSR） 4. 安全论证（Arguments） 4.1 论证1：所有SSR已被正确实现 → 见证据A 4.2 论证2：所有安全机制已被验证 → 见证据B 4.3 论证3：软件架构实现了FFI → 见证据C 5. 安全证据（Evidence）索引 5.1 概念阶段证据：HARA报告、SG、FSC 5.2 系统阶段证据：TSC、HSI、系统测试报告 5.3 硬件阶段证据：HSR、FMEDA报告 5.4 软件阶段证据：SSR、架构文档、单元测试报告、集成测试报告、覆盖率报告 6. 可追溯性矩阵 6.1 SG ↔ FSR ↔ SSR 追溯 6.2 SSR ↔ 测试用例 追溯 7. 安全档案维护计划 7.1 变更影响评估流程 7.2 安全档案更新机制
💡 关键原则：安全档案不是“把所有文档堆在一起”，而是用索引文档把所有证据按逻辑组织起来，让审核员能快速找到“某个主张对应的证据在哪里”。
🔥 实战：ACC控制器软件安全档案完整构建
把以上所有内容整合起来，ACC控制器软件安全档案的完整构建过程如下：
Step 1：定义安全主张（Claims）
| 主张ID | 主张内容 | 对应安全目标 |
|---|---|---|
| C-01 | ACC软件满足所有软件安全需求（SSR） | SG-01, SG-02 |
| C-02 | ACC软件的安全机制已通过验证 | SG-01, SG-02 |
| C-03 | ACC软件架构实现了免于干扰（FFI） | SG-01, SG-02 |
| C-04 | ACC软件的单元测试达到100%覆盖率 | SG-01, SG-02 |
Step 2：构建论证（Arguments）
以C-01为例：“ACC软件满足所有软件安全需求（SSR）”
| 论据ID | 论据内容 | 支撑证据 |
|---|---|---|
| A-01-01 | SSR-01（跟车距离计算）已被正确实现 | 设计文档、代码审查记录、单元测试报告 |
| A-01-02 | SSR-02（安全状态管理）已被正确实现 | 设计文档、代码审查记录、单元测试报告 |
| A-01-03 | SSR-03（程序流监控）已被正确实现 | 设计文档、代码审查记录、集成测试报告 |
Step 3：收集证据（Evidence）
| 证据ID | 证据名称 | 位置 | 关联论据 |
|---|---|---|---|
| E-01 | 软件安全需求规范（SSR） | 文档库/SSR_v2.3.docx | A-01-01~03 |
| E-02 | 软件架构设计文档 | 文档库/Arch_v1.2.docx | A-01-01~03 |
| E-03 | 代码审查记录 | 工具/GitLab/MR-123 | A-01-01~03 |
| E-04 | 单元测试报告（Tessy输出） | 工具/Tessy/Report_2026-07 | A-01-01~03 |
| E-05 | 集成测试报告 | 文档库/Integration_Test_v1.0.docx | A-01-03 |
| E-06 | 覆盖率报告（100% MC/DC） | 工具/Tessy/Coverage_2026-07 | C-04 |
Step 4：建立可追溯性矩阵
这是审核员必查的内容。
| 安全目标（SG） | 功能安全需求（FSR） | 软件安全需求（SSR） | 测试用例 | 测试结果 |
|---|---|---|---|---|
| SG-01 | FSR-01 | SSR-01 | TC-001~010 | ✅ PASS |
| SG-01 | FSR-02 | SSR-02 | TC-011~020 | ✅ PASS |
| SG-01 | FSR-03 | SSR-03 | TC-021~030 | ✅ PASS |
| SG-02 | FSR-04 | SSR-04 | TC-031~040 | ✅ PASS |
💡 追溯矩阵的价值：审核员问“SG-01怎么证明实现了？”——你从矩阵里找到SG-01 → FSR-01 → SSR-01 → TC-001~010 → 全部PASS，证据链完整。
🛠️ 安全档案管理工具
手动管理安全档案（尤其是可追溯性）在大型项目中非常困难。行业里有一些专业工具可以帮忙：
| 工具 | 功能 | 特点 |
|---|---|---|
| Ansys Medini | HARA、FTA、FMEA、FMEDA、需求追溯一体化 | 功能安全专用，模板丰富 |
| AVL ComplyGuard | 安全计划、安全档案、V&V计划生成 | 加速认证流程 |
| safeTbox（Fraunhofer IESE） | GSN安全论证文档化 | 支持GSN图形化 |
| Axivion Suite | 静态代码分析+架构验证，直接贡献安全档案证据 | 通过SGS-TÜV认证，支持ASIL-D |
💡 工具选择原则：工具本身需要有功能安全认证（或已被评估为可用于功能安全开发），否则它产出的报告不能作为安全档案的证据。
⚠️ 安全档案构建中容易踩的“坑”
坑1：把“文档堆”当成“安全档案”
❌ 把所有项目文档放在一个文件夹里，说“这就是安全档案” ✅ 安全档案是有逻辑结构的论证——有主张、有论据、有证据，三者之间有清晰的追溯关系
坑2：证据和主张对不上
❌ 主张说“所有SSR都被实现了”，但证据里只有部分SSR的测试报告 ✅ 每个主张必须有对应的证据支撑——缺一个都不行
坑3：忘了建立可追溯性
❌ 测试用例和需求之间没有关联 ✅ 建立SG ↔ FSR ↔ SSR ↔ 测试用例 ↔ 测试结果的完整追溯链
坑4：安全档案做完了就不管了
❌ 安全档案是一次性工作，做完就锁起来了 ✅ ISO 26262要求当系统发生变更时，必须评估变更对安全档案的影响，并相应更新安全档案
🧠 本期重点回顾
| 核心概念 | 核心要点 |
|---|---|
| 📋 安全档案定义 | 结构化的、基于证据的论证，证明系统对预期用途是足够安全的 |
| 🧱 三块基石 | 主张（Claim）+ 论据（Argument）+ 证据（Evidence） |
| 📄 证据来源 | 贯穿整个V模型——从概念到生产，每个阶段的验证报告都是证据 |
| 🗺️ 两种构建方法 | GSN（图形化论证）和结构化文档（索引+证据） |
| 🔗 可追溯性 | 审核必查项——SG ↔ FSR ↔ SSR ↔ 测试用例的完整链条 |
| 🛠️ 管理工具 | Ansys Medini、AVL ComplyGuard、safeTbox、Axivion |
📢 下期预告
【第31期】：ASIL分解——如何“拆解”高等级安全要求？今天我们完成了软件安全档案的构建，把整个Part 6的内容画上了句号。下期咱们进入支撑流程与分析方法模块——聊聊ASIL分解。ASIL-D太贵太难了怎么办？能不能把“一个D”拆成“两个B”？拆了之后怎么保证安全性不降级？敬请期待！
系列简介：《汽车电子ISO 26262功能安全系列》共计40期，系统讲解汽车功能安全标准的完整知识体系。从概念到实践，从理论到落地，层层递进，帮你构建从入门到精通的功能安全知识体系。本期为第30期。
💡 如果觉得有帮助，欢迎点赞、在看、转发三连！你的支持是我持续输出的最大动力～💡 喜欢请持续关注 【AI超级个体实践】 ，更多硬核内容持续输出！