原文链接：https://mp.weixin.qq.com/s/ZjjUcJBO4s1Lj7YrlVpdZw

今天讨论话题：换个角度讨论补文档的事。

一般来说，功能安全由一系列的安全活动以及这些活动的输出件，也就是通常所说的文档，文档不仅数量多，要求也多，一个项目下来好像都是一直在写文档，让很多人都产生了功能安全就是文档工作的偏见。

其实我们要说的不是功能安全本身等于补文档，而是证据导向的认证规则，撞上量产优先的项目节奏，最终把一套覆盖全生命周期的安全工程体系，异化成了末端的文档合规工程。

一、审核导向“文档即证据”

ISO 26262、ASPICE 等标准的认证本质是基于证据的审核，采用「Claim-Argument-Evidence（声明-论证-证据）」逻辑：标准默认「没有书面记录的活动=未执行」。

从HARA危害分析、FMEA/FTA故障分析，到需求追溯、安全验证、评审记录，标准每一条要求都对应明确的交付物文档。审核员的核心工作就是核对文档的完整性、追溯性和一致性，很难穿透到真实的开发过程深处核验。

这种规则本意是倒逼过程落地，但实操中极易反向异化：企业把“产出合格文档”当成了目标，而非“落地安全工程”的副产品。只要文档模板对齐标准、追溯关系闭环、签字齐全，就能通过认证；至于文档和实际工程是否一致，审核层面很难深度核查。

二、量产倒逼认证后置，文档反向补

这是行业最普遍的成因：功能安全介入严重晚于开发进度。

正常流程是概念阶段就定ASIL等级、拆解安全目标，再逐层分解到软硬件设计。但国内大量项目是「硬件已打样、代码已写完、临近SOP量产」，才想起要满足车企的功能安全准入要求。

此时不可能推翻重来走全流程，只能做反向文档工程：按照标准模板倒推安全需求、补FMEA分析、补需求追溯矩阵、补故障注入测试报告，把已经做完的产品，逆向“包装”成符合ISO 26262流程的产出。这类项目里，功能安全团队不参与开发决策，只负责“补文档、凑证据、过审核”。

这也恰恰是标准明确反对的做法：安全活动必须嵌入每个生命周期阶段、实时影响设计决策；架构冻结后再补的安全文档，无法证明安全曾被纳入设计考量。

三、企业把功能安全当“准入门票”

多数中小供应商甚至部分车企，对功能安全的定位就是供应链准入门槛——是“为了拿订单不得不花的合规成本”，目标是「最快、最便宜拿证」，而非真正提升产品的故障容错能力。

这种导向下，“补文档拿证”自然是性价比最高的路径：

真落地全流程功能安全，人力、周期成本是补文档的5~10倍；

补文档只需要23个月就能凑齐全套交付物，成本仅为真做的1/51/3。

对很多企业来说，“能过审核、能供货”就够了，安全工程本身是额外支出。

四、第三方咨询的“文档工业化”

国内绝大多数功能安全咨询公司都建立了标准化文档模板库：从安全计划、HARA、FMEA、FTA，到软件安全需求、追溯矩阵、验证报告，全套可套用模板，仅需替换项目参数、器件型号就能快速生成整套交付物。

这种“文档工厂”模式进一步弱化了功能安全的工程属性，也让很多从业者形成了「功能安全就是整理文档」的刻板印象。

写在最后

行业真实状态从来不是非黑即白：

核心安全系统（动力、制动、转向、智驾域控）：多数是「真做工程+补美化文档」结合，核心安全机制实际落地，文档做标准化对齐以通过认证；

非核心系统（车身域、小控制器）：大量纯“补文档”项目，工程完全不做安全设计，仅靠文档套模板过审。

本质上，文档只是功能安全的产出记录，不是功能安全本身。

补文档模式能过认证，但解决不了真实的系统性失效和随机硬件失效风险——这也是行业里会出现“过了ASIL D认证依然出功能安全问题”的核心原因。

以上个人观点，仅供参考讨论！