译文《汽车应用的功能安全方法论》

ISO 26262: 道路车辆 – 功能安全是汽车行业标准，派生于更通用的 IEC 61508 功能安全标准 (IEC), 针对总重不超过3500公斤、配备一个或多个电子电气（E/E）子系统的批量生产的乘用车，为其安全相关系统所设计 (Beckers)。

ISO 26262对功能安全的定义为：“不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险“。

这个定义可以表示为一连串的影响，如图1所示。

根据 ISO 26262，电子电气组件的故障分为两种类型的失效：

•系统性失效：这类故障是表示在开发、制造或维护（流程问题）期间以确定性方式引起的相关项/功能故障。这些故障——通常是由流程原因引起的——可以通过设计的转变或制造过程、操作程序、文档或其他相关因素的更改来解决。典型的需求是可跟踪和可追溯性。所有这些方法和期望都包含在ISO 26262-2:2011 报告的功能安全管理活动中。

•随机失效：随机硬件失效出现在一个硬件元件的生命周期内，源于工艺或使用条件的随机缺陷。硬件随机故障可以进一步分为永久性故障（例如，卡滞故障）和瞬态故障（例如，单粒子翻转或软错误）。

在硬件/软件系统的设计和验证过程中，通过引入安全机制来处理随机故障，使得架构能够检测和纠正故障。

ISO 26262:1-2011词汇表所述, 安全机制是指为了探测故障或者控制故障，以达到/保持某种安全状态的目的, 由电气/电子系统的功能/要素或者其他技术来实施的技术解决方案。

安全机制的例子包括:

–纠错码 (ECC)

–循环冗余校验 (CRC)

–硬件冗余

–内建自测试 (BIST)

检测这些随机故障的解决方案的有效性由三个指标来衡量，以检测故障和故障时间（FIT），以及风险的总体可能性:

–单点故障度量 (SPFM)

–潜伏故障度量 (LFM)

–随机硬件失效概率度量 (PMHF)

根据 ISO 26262，这三个指标基本上是硬件组件功能安全的度量标准，本文接下来的部分主要关注如何分析它们并满足其目标值。

定义硬件架构指标的描述和公式在ISO 26262-5:2011，附件D，C.2和C.3以及9.2中有报告:

•单点故障度量(SPFM)：这个度量反映了相关项、功能通过设计手段或通过安全机制覆盖,实现的对单点故障的鲁棒性；

•潜伏故障度量(LFM)：这个度量反映了相关项/功能通过设计手段（主要为安全故障）、通过安全机制覆盖、或通过驾驶员在安全目标违背之前识别，实现对潜伏故障的鲁棒性；

•随机硬件失效概率度量(PMHF)：由于随机硬件故障而导致违反安全目标的剩余风险足够低，该度量标准为这一理论提供了依据 (Chang)。

从直观的角度来看，单点故障可以直接导致违反安全目标，而潜伏故障则是未被发现的故障，这种故障允许另一个故障造成危害。

在整车层面，如果已知的功能出现故障（例如，防抱死制动系统），就会进行危害和风险分析，以确定人身伤害和财产损害的风险。该分析基于危险事件的暴露程度、严重程度和可控性以及由此产生的风险，并确定汽车安全完整性等级（ASIL），即为达到可承受的风险所需的风险降低水平。图2给出了根据故障及其潜在影响确定ASIL的步骤的一个例子。ASIL A是最轻微的危险，而ASIL D是最严重的。

对于硬件组件，ASIL 要求决定了故障指标要达到值，如表 1 所示。为了解决系统性故障，ASIL也将设定严格的流程合规性（如可追溯性，制程质量，文档）。

功能安全生命周期和开发阶段s

ISO 26262 标准定义并记录了功能安全生命周期的所有阶段。

图3a说明了概念阶段和开发阶段的顺序，而图3b和图3c则展示了相应的功能安全活动和示例。概念阶段由汽车制造商拥有，并定义了在整车层面实现功能的系统（在ISO 26262术语中称为相关项，例如，自动紧急制动（AEB）系统）。ASIL是在这个层面上确定的，安全目标和功能安全要求是由它定义的。 对于每个功能安全要求，当系统级产品开发阶段开始时，技术安全要求是针对安全相关功能的硬件和软件组件推导得出的。

基本上，安全目标从车辆层面开始，在开发链中被映射和完善，直到硬件失效度量被定义并分配给各个硬件子系统。

FMEDA 是一种结构化方案，用于定义硬件组件的失效模式、失效率和诊断能力。

根据组件功能，FMEDA 层次结构分为元器件/子元器件/基础子元器件（取决于详细程度）/失效模式（ISO 26262：道路车辆 – 功能安全）。对每种失效模式根据其是否影响安全目标进行分类。

