Safety Case 安全案例：基于 GSN 的六层证据包结构解析
图1 Safety Case 安全案例：监管提交型证据结构总览
一 开篇：自动驾驶要“自证安全”，安全案例是监管入场券
自动驾驶系统能否上路，监管不再只看样车跑得是否平稳，而是要求企业把“我为何安全”这件事，用一整套可追溯的证据讲清楚。这份讲清楚的材料，就是安全案例（Safety Case）。
无论 L2 组合驾驶辅助依据联合国法规 UN R171，还是 L3 及以上自动驾驶依据 UN R157 与配套法规 EU 2022/1426，技术审核的底层语言都指向同一套结构化论证——GSN（Goal Structuring Notation，目标结构化记法）。
安全案例不是一份测试报告，也不是一组演示视频，而是一张从顶层安全主张一路拆到原始证据的论证网络。它要回答三类问题：主张是什么、凭什么成立、证据放在哪里。
对整车与系统供应商而言，安全案例是拿到型式批准与上市许可的入场券。没有它，再漂亮的实车演示也无法转化为合规交付，审核会直接卡在“依据不足”这一关。
本文聚焦“证据结构”这一视角：把一份可提交的安全案例拆成六层证据包，逐层说明每层交付什么、依据什么标准、又如何彼此咬合，帮助工程与合规团队建立可操作的全局图。
图2 先给出 GSN 的论证骨架，帮助读者在后续理解六层证据如何挂在论证树上，为什么审核员能从一张图追到每一份底层材料。
图2 GSN 目标结构化记法：目标—策略—证据
二 GSN 目标结构化记法：论证树、目标—策略—证据
GSN 用图形化方式表达“为什么相信某安全主张成立”。顶层是一个目标（Goal），代表系统的整体安全主张；向下通过策略（Strategy）分解为若干子目标，每个叶子节点一路落到证据（Evidence）——一份可核查的交付物。
除这三要素外，GSN 还允许标注假设（Assumption，论证成立所依赖的前提）、上下文（Context，系统边界与适用范围），以及尚未闭合的未解决项（Undersolved）。这些标注让论证的边界与残留议题透明可见。
这种树状分解的好处是责任可视：审核员可以从一个具体证据反向追到顶层主张，也能从顶层主张顺藤摸到每一份底层材料，不必在成堆文档里盲找。
监管之所以偏好 GSN，是因为它把主观自信转成客观可追溯——任何一句安全断言都必须挂得住证据，没有悬空的结论，也没有无法溯源的乐观估计。
需要说明，GSN 本身不规定“证据必须是什么”，它只规定“论证如何组织”。证据的具体内容，正是由后续六层证据包来填充，六层即这棵树的六段主干支撑。
正因为论证与证据解耦，同一套 GSN 框架可以适配不同车型、不同自动化等级，企业只需替换叶子节点的材料，主干逻辑不必推倒重来，积累的经验也能跨项目复用。
表2 把 GSN 各要素与它们在证据结构中的角色一一对应，便于在搭建安全案例时按图索骥，知道每个节点该挂哪类材料。
表2 GSN 要素对照与证据结构角色
三 六层证据包总览：一图看清论证骨架
把若干项目的提交实践加以归纳，一份可提交安全案例通常由六层证据包构成。它们不是平行罗列，而是层层递进：先界定系统本身，再量化风险，随后用功能安全与预期功能安全两条工程线构筑保障，收尾用整车验证与量产运维收口。
层① 系统定义：给出量化 ODD、系统能力清单、系统边界框图、接口 ICD、HMI 接管时序规范，回答“这系统是什么、在哪跑、能力边界在哪”。它是后续一切论证的锚点。
层② 整车危害评估：统一危害库、统一风险矩阵、安全目标清单、需求追溯矩阵 RTM、HARA 评审签署，把“可能伤谁、伤多重”量化出来，为下游分派安全需求。
层③ 功能安全证据包（ISO 26262）：ASIL 分解、FTA、DFMEA/PFMEA、硬件侧度量，应对电子电气系统的随机失效与系统失效。
层④ 预期功能安全证据包（ISO 21448）：场景库构建与分类、已知不安全场景分析、未知场景识别，应对功能本身设计不足、性能局限与合理可预见的误用。
层⑤ 整车验证：ODD 边界测试、MRS 最小风险策略验证、事件数据记录合规测试、接管与降级策略人因测试，把论证落到实车并闭合。
层⑥ 生产运维与变更：生产一致性计划 CoP、上市后安全监控、OTA 安全影响评估、安全变更管理 SCM，让安全在量产与生命周期内持续成立，而非研发段一次性产物。
图3 把六层画成一棵自上而下的论证树，层①到层⑥逐层提供支撑；表1 则给出每层的层名、核心交付物与对应标准，便于对照检视。
图3 六层证据包总览：自顶向下层层支撑
表1 六层证据包总览与对应标准
四 层① 系统定义：先把“讨论对象”钉死
任何安全论证的首要一步，是先把讨论对象钉死。系统定义层就是把自动驾驶系统的形态、运行边界与能力清单写清楚，避免后续论证在模糊对象上打转，导致危害识别与验证都失去基准。
ODD（运行设计域）必须做量化描述：道路类型、速度区间、天气光照、地理围栏等，都要可度量，而非“城市工况”这类含糊说法。量化程度直接决定后续验证能否施力。
系统能力清单列明本系统能接管哪些动态驾驶任务、不能接管哪些，划清“能”与“不能”的线。这条线也是 L2 与 L3 责任划分的依据，含糊不得。
系统边界框图与接口 ICD 描述本系统与感知、规划、执行、网关等相邻模块的交互边界，是后续危害识别、ASIL 分配与追溯的锚点；边界画不清，危害就容易漏到系统外。
HMI 接管时序规范规定系统何时请求接管、给驾驶员多少时间、超时如何降级，这是 L2/L3 责任划分与人因安全的关键材料。时序若写不清，实车验证无从设计。
表3 把层①的五类交付物、各自说明与作用列成对照，便于在提交前逐项核对，确认“对象”这一地基已经夯实。
实践中，层①常被低估：团队急于做危害分析与安全机制，却把 ODD 写成几句定性描述。这样做的后果是，后续所有验证都缺少可量化边界，审核时会要求返工，反而拖慢进度。
图4 层① 系统定义：五类交付物
表3 层① 系统定义交付物清单
五 层② 整车危害评估与 HARA：把“会伤谁、伤多重”量化
危害评估把“系统出问题时可能造成的伤害”系统化梳理。整车级 HARA 先建统一危害库，避免不同团队各列各的危害、口径不一，导致后续安全目标出现重叠或遗漏。
统一风险矩阵给出严重度、暴露概率、可控性三维度评分规则，使 ASIL 评级可复现、可审计。评级一旦靠个人经验拍板，审核时就会因不可复现而被质疑。
安全目标清单从危害反推“系统必须避免什么状态”，是功能安全需求的源头。每个安全目标都要能被下游需求承接，并能在验证层找到对应证据。
需求追溯矩阵 RTM 把安全目标一路挂到下游需求与验证，是六层里“可追溯”的枢纽——后面每一层的安全活动都要能回指到层②的安全目标，形成不断链的回路。
HARA 评审签署是这一层的收口动作：由跨职能团队确认危害识别完整、评级合理，签字即代表责任落地。没有签署，安全目标在法律与审核层面都站不住。
表4 列出 HARA 的五类输出与其去向，提示每一份材料在论证树上的位置；图5 把层②的关键交付物可视化，便于向管理层与审核员快速讲清逻辑。
图5 层② 整车危害评估：关键交付物
表4 层② 整车危害评估输出
六 层③ 功能安全证据包 ISO 26262：应对随机与系统失效
ISO 26262 处理电子电气系统的随机硬件失效与系统失效。证据包的核心是 ASIL 分解：把高等级安全需求拆解到软硬件组件，使整体达标而单体可落地，避免一颗芯片扛下全部等级压力。
FTA（故障树分析）自上而下找导致顶事件的组合路径，适合追“多个条件同时发生时为何失效”；DFMEA 与 PFMEA 自下而上排查设计与制造环节的潜在失效，两者方向相反、互为补充。
硬件侧需提供度量子（如 SPFM、LFM、PMHF）以满足随机失效目标，这是审核常盯的硬指标。度量不达标，再完善的分析也救不回这一层。
这一层与层②通过 RTM 联动：每个安全机制都能追到某条安全目标；它与层④的区别在于，26262 假定“功能设计正确”，只管失效，不追问功能本身是否设计得当。
把层③做好，意味着电子电气系统“即便出故障，也坏不到伤人”。但它不覆盖“功能没错却因场景理解不足而撞车”，那部分要交给层④。
表5 把层③的 ASIL 分解、FTA、DFMEA/PFMEA、硬件度量按类型与说明列出；图6 给出层③的证据形态，便于团队对齐交付口径。
图6 层③ 功能安全 ISO 26262：核心方法
表5 层③ ISO 26262 方法对照
七 层④ 预期功能安全证据包 ISO 21448：即使没坏，会不会撞
ISO 21448（SOTIF）补足 26262 未覆盖的部分：功能本身设计不足、性能局限，以及合理可预见的误用。它不假设功能正确，而是追问“系统没坏，会不会因为没理解场景而出事”。
场景库构建与分类是地基：把车辆可能遭遇的工况结构化、分层、打标签，使验证有迹可循。没有场景库，已知与未知就无从区分，验证也会变成盲目试错。
已知不安全场景分析针对已识别的危险触发条件，给出规避或缓解措施并验证；未知场景识别则用数据驱动方法（自然驾驶数据、仿真、实车）尽量把“未知”变成“已知”，缩小残余风险。
触发条件验证判定性能局限与误用是否落到可接受区间，是层④收口的关键动作。若触发条件无法消除，就要靠层⑤的实车验证证明缓解有效。
值得提醒，场景库不是一次性资产，它会随 ODD 扩充、功能迭代而增长；把场景的增删改也纳入变更流程，才能避免“库在变、论证却没跟着变”的脱节。
这一层与层⑤整车验证紧密咬合：场景库直接喂给 ODD 边界测试与触发条件验证，使“纸上场景”变成“轮上证据”，避免两层各说各话。
表6 列出 SOTIF 的四类活动、对象与产出；图7 把层④的三块内容可视化，帮助团队看清场景库为何是整条证据链的源头。
图7 层④ 预期功能安全 ISO 21448：场景驱动
表6 层④ ISO 21448 活动对照
八 层⑤ 整车验证：把论证落到实车闭合
论证再漂亮，也要在实车上闭合。层⑤把前四层的主张转化为可执行的验证活动，是审核所看重的一锤定音环节——没有它，论证仍停留在纸面。
ODD 边界测试在运行域的边缘与越界处施压，确认系统在该退出时退出、该降级时降级。边界是层①定义的，验证正是检验定义是否被守住。
MRS 最小风险策略验证检查系统触发最小风险机动（如靠边停车）是否真的把风险压到可接受；事件数据记录合规测试确保 EDR 按法规记录关键数据，为事故回溯提供依据。
接管与降级策略人因测试评估驾驶员在系统请求接管后的反应时间与操作可行性，直接关系到 L2/L3 的责任与安全保障。人因不过关，再好的策略也难落地。
这一层把层①②③④的抽象主张变成可被第三方复现的结果，是安全案例从“说得通”到“证得清”的转折。验证用例本身也要能回指安全目标，挂进 RTM。
表7 列出层⑤的验证类别、测试内容与关注点；图8 把四块验证可视化，提示每一类都在闭合哪一段论证。
图8 层⑤ 整车验证：四类测试闭合论证
表7 层⑤ 整车验证类别对照
九 层⑥ 生产运维与变更：让安全在生命周期内持续成立
安全不是研发段一次性产物，要在量产与生命周期内持续成立。层⑥提供让“论证长期有效”的运行证据，否则送审样车安全、量产车却走样，安全案例便失去意义。
生产一致性计划 CoP 保证下线的每台车与送审的那台在关键安全特性上一致；上市后安全监控通过真实世界数据发现研发段未预见的风险，把验证从实验室延伸到道路。
OTA 安全影响评估在每次远程升级前评判“这次改动会不会动到安全相关逻辑”，避免软件更新悄悄削弱安全；安全变更管理 SCM 给所有变更一个审批、评估、记录的回路。
追溯链是层⑥与前面各层的纽带：任一量产变更都要能回指到原始安全目标与验证，形成不断链的回路。一旦断链，审核会质疑“你交付的和你论证的是否还是同一台车”。
这一层也把六层证据从静态文档变成动态资产：监控发现、OTA 改动、变更记录持续回流，论证树随之更新，安全案例才真正“活着”。
表8 把层⑥的四类活动与常见误区、正解并列；图9 可视化层⑥的四块内容，图10 单独强调 RTM 在六层间的串联作用。
图9 层⑥ 生产运维与变更：四块内容
图10 追溯矩阵 RTM：让六层证据彼此咬合
表8 层⑥ 生产运维与常见误区对照
十 企业如何搭建安全案例：角色、工具、维护与常见误区
搭建安全案例是跨职能工程，而非文档部门单独能交付的事。角色上需有安全经理统筹，系统、软件、硬件、测试各出证据，质量与法务把关口径，避免各做各的、缺乏串联。
工具上，需求管理、缺陷跟踪、配置与变更系统要把证据“机制化”产出，减少人肉拼凑；但要注意工具只是器，追溯粒度与责任归属仍由人定义，买工具不等于跑成证据链。
持续维护上，把安全案例当成活文档：每次变更、每次 OTA、每批监控发现，都回流更新论证树，而非认证前突击重写。常态化运行比一次性过关更经得起抽检。
常见误区其一：把安全案例当一次性过关材料，认证后束之高阁，论证很快失活；其二：六层各做各的、缺乏 RTM 串联，审核一追就断；其三：混淆功能安全与预期功能安全边界，用 26262 覆盖本属 SOTIF 的场景风险；其四：ODD 写得模糊，边界说不清，验证无从施力。
回到本质：安全案例是把“我相信它安全”变成“我能证明它安全”。六层证据包不是负担，而是把安全能力沉淀为可审计、可维护、可追溯资产的路径。
需要指出，六层之间并非单向流水，而是一张彼此引用的网：层②定目标，层③层④接需求，层⑤做验证，层⑥管运维，任何一层改动都可能牵动其余各层的追溯与评审，因此尽早统一术语与模板，比事后补链省力。
对准备提交的企业，务实的起手式是先夯实层①系统定义与层②危害评估，把 RTM 这张网织起来——地基与枢纽稳了，上层证据才挂得住、追得清。
能证清，才敢交付、稳交付。图11 给出企业搭建的角色与三步要点，图12 收束全文并提示四类常见误区，供团队对照自查。
图11 企业如何搭建安全案例：角色与要点
图12 结语与四类常见误区自查
— — — — — — — — — — — — — — — —
苏州纳兰企管提供以上专业技术支持，
欢迎联系邮件[email protected]获取解决方案。
