4. 确认与审核的区别

在 ISO 26262 的工程实践中，确认（Confirmation）与审核（Audit）是两类经常被混用的独立活动。它们都服务于功能安全的“独立评价”，但出发点、评价对象、执行时机与责任角色存在本质差异。理解这种差异，是构建功能安全确认与审核体系的第一步，也是避免“用审核代替确认”或“用确认覆盖审核”这类典型错误的根本前提。

一、定义与目标：结果导向 vs 过程导向

根据 ISO 26262-2 的定义，功能安全确认（Functional Safety Confirmation）是通过一系列确认措施（Confirmation Measures），对功能安全相关的输出物进行独立评价，以判断其是否满足功能安全要求。确认的目标是回答“安全目标是否被真正实现”，其评价对象包括安全计划、安全案例、危害分析与风险评估（HARA）、安全需求、安全机制、验证与测试结果等。

功能安全审核（Functional Safety Audit）则是通过独立检查，判断功能安全活动是否按照适用的标准、组织流程和项目安全计划执行。审核的目标是回答“过程是否被正确执行、证据是否完整可追溯”，其评价对象是过程执行的一致性、计划符合性和文档完整性。

因此，确认关注“做出来的东西对不对”，审核关注“做事的方式对不对”。确认偏技术判断，审核偏过程判断；确认需要深入技术细节，审核需要覆盖流程节点。

二、输入输出与执行时机

确认与审核的输入输出差异明显。确认的输入通常是安全需求、安全分析结果、验证报告、测试用例与测试结果、安全案例等；输出是确认报告（Confirmation Report），其中包含确认结论、发现的问题、风险等级与整改建议。审核的输入是安全计划、组织流程文件、工作产品清单、评审记录、配置管理记录等；输出是审核报告（Audit Report），包含符合性结论、不符合项、观察项与改进建议。

执行时机上，审核通常贯穿项目全生命周期，在安全计划发布后、关键里程碑前、阶段评审时均可执行，属于“过程伴随式”活动；确认则集中在关键节点，如安全需求冻结后、安全机制实现后、安全案例发布前，属于“结果评价式”活动。审核可以多次进行，确认通常按确认措施计划在特定节点执行一次或有限次数。

三、责任角色：谁来做确认，谁来做审核

ISO 26262 对确认与审核的责任角色有明确要求，核心原则是独立性与能力匹配。

• 确认责任角色：通常由功能安全经理（Functional Safety Manager）组织，由独立于开发团队的确认人员（Confirmation Reviewer）执行。确认人员应具备功能安全技术能力，且不得是所确认工作产品的直接作者。对于 ASIL D 项目，确认人员需具备更高的独立性和经验要求。
• 审核责任角色：通常由质量保证（QA）或功能安全审核员（Functional Safety Auditor）执行。审核员应独立于被审核项目，熟悉 ISO 26262 标准条款和组织流程，但不一定需要深入具体技术实现细节。
• 共同要求：两者都需具备相应的功能安全培训与资质，且其独立性应在安全计划中明确记录。

四、对比清单与典型误区

五、案例场景：ASIL D 项目的确认与审核协同

某 ASIL D 电子制动控制器项目在安全需求冻结后，功能安全经理组织确认人员对安全需求与 HARA 的一致性进行确认，发现一条安全机制的需求描述与 FTTI 计算不匹配，确认报告将其列为高风险问题。与此同时，审核员在阶段评审前对安全计划执行情况进行审核，发现配置管理记录中缺少部分工作产品的版本基线，审核报告将其列为不符合项。两类发现项分别从技术结果与过程执行两个维度暴露了项目风险，最终在安全案例中统一闭环。这个案例说明：确认与审核不是二选一，而是互补的双轨机制。

总结来看，确认与审核在 ISO 26262 中承担不同但互补的独立评价职责。确认回答“安全目标是否实现”，审核回答“过程是否合规”。只有将两者在安全计划中明确区分、协同执行，才能构建完整的功能安全确认与审核体系，为安全案例提供充分且可信的证据支撑。