对于已被定义并影响安全目标的每种故障模式，基本需要的输入包括：

– 失效率(FR)：组件出现故障的比率，即可靠性

– 安全机制(SM)：即是否存在安全机制，用以检测失效模式

– 诊断覆盖率 (DC)：即安全机制在检测故障方面的有效性

评估功能安全准备程度的输出是硬件架构度量单点故障度量（SPFM）、潜伏故障度量（LFM）和随机失效概率度量（PHFM）。

直观地说，这些度量反映了组件的可靠性（换句话说，它发生故障的可能性有多大），也反映了安全机制在探测失效并使系统进入安全状态方面的可靠性。

失效率是衡量一个组件可靠性的标准，它以FIT表示。一个组件的FIT率是指，在10亿小时的运行中预计出现的故障数量。换句话说，如果一个设备的FIT率等于1，则该设备的平均失效间隔（MTTF）为10亿小时（ISO 26262：道路车辆 – 功能安全）。

根据ISO 26262，硬件部件的预计失效率应通过以下三种方法之一确定：

–通过应用行业可靠性数据手册来估算(如, IEC 61709, IEC TR 62380)

–由现场事故观测得出，例如，对于作为现场失效返回的材料分析

–从实验测试中得出

表2展示了一个简化的FMEDA表格。如表中所示，对于每个失效模式，结合FR、SM和DC，计算出SPFM、LFM和FIT率。总失效是对所有行进行求和得到的。通过分析总失效和逐行对其的贡献，FMEDA指导设计者为了安全准备需要加强设计的哪些部分。

在表2的实例中，FMEDA是针对永久性故障进行的。也可以用类似的方式建立对瞬态故障的分析。

尽管到目前为止描述的硬件架构指标不包括时序约束，但不难理解，安全机制的完整评估应当涉及时序性能。事实上，系统必须能够在特定的时间（容错时间间隔FTTI）内探测到故障并转至安全状态；否则，故障会成为系统级危害。这在图4中得到体现，图中还说明了诊断测试间隔（DTI），即FTTI中分配给探测测故障的部分（ISO 26262: 道路车辆- 功能安全）。作为一个参考例子，当整个系统分配给FTTI的时间是100ms左右时， 一个CPU中的故障检测的DTI可能是大约10ms。

与硬件随机故障分析一起，特别是当系统有共享资源时，需要评估的另外一个方面，是相关失效分析（DFA)。

相关失效分析–也被称为给定要素之间可能的共因失效和级联失效的分析–旨在识别可能绕过给定要素之间所需的独立性或免于干扰的单一原因，这种单一原因可能违反安全要求或安全目标（ISO 26262：道路车辆-功能安全）。

与架构特性相关的两个最直观的场景如下：

– 相似的和不相似的冗余要素

– 由相同的软件或硬件要素实现的不同功能

ISO 26262提供了一系列可评估的相关失效引发源，并提供了控制或减轻此类故障的安全措施指南。

由于共享资源的随机硬件失效导致的相关失效引发源有，例如时钟要素失效、电源要素失效或共用复位逻辑失效。随机物理性根本原因有关的相关失效引发源包括短路、闩锁和串扰等。

根据ISO 26262，针对随机物理性根本原因的典型对策包括：

–对共享资源的专用独立监控（例如，时钟监控）

–启动时的进行自检（例如，安全机制启用检查）

–影响的多样化 （例如，主核和检测核之间的时钟延迟）

–使用特殊传感器进行间接监控（例如用作共因失效传感器的延迟线）

–故障避免措施（例如物理分离/隔离）

在设计流程中，已经实现自动化的安全机制的最显著的一个例子是内建自测试（BIST），其用于汽车内系统/现场测试的寿命可靠性，以实现所需ASIL。

用于测试随机逻辑的BIST技术一般有两类（Wang）。它们对安全度量有不同的影响，需要不同的时间性能：

• 在线BIST：这个测试是在功能电路处于正常运行模式（任务模式）时进行的。它有利于SPFM度量，并有更严格的时间要求，因为它必须在DTI时间内完成。

• 离线BIST：这种测试是在功能电路在非正常模式下进行的，例如，在发动机启动时的上电复位过程中。它有助于LFM，而且时间要求也比较宽松。

在BIST集成过程中需要面临的挑战是速度测试能力、功耗、面积、路由最小化和ASIL目标（Wang）。压缩技术的集成提供了高质量和高效率的资源共享（Pateras）。

