ARTICLE · 1292415

别把 Safety Case 写成安全文档堆砌!智驾功能安全论证怎么写

发布时间：2026-11-01 19:41:19 最近访问：2026-11-01 19:41:19

做智驾功能安全、体系、质量的同行，应该都有共同的痛点： HARA 评估做完、FMEA 反复迭代、仿真脚本跑满、实车标定和道路测试一轮轮落地，上百份分析报告、测试报告整理归档，信心满满提交 Safety Case，等来的却是审核老师一句：论证不充分，打回重写。

很多项目团队第一反应是疑惑：该做的分析都做了，该跑的测试也都测了，为什么 Safety Case 还是过不了？

答案很简单：大部分团队，都把 Safety Case 做成了安全文档合集。把 HARA、FTA、FMEA、测试报告、标定报告直接打包拼接，目录一合并就交付。这是写 Safety Case 最大的误区。

一、先搞懂：Safety Case 到底是什么？

按照 ISO 26262 定义，Safety Case（安全论证文件）不是一份汇总报告，而是结构化、可追溯、有层级的论证集合。它的核心使命，是向评审方、客户、认证机构证明一个核心命题：

在明确定义的 ODD（运行设计域）范围内，本智驾系统的危险已经被充分识别，对应的风险得到合理管控、充分验证，系统剩余风险可接受。

它有一条不能断裂的主线：安全目标（Safety Goal） → 功能安全需求（FSR） → 技术安全需求（TSR） → 验证策略 → 证据采集 → 风险结论

所有文档、数据、测试结果，都应该是支撑这条主线的证据，而不是独立零散的附件。一份合格的 Safety Case，本质是讲一个严谨的安全故事：我们识别了什么危险→我们定了什么目标去防→我们拆解了哪些安全要求→我们打算用什么方式验证→我们拿到了哪些证据证明满足→最终风险可控。

没有这条主线，文档再多、数据再厚，都只是资料堆，不是论证。

二、质量人在 Safety Case 里，到底要扛哪些责任？

很多项目里，Safety Case 由系统工程师或者安全工程师主导撰写，但质量是贯穿全程的守门员，也是审核时重点核查的角色，核心价值集中在 4 件事：

✅证据一致性把关，双向追溯闭环追溯是 ISO 26262 审核的重中之重。安全目标能不能对应到 HARA 识别的危险？安全需求能不能对应 FMEA 失效项？测试用例是不是完全覆盖安全需求？测试失败项有没有闭环？质量要守住 “不两张皮”：需求、风险分析、用例、测试报告、偏差处理记录，链路必须双向可查。经常出现的问题：需求更新了，但测试用例没有同步修订，追溯矩阵断链，直接被审核质疑。

✅提前识别论证缺口，避免临 SOP 翻车安全工程师容易埋头做仿真、做场景，但容易忽略论证维度是否完整。质量要站在评审视角挑漏洞：某一类失效风险，是不是只做了仿真验证，缺少实车道路测试佐证？边缘场景、故障注入场景、人机接管场景覆盖够不够？有没有危险仅仅做了定性分析，缺少定量的风险评估？提前挖出论证缺口，在项目中期补齐，远好过 SOP 前夕审核卡壳，倒逼加班补测试。

✅变更管控：Safety Case 不是写完就定稿智驾项目迭代极快：固件版本升级、传感器硬件换型、场景库扩容、ODD 边界调整、需求变更…… 只要影响安全目标、安全需求或者风险结论，Safety Case 就必须同步开展影响评估、更新论证、更新证据。不存在 “版本冻结之后，Safety Case 就不用改”。变更闭环，是审核常年关注的点。一旦论证和当前版本系统不一致，直接判定 Safety Case 无效。

✅划清边界：区分 ISO26262 Safety Case 和 SOTIF 安全论证这是超高频踩坑点，很多团队会把两套证据混在一起。

ISO 26262 功能安全 Safety Case：聚焦系统性失效、硬件随机失效，防止因系统故障导致危险；证据池以 HARA、FMEA、FTA、硬件指标、故障注入测试、硬件可靠性数据为主。

SOTIF 预期功能安全论证：聚焦系统功能本身的局限性、未知不安全场景，即使系统没有故障，也可能因为场景、感知局限出问题；证据池以场景库、ODD 分析、场景挖掘、大规模道路数据、刺激测试为主。

两者论证对象、逻辑、接受准则完全不同，不能揉在同一个 Safety Case 里混审，证据不能互相借用。审核老师很容易抓住这个问题提严重缺陷。

三、项目临近 SOP 审核翻车，根源大多在这里

我们见过太多智驾项目，前面开发、测试都顺利，卡在安全论证环节，影响量产节点。表面看是缺几份报告，底层原因是论证碎片化：危险分析是一套、安全需求是一套、测试是另一套。各个模块独立产出，没有串联成一条完整的证明链。评审方看不到：每一条安全需求，都有对应的验证策略；每一条验证策略，都有充分证据证明已经达成。