ISO 26262功能安全标准体系解读（下）

在 ISO 26262功能安全标准体系解读（上）中，我们已经了解了功能安全的基本概念、发展历程和ISO 26262标准的概述，以及如何评估安全完整性等级（ASIL）。接下来，我们将继续深入探讨如何通过危害分析和风险评估确定系统或功能的安全目标和ASIL等级，以及在不同开发阶段如何执行安全需求的继承、系统设计、硬件和软件开发等方面的具体步骤。

一、安全目标与需求继承

确定安全目标是系统安全设计的第一步，它描述了所需实现的系统安全目标，并选择相应的实现方法。通过危险分析和风险评估，我们为每一个风险确定ASIL等级，安全目标是为了防止在特定驾驶状态下发生危险事件而设定的功能需求。安全目标与功能安全需求之间存在分层关系，安全需求继承自安全目标的ASIL等级。

二、功能安全需求设定

为了满足安全目标，我们需要在功能安全概念中规定项目的功能安全需求。功能安全概念旨在确定实现安全目标所需的功能安全要求，并将这些要求分配到设计架构或外部减少危险措施中。功能安全需求是一种安全措施，旨在减少有害影响，并且不需要依赖于项目安全行为规范和实施。

三、技术安全需求与系统设计

根据功能安全需求，我们需要将这些需求细化为系统级的技术安全需求。系统设计阶段需要按照定义的技术安全要求，设计出符合系统规范的方法。这包括考虑安全需求和非安全需求（ASIL等级表中的“QM”要求），同时保证设计的可验证性、功能安全的技术能力以及系统集成期间的测试可行性。

四、硬件安全需求与开发

硬件安全需求基于分配给硬件的技术安全要求，用于确保控制器内部硬件故障的安全机制。ISO 26262要求在硬件设计中评估硬件架构指标、偶发硬件故障的随机失效率。这些评估有助于确保硬件架构对偶然故障的鲁棒性，并评估安全机制的有效性。

五、软件安全需求规范与开发

软件安全需求根据因故障引起的技术安全要求偏离进行规范。设计软件时，需要考虑系统和硬件配置、接口、安全性约束、车辆与系统交互、受软件影响的车辆和硬件动作模式等因素。软件安全需求必须验证与技术安全概念、系统规范和接口规范的一致性。

六、验证与确认

验证阶段涉及确认产品开发的正确性，包括完成与ASIL等级相对应的验证过程。确认阶段则通过提供客观证据来认定特定预期用途或应用要求已得到满足，通常通过试验来确认成果物是否符合要求。

七、软件工具认证

为了确保软件开发过程的可靠性，ISO 26262设定了软件工具的可靠性评估指标。工具的认证过程包括评估工具对安全功能的影响、诊断能力以及生成置信等级。根据TI、TD和TCL的评估结果，可确定工具的使用级别。

八、故障传播的防止与软件隔离

在软件组件发生故障时，ISO 26262推荐使用软件隔离技术防止对其他组件造成不良影响。通过软件分区技术，可以将不同ASIL等级的软件组件分配到不同的资源上，以避免浪费开发成本或使用不可信的数据。

九、流程改进

ISO 26262要求流程改进以确保功能安全活动的实施状态。建议至少通过CMMI Level 2和Automotive SPICE Level 3认证，以满足安全开发流程的要求。

ISO 26262标准的实施将带来显著的安全效益，减少交通事故和召回风险，但对于汽车企业及供应商而言，将面临着在安全文化、工作流程、产品设计与开发等方面的持续改进挑战。随着标准的逐渐推广，功能安全工程师的需求将持续增长，培养专业的功能安全人才变得尤为重要。