虽然是相关联的，但在BIST插入期间，预估的测试覆盖率并不完全等于ISO 26262度量所要求的诊断覆盖率（DC)；可能需要功能安全验证来准确测量DC值。参考图5中举例的AEB系统，BIST可以用来避免CPU缓存中的累积故障（复杂微处理器中的典型问题）。

安全机制的另一个例子是三模冗余技术（TMR）。在这种情况下，对单粒子翻转事件敏感的逻辑（存储单元）有三个，表决系统被放置在输出端以识别正确的值（Ruano）。图6显示了应用于触发器层面的TMR架构：该技术涵盖了三套顺序要素的SPFM和LFM。

当安全架构是基于硬件冗余时，就需要执行DFA来解决由于随机物理性根本原因导致的共因失效:本质上就是逻辑性独立需要转化为物理性独立。

另一个基于冗余的安全机制是双核锁步（DCLS），在表2中也提到过。共享资源（如电源、时钟、复位信号）和单一的物理性根本原因都必须被视为潜在的失效，需要特殊的设计技术来保持较高的可实现的诊断覆盖率。

图7报告了在功能层面解决共因失效的对策实例，如时序多样性和输出反转。它还展示了避免交叉通讯或保证冗余块之间强隔离的布局技术（例如，环形屏障）。为了确保物理性独立，实施了几个位置和路由约束，例如，同值寄存器的间距和电源域路由的安全着色。

图8显示了使用Cadence®Innovus™实现系统，在有和没有功能性安全路由约束的情况下实现的一个设计示例：左下角区域是一个模块的主副本，而右上角区域是为冗余而插入的副本。通过保证属于主模块的导线永远不进入右上角区域，实现冗余模块在结构上是物理性独立的，并能满足DFA的要求。

当设置初始的FMEDA为评估IP/片上系统SoC的安全准备时，可以根据ISO 26262:2011-5附件D，表D3到D9中定义的可实现的值（低、中、高）,来估计安全机制的诊断覆盖率（DC)。

对于一些标准的安全机制（如ECC），DC值可以通过分析计算。这种计算只在逻辑的某些部分是准确的；例如，对错误探测纠错码（ECC），诊断覆盖率（DC）在数据单元上是准确的，但对于存储器前面的解码器却不是。在这种情况下，有一个变化区间，对于高水平的ASIL目标（ASIL-D）来说这种变化区间可能是不可接受的，需要通过故障注入对诊断覆盖率（DC）值进行更精确的调查。

在定制硬件或软件安全机制（标准测试库，或STL）的情况下，故障注入仿真是一种技术，可用于更准确地验证DC值。它也可以用来评估探测时间和故障响应时间（见表2），或确认故障影响。

功能安全验证从是标准的功能验证设置开始进行的。用以评估安全机制DC值的故障注入活动，其主要需求是描述执行观察点的工作负荷–即在哪里观察故障的影响，以及探测点–即在哪里观察安全机制的反应。

参照图7，观察点放在CPU主控器的主输出上，而检测点则放在比较器的报警器上。故障被观察到及至故障被探测到的时间延迟决定了诊断测试间隔（DTI)。

故障可以根据对观察点和诊断点的影响进行分类：

– 检测到危险：在观察点和诊断点上都可以看到故障的影响。 这意味着功能输出受注入故障的影响，但安全机制已检测到它。

– 未检测到的危险：在观察点上可以看到对故障的影响，但在检测点上看不到。 换句话说，故障会影响功能输出，而安全机制尚未检测到它。

– 安全：故障不影响观察点：需要注意的是，只有当工作负载为功能验证提供良好的覆盖范围时，故障才能被归类为安全的。

当建立一个故障注入活动时，决定在哪里注入故障是至关重要的。事实上，在评估中的安全机制是针对电路特定的失效模式的；故障应该只注入属于相关失效模式的逻辑中。

作为解决系统性错误的功能安全管理的一部分，用于开发安全关键型应用的工具需要评估其置信水平。工具置信水平（TCL）量化了软件工具中的失效可以被检测出来的保证，这与适用于硬件组件的原则非常相似。工具可信水平等级包括TCL1、TCL2和TCL3，其中TCL1是最高的；被归类为TCL1的工具不需要额外的资格认证，可以用于开发任何ASIL等级的应用。TCL的确定是基于ISO 26262-8:2011中总结的标准。

表3：它包括了评估这些工具对安全应用的潜在影响和工具的错误探测能力。有关软件工具符合性的信息， 是为满足ISO 26262功能安全要求而开发的产品安全包的一部分。

SASETECH组织致力于推动功能安全、系统安全、网络安全、预期功能安全的业内交流和技术进步，打造全新智能网联汽车安全生态圈。欢迎加入！