Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 26262-2:2018 道路车辆——功能安全——第2部分：功能安全管理
汽车功能安全管理框架——安全文化、确认措施、安全案例与生产放行
一、功能安全管理在汽车生命周期中的核心地位
ISO 26262-2:2018 确立了贯穿汽车E/E系统整个安全生命周期的功能安全管理要求。作为ISO 26262系列的管理基石，本标准定义了确保功能安全得以系统化实现和维持的组织职责、规划活动和确认措施。第二版在2011版基础上进行了重大演进，引入了更详细的目标、对安全文化的更强强调、明确的安全异常管理以及与网络安全的整合。
该标准适用于参与道路车辆（包括乘用车、卡车、客车、挂车和摩托车）安全相关E/E系统开发、生产、运行、服务和退役的所有组织。安全管理分为三大类别：总体安全管理（项目独立）、项目依赖的安全管理以及有关生产、运行、服务和退役的安全管理。
组织应在开始任何项目特定的功能安全工作之前建立明确的安全管理框架。第5条定义的独立于项目的安全管理活动为所有项目特定活动提供了必要的基础。
| 管理类别 | 关键要求 | 工作成果 |
|---|---|---|
| 总体安全管理（第5条） | 安全文化、能力管理、QMS、异常管理、生命周期剪裁 | 安全文化方针、能力登记册、剪裁后安全生命周期 |
| 项目依赖管理（第6条） | 角色与职责、影响分析、计划、安全案例、确认措施 | 安全计划、安全案例、确认措施报告、生产放行报告 |
| 生产/运行/服务管理（第7条） | 生产安全规划、服务说明、退役 | 生产安全计划、服务文档、退役概念 |
二、安全文化与能力管理
2018版的一个关键新增内容是对组织内部安全文化的明确要求。第5.4.2条要求组织建立、实施和维护支持功能安全实现的安全文化。这包括管理层的承诺、关于安全问题的开放沟通，以及鼓励员工报告安全问题而不必担心报复的”公正文化”。
安全文化不能仅通过文档来建立。它需要领导层切实的承诺、定期的安全沟通以及根据安全发现采取行动的记录。评估员会通过访谈员工和审查会议记录来验证安全文化，而不仅仅是检查方针文件。
能力管理（第5.4.4条）要求所有参与功能安全活动的人员具备与其分配角色相适应的教育、培训和经验。标准不要求特定的认证，但要求能力记录得到维护。这包括对每位角色相关具体功能安全要求的基本认识。
质量管理体系集成（第5.4.5条）是另一项关键要求。组织必须证明其质量管理体系（如ISO 9001或IATF 16949）能够支持功能安全活动。质量管理体系为功能安全所必需的配置管理、变更管理、文件控制和供应商管理提供了基础。
三、项目依赖管理与确认措施
项目依赖的安全管理（第6条）针对每个开发项目的具体安全活动。安全经理必须被任命并具有明确的职责和权限。安全计划必须定义所有安全活动及其时间和分配资源。标准要求安全案例在项目全程逐步建立，最终以生产放行决策作为终点。
实践洞察：以增量方式构建安全案例，而非作为项目末期的收尾工作。每个开发里程碑都应生成为安全案例提供支持的证据。这种方法可以及早发现差距，避免在发布前匆忙寻找证据的常见问题。
确认措施（第6.4.9条）是ISO 26262-2独立监督方法的基石。定义了三种类型的确认措施：确认评审、功能安全审计和功能安全评估。执行这些措施的人员的独立性必须与被评估项目的ASIL相适应，从ASIL A/B的独立人员到ASIL D的独立部门或组织。
一个常被忽视的关键要求：确认措施的独立性级别由项目的最高ASIL决定，而非分解后的ASIL。务必根据ISO 26262-2表1确认正确的独立性要求。
影响分析（第6.4.3条）在对现有项目进行变更时需要执行。分析必须评估变更对安全要求、架构和假设的影响。对于现有要素的复用（第6.4.4条），标准要求进行专项分析，以证明该要素在新环境中适用于其预期用途，考虑其运行历史和安全案例的完整性。
常见问题解答
问1：谁可以执行确认措施？
独立性要求因ASIL而异。对于ASIL A和B，同团队的独立人员即可。对于ASIL C，需要来自不同团队的独立人员。对于ASIL D，需要独立部门或组织。关键是执行确认措施的人员不得参与被评审的活动。
独立性要求因ASIL而异。对于ASIL A和B，同团队的独立人员即可。对于ASIL C，需要来自不同团队的独立人员。对于ASIL D，需要独立部门或组织。关键是执行确认措施的人员不得参与被评审的活动。
问2：安全审计和安全评估有何区别？
功能安全审计（第6.4.11条）检查流程——即计划的安全活动是否得到遵循。功能安全评估（第6.4.12条）检查产品——即项目是否实现了其功能安全目标。ASIL C和D两者都需要；ASIL A和B仅需确认评审。
功能安全审计（第6.4.11条）检查流程——即计划的安全活动是否得到遵循。功能安全评估（第6.4.12条）检查产品——即项目是否实现了其功能安全目标。ASIL C和D两者都需要；ASIL A和B仅需确认评审。
问3：安全异常应如何管理？
安全异常（偏离预期安全行为的情况）必须被系统性地捕获、分析和解决。流程包括：识别、按严重度分类、根本原因分析、制定纠正措施、有效性验证和关闭。安全异常必须与一般质量问题分开跟踪。
安全异常（偏离预期安全行为的情况）必须被系统性地捕获、分析和解决。流程包括：识别、按严重度分类、根本原因分析、制定纠正措施、有效性验证和关闭。安全异常必须与一般质量问题分开跟踪。
问4：什么情况下需要更新安全案例？
任何影响安全的变更——包括设计变更、需求变更、新危险识别、安全异常解决和假设变更——都应触发安全案例的更新。安全案例应被视为随项目演进的活文档。
任何影响安全的变更——包括设计变更、需求变更、新危险识别、安全异常解决和假设变更——都应触发安全案例的更新。安全案例应被视为随项目演进的活文档。
