ISO 26262标准应用（二）

除了正常的设计流程外，安全生命周期的设计阶段还包括重要的安全分析步骤。这些分析有助于在设计中加入安全机制并确保符合ISO 26262标准。安全分析方法包括定性和定量方法。分析包括归纳和演绎分析、FMEA、FMEDA和FTA，如下所述。

图3：FPGA设计流程

在关键安全应用的FPGA设计阶段，安全分析可以确保不会因模块故障而违反安全目标。在ISO 26262功能安全标准中，有两种安全分析方法——演绎法和归纳法。演绎分析是一种自上而下的安全分析方法。一种常见的自上而下的分析方法是FTA——故障树分析。归纳分析是一种自下而上的分析方法，常用的一种类型是是失效模式和影响分析（FMEA）。

假设设计包括了软核或者硬核CPU模块。在这种情况下，软件和硬件开发都必须遵循安全生命周期。ISO 26262标准的第5章适用于硬件（FPGA开发），第6章适用于嵌入式软件开发。

图4：将FPGA设计分为硬件和软件部分

故障模式和影响分析是系统的定性安全分析，用于识别潜在的故障模式并使用合适的安全机制解决故障。根据每个模块提供的功能将FPGA设计架构分解为简单的模块。审查现有文档和数据以确定每个模块可能发生故障的方式。

图5：FMEA流程

模块发生故障可能由各种原因导致。随机硬件故障（例如晶体管故障）可能会导致模块故障。例如，若出现“错误！未找到参考源”，随机硬件故障可能导致时钟生成功能或复位功能故障。

分析故障的影响，从而了解局部和系统层面的风险。最后，需要根据故障的影响设置安全机制。

FPGA UART模块的FMEA如表1所示：

表1：FPGA模块的FMEA

在枚举完影响局部和系统的所有故障之后，需要进一步分析设计，检查安全机制是否到位，确保检测故障和从故障恢复。在基于FPGA的设计中，安全机制可以实现为智能错误检测和纠正方法。

系统中的软件组件也进行了类似的FMEA分析。对每个软件的功能进行分析，从而识别故障模式并创建安全机制/诊断来检测这些故障，让系统在发生任何故障时转换到安全状态。

当系统中使用第三方组件时，设计人员有责任确保对使用的所有组件功能进行安全违规分析，并且在发生故障时可以在系统层面启用安全机制/诊断。可以根据流程失效模式和影响分析团队提出的改进，重新评估FPGA架构设计。重新评估每个潜在故障。一旦进行了改进，就可以反复改进和重新分析架构，降低不可避免的故障带来的影响。凭借其可重新编程、使用周期长和高处理带宽等特性，FPGA架构可以实现定制化设计，以满足汽车项目各个阶段的安全需求。

1、冗余

三模冗余（TMR）

双备份比较（DWC）

图6：三模冗余

TMR使用投票机制来识别哪个模块发生故障并启用错误检测和恢复功能。然而，这种方法的缺点就是会增加门数。在某些情况下，使用双备份比较方案（DWC）可能就足够了，该方案有助于故障检测（但不能从故障中恢复），如图7所示。

图 7：双备份比较方案

通过提供在双核锁步模式下运行的CPU，可以实现基于冗余的安全机制（图8）。

图 8：双核锁步

2、错误校正方法

这些方法通过让系统进入安全状态来确保系统在发生故障时可以持续运行。例如针对嵌入式RAM中的存储器故障使用ECC进行单比特纠错（SEC）。

3、诊断和错误检测方法

错误检测逻辑可以在硬件中实现，可以将故障通知给系统控制器，以便采取进一步措施过渡到安全状态。例如：

• 检测到数据完整性错误

• 时钟生成逻辑错误

• 接口信号时序错误

• 通过ECC进行2位存储器错误检测

  
  

可以通过在状态寄存器中设置错误位来表示这些错误，从而让整个系统或主机重置，丢弃错误数据包。

• 错误检测和诊断也可以通过软件实现，例如

• 定期检查重要的控制寄存器

• 诊断外部设备，如板载传感器或物理层组件（如以太网PHY设备）

• 启动时对软件和配置分区进行CRC验证

在进行诊断，尤其是在软件中实现的诊断时，设计人员必须确保满足系统级参数，例如故障容错时间间隔（FTTI）。

在设计、开发和制造过程中可能由于规范或实施的错误导致系统性故障。

质量控制——这可能包括通过测试或检查消除潜在故障。检查的有效性必须与可能对消费者造成隐患的严重程度相匹配。可以使用各种验证和错误注入工具实现充分测试，例如HDL模拟器、故障模拟器和静态代码分析工具。下文描述了工具选择的过程。

另一种定性的安全分析方法是故障树分析（FTA）。FTA是一种演绎法，涉及从顶事件（违反安全目标）到底事件（根本原因）的逻辑分解。归纳法和演绎法是互补关系，如ISO 26262-5: 2018 7.4.3.1表2所述：“分析的详细程度与设计的详细程度对等。在某些情况下，这两种方法都可以在不同详细程度的分析中开展。”

故障树的构建是通过为分析添加顶事件、安全目标或安全要求实现的。然后对顶事件进行分析，将其拆分为潜在的故障事件，这里硬件架构被视为输入。最后，对可能导致顶事件失效的故障进行根本原因分析。如图9所示，基本事件被添加到系统元素的抽象层，故障树是在系统层面绘制。

图9：Isograph工具中的故障树

在硬件层面的FTA中，这些基本事件将根据安全设计的要求被扩展到硬件中最低的抽象层或硬件模块层。为了得出每个基本层故障事件概率的定量数值，需要确定每个事件的故障率。详细描述见下文。

一个典型的条目（item）层面的方法（根据ISO 26262:10, B.2）是使用FTA来分析安全目标的违反情况，并识别组件（component）级别的危险事件。然后使用FMEA自下而上地分析硬件模块的故障模式。这样，可以将FTA和FMEA结合起来，在条目级别上平衡自上而下和自下而上两种安全分析（图10）。

图10：FTA与FMEA结合的示例

通常还进行相关失效分析（DFA）以降低常见原因和级联故障引发的安全风险。共享资源的随机硬件故障导致的相关失效包括时钟元件、电源元件或通用复位逻辑故障。随机物理根源引起的相关失效包括短路、闩锁和串扰。

相关失效的常见应对方法包括：

更多安全分析方法介绍之定量分析见标准应用第三篇。