最先进的软件测试库 (STL) 和 ASIL B：真理、神话和指导

1. 简介

功能安全在一系列市场中仍然至关重要，随着自动驾驶和相关服务成为现实，功能安全是决定其成功和广泛部署的关键因素。关键性越高，驾驶员对应用程序的控制越少，固有风险和相关的汽车安全完整性等级 (ASIL) 就越高。 ISO 26262 [1] 定义了四种 ASIL：

    1. ASIL A（最低完整性）

    2. ASIL B

    3. ASIL C

    4. ASIL D（最高完整性）

ASIL 根据安全目标和功能安全要求的定义在车辆级别确定。对于每个功能安全要求，技术安全要求被派生并分配给构成系统的各个硬件和软件组件。例如，为了保持更高的完整性，处理器等硬件组件必须通过其持续监控和报告能力（分配给 CPU 的技术安全要求）对随机硬件故障具有更高的覆盖率。
双核锁定步骤 (DCLS) 是一种常用于高覆盖率、持续监控和报告的方法。使用这种方法，主 CPU 和冗余 CPU 同步运行，并不断比较输出，以确保可以检测和报告在运行期间在其中一个处理器中发生并传播到输出的任何随机硬件故障。这种类型的系统价格昂贵，因为 CPU 面积大约翻了一番，但用于许多安全关键型应用，特别是那些必须满足 ISO 26262 汽车安全完整性等级 D (ASIL D) [1] 指导的应用。但是，对于驾驶员通常对车辆具有更多控制权的安全应用（例如，车道监控、自适应前照灯系统等），完整性要求往往较低（例如，ASIL B）。在这种情况下，经常使用自测试技术，例如软件测试库 (STL) [2]。
本文介绍了如何使用最先进的 STL 来实现关于硬件架构指标的 ISO 26262 ASIL B 完整性要求。在简要介绍了 STL 之后，讨论了它们与 ISO 26262 要求相关的优势和局限性。本文解决了以下问题：

    如果 STL 不满足 IP 级别的系统级 ASIL B 硬件架构指标目标怎么办？

    如果不满足这些目标，它们如何仍可用于 ASIL B 应用程序？

本文不关注如何避免 IP 或 IC 和 STL 的系统性故障，假设 IP 和 IC 提供商酌情负责。本文中的讨论也适用于 IEC 61508 标准的硬件架构度量目标。

本文组织如下：

    第 2 节介绍了 STL、它们的要求和原则。
    第 3 节描述了 ISO 26262 中定义的硬件架构指标和诊断覆盖率 (DC)，为本文的进一步讨论奠定了基础。它还以 STL for CPU 为例，定义了安全机制的范围和 DC 目标。

    第 4 节是关于目标硬件架构指标的 IP 和 IC 级别注意事项，包括：

        - 关于如何为单个硬件组件（例如，微控制器）和组成 IP 块（例如，CPU 内核）导出硬件架构指标目标的建议基于为目标 ASIL 分配或假定的硬件指标。
        - 基于目标 ASIL 和理由的推荐硬件架构指标和 DC 目标的可能例外情况。
    第 5 节涵盖了用于增强在 IP 或 IC 级别实现的硬件架构指标和 DC 的系统级注意事项和方法。接下来是一个示例，以演示使用本文中描述的技术在系统级增强 DC。
    第 6 节以对 IP 供应商和系统集成商的建议作为本文的结尾。

2. 软件测试库简介

STL 是一种基于软件的安全机制，可以成为汽车、工业和其他需要运行应用程序且必须展示功能安全性的市场的安全相关设计的重要组件1。 STL 用于测试永久性硬件故障，例如硬件功能逻辑内的卡在 0 或卡在 1 的测试，它应该被开发为脱离上下文的软件安全元素 (SW SEooC)。
开发 STL 时通常考虑的安全和功能要求如下：

安全

    达到技术安全概念要求的 STL 假定的 DC 目标，或 IP 提供商假定的 STL 的 DC 目标。
    报告故障信息，包括从测试到系统级应用程序的任何已识别故障。
    避免干扰应用软件。
    为受保护 IP 定义的诊断测试时间间隔 (DTTI) 内的执行时间。
    在运行时维护的 IP 的使用假设。

功能

    灵活的测试深度，可在特定时间点运行选择的测试和测试数量。
    能够通过选择不同的测试集来针对特定逻辑块进行测试。
    适应不同的IP配置。
    在一般总内存占用量的定义允许百分比内的代码大小。
    可重定位取决于系统内存映射。
    可中断，具有最大定义的延迟。
总的来说，STL 可以提供一种强大而重要的方法来实现对永久性故障的诊断覆盖，同时最大限度地减少对系统可用性的影响。
开发 STL 架构时要考虑的原则是：

1. 简化集成：

    调用 STL 的简单应用程序编程接口 (API) 的可用性。
    根据系统级技术安全概念，能够选择在可用时间预算内运行所需的特定部件和 STL 的部件数量。
    使客户能够执行自己的数字和故障模拟的功能。
2. 在任何特定时间根据所选配置和可用内存灵活选择测试。
3. 附加硬件应限制在增加诊断覆盖率所需的最低限度内。

3. 随机硬件故障和相关硬件架构指标的基本定义

3.1 硬件架构指标和诊断覆盖率 (DC)

一个项目中电气/电子系统的故障行为可能是由其一个或多个元素中发生的系统故障和随机硬件故障 (RHWF) 引起的。
对于随机硬件故障，ISO 26262 和其他功能安全标准定义了几个硬件架构指标 [1]，并为每个定义的完整性级别提供了推荐的目标值 [3]。必须实现硬件架构指标的这些目标，以确认安全相关系统可以在一定程度上应对 RHWF，而不会导致导致危险情况的危险系统故障。
ISO 26262 标准为此目的定义了一个绝对硬件架构度量（单位：故障时间 (FIT)）和两个相对硬件架构度量（单位：1 或 %）：

    随机硬件故障 (PMHF) 的概率度量：可能违反安全目标 (PVSG) 的不受控制的 RHWF 的绝对故障率。 （单位：h-1 或 FIT） [等式 5]

    单点故障度量 (SPFM)：1 – 不受控制的 PVSG 故障的比率，相对于系统或元件中所有与安全相关的 RHWF。 （单位：1 或 %）：[方程式 4]

    潜在故障度量 (LFM)：1 – 潜在双点故障 (DPFL) 的比率，相对于所有安全相关的 RHWF，但不受控制的 PVSG 故障除外。 （单位：1 或 %）

ISO 26262-5 §8.4.5、ISO 26262-5 §8.4.6 和 ISO 26262-5 §9.4.2.2 [3] 定义了三个硬件架构指标的 ASIL 相关目标值：PMHF、SPFM 和 LFM，如图所示表 1. 这些目标值是为系统级定义的，并且必须在系统级实现（例如，对于完整的制动或转向系统）。请注意，没有为 ASIL A 定义目标，并且 ASIL B 的目标值仅由 ISO 26262 标准推荐。尽管如此，系统开发人员仍经常要求并强制要求必须达到 ASIL B 目标值。

另一个相对度量通常用于描述安全机制检测和控制故障的有效性：

    诊断覆盖率 - 单位：1 或 % (DC)：故障率的百分比或由硬件元件检测和控制的故障模式安全机制[方程式3]。
安全机制的 DC 直接影响安全机制有效的元素的硬件架构指标 SPFM 和 PMHF。这在图 1 中得到了证明，它描述了一个硬件元素及其总故障率，也称为基本故障率 (Total)，其中一部分被假定为安全故障，其余部分为 PVSG4 故障。在本文中，我们只考虑安全故障和可能违反安全目标的故障。安全机制检测并控制一定比例的这些 PVSG 故障。公式 1-5 显示了如何定义不同的硬件架构指标，以及如何针对本示例计算它们。

3.2 定义安全机制的范围和诊断覆盖目标

当将安全机制指定为 IC 或 IP 安全概念的一部分时，除其他要求外，还应定义安全机制和 DC 目标的范围。对于范围定义，应考虑以下方面：

    安全机制应涵盖哪些硬件块？

    是否有任何子块预计不会被安全机制覆盖？

    硬件块的故障模式是什么？

    安全机制应该​​覆盖硬件块的所有故障模式，还是只覆盖选定的故障模式？

DC 目标应该为整个硬件块定义，或者为单独的故障模式单独定义。后者也称为故障模式覆盖 (FMC) 目标。在任何一种情况下，都应考虑以下方面：

    硬件块的 SPFM 目标是什么，基于其 ASIL 和第 4.1 节和第 4.2 节中描述的其他考虑因素？

    与 SPFM 目标相比，是否存在大量安全故障，从而降低了所需的 DC？

    是否有其他安全机制计划以正交或重叠的方式覆盖相同的块和故障模式，从而降低每个安全机制相对于 SPFM 目标所需的 DC？

    什么 DC 目标被认为是可以实现的？

如果没有可用的详细信息来支持更准确的 DC 规范，那么定义一个 DC 目标等于表 1 中的 ASIL 相关 SPFM 目标是合理的。换句话说，如果安全机制是为应用程序开发的 SEooC用例并不广为人知，可以假设 DC 目标等于表 1 中的 ASIL 相关 SPFM 目标。

3.2.1 CPU 的 STL：范围、诊断覆盖目标、高级架构和开发过程

3.2.1.1 CPU STL 的范围和 DC 目标

以 Arm CPU 内核的 STL 为例，范围和 DC 目标定义可能导致STL 的以下要求。 CPU 内核是作为硬件 SEooC 开发的，这些是假定的、软件分配的、技术安全要求：

    STL 应针对 CPU 内核中的所有永久性故障，非安全相关块除外。更详细的分析可以基于全套功能性 CPU 故障模式，或所有门级网表故障。 STL 不会涵盖瞬态故障。
    STL 应实现 90% DC 的 DC 目标（基于 CPU 内核的假定 ASIL B 用例）。
STL 是根据这些假设的要求和 DC 目标开发的。

3.2.1.2 STL 架构

STL 的高级架构5 如图 2 所示。该架构分为四个组件：

    简单 API

    调度程序

    块：表示处理器功能块（例如，核心、MPU 等）的逻辑部件组，以确保 STL 可根据 CPU 配置进行配置。
    部分：由受约束的随机测试生成器或针对特定逻辑编写的定向测试生成。受约束的随机测试侧重于特定功能，例如，DPU 部分没有 FPU 指令，因此即使没有 FPU 也可以执行它。这些测试是用汇编代码编写的，以实现高效执行并避免编译器优化可能发生在用 C 编写的代码上。

构建 Arm STL 架构的主要原则是“简单性”。有一个基于 C 的 API 用于调用库，然后将执行预定的测试。完成后，控制权将连同已执行测试的结果一起返回给库的调用者。如果测试导致失败，则会提供有关哪个测试失败及其可能原因的附加信息。
可以配置可以从单个 API 调用运行的测试数量，具体取决于可用的时间和内存。

3.2.1.3 STL 开发

STL 开发分为以下几个阶段：

1. 探索

在此阶段，探索对整个 SPFM 影响最大的 CPU 的安全相关区域，例如执行指令的单元。这有助于首先为对覆盖范围产生最大影响的单位实施刺激和检查，这可能间接地使其他较小的单位受益。
2. 测试编写

这个阶段包括在可能的情况下使用工具生成伪随机测试，例如，用于测试执行指令的单元。这是通过创建随机指令序列来完成的，例如为内存系统或中断控制器生成测试。此外，定向测试还用于打击某些难以到达的区域或随机测试无法到达的区域。
3. 故障模拟

故障模拟通常用于验证所编写测试的质量。这是由合格的故障模拟器完成的。构成 STL 的部件和块的质量基于所获得的 DC 进行验证。如果没有达到要求的 DC，IP 开发人员需要返回到第 2 步，直到达到覆盖目标。
4. 签核

签核总是通过在整个 CPU 上运行全套测试来完成，以证明达到了预期或目标覆盖率。
在 STL 开发的最后验证范围定义的实现，并测量或评估 STL 的实际 DC。实际的 DC 记录并报告给 CPU 内核的用户和集成商，以支持对集成 CPU 内核的 IC 和整个系统的定量分析。
通常，STL 实现的实际 DC 低于 ASIL B 用例的 SPFM 目标，即 IP 级别的 90%。这是由于理解 RTL 和网表之间的映射以生成目标测试所涉及的挑战。将深埋在逻辑中的故障传播到观察点的可控性的限制也促成了这一点。本文后面的部分有助于证明在 IP 级别低于定义的 SPFM 目标（如表 1 所示）是可以接受的，并且有一些方法可以在系统级别增强 SPFM。

4. IP 和 IC 级别考虑

4.1 基于 PMHF 和 SPFM 目标为单个硬件组件和组成 IP 块导出硬件度量目标

硬件架构度量目标值在系统级别定义，并且必须为整个硬件实现的一个系统。这就提出了一个问题，即如果一个人不开发一个完整的系统，而只开发一个 IC 或 IP（例如，它是系统中的一个组件或子部分），那么度量目标将是什么。不幸的是，ISO 26262 没有提供任何要求，也只提供了很少的关于这个主题的指导。由 IC 或 IP 的开发人员指定这些目标，例如，作为 SEooC 定义的一部分。
IC 或 IP 级度量目标值的规范应考虑以下指南：

1. SPFM：IC 或 IP 应根据目标 ASIL 采用系统级 SPFM 目标值。
2. LFM：IC 或 IP 应根据目标 ASIL 采用系统级 LFM 目标值。

3. IC 的 PMHF：对于 IC，我们建议假设 PMHF 目标是 ASIL 相关的整体系统级 PMHF 目标值的 1% 到 10%（如表 1 所示）。
    a. 预计将成为目标系统中最主要的单一硬件组件的复杂 IC 可以假定 PMHF 值接近上限（高达 10%）。例如，针对防抱死制动系统（ABS）、电池管理系统（BMS）、电动助力转向（EPS）等传统汽车系统的微控制器。
     b. 中等复杂性 IC 或预期与目标系统中的一个或多个其他类似复杂 IC 一起使用的复杂 IC 应假定 PMHF 目标处于中等范围（3% 至 5%）。例如，用于 SAE L3 或更高级别自动驾驶系统的复杂 CPU，预计将包括其他非常复杂的 ISP、DSP、ASIC 等。
    c. 简单的分立 IC 应假定 PMHF 目标朝向低端（即 1% 至 2%）。例如，传感器 IC、DRAM 存储器、PMIC。
4. IP 的 PMHF：不应为 IP 定义 PMHF 目标。
5. DC：IC/IP中的安全机制的DC没有通用的目标。

如果相关架构指标遵循指南 #1 和 #2，并且系统中的所有硬件组件都实现了系统级 SPFM 和 LFM 目标，那么整个系统也会自动实现这些相关指标目标。
指南#3 旨在解决 PMHF 预算的棘手问题。因为系统级 PMHF 目标必须适应系统中的所有硬件组件，所以没有单个 IC 或组件必须消耗太多 PMHF 目标的一部分，从而使所有其他组件的 PMHF 预算不足。基于经验和可行性考虑，建议分配 1% 到 10% 的份额（对于为 ASIL D 系统开发的 IC，在 0.1FIT 和 1FIT 之间）是一个合理的目标。定义的 IC PMHF 目标值包含来自硅芯片和封装的永久性故障以及瞬态故障，是一个假设的目标值，也是为 SEooC 定义的假设的一部分。这些假设必须由系统集成商验证和确认，以适合实现系统级 PMHF 目标。
如果 IP 是独立开发的，而不是在 IC 的上下文中开发，则应仅使用相关的硬件架构指标（SPFM 和 LFM），而不应针对该 IP 的 PMHF 值，如指南 #4 中所述。原因是确定独立 IP 的基本故障率并不常见，这将需要计算绝对指标。相反，通常情况下，基本故障率是针对完整 IC 确定的，然后分解为单个 IP。
最后，准则 #5 提醒您，ISO 26262 [3] 只要求实现三个硬件架构指标（PMHF、SPFM 和 LFM）。 ISO 26262 不包括为安全机制实现特定 DC 的任何要求。相反，具有安全机制的 IC 或 IP 安全概念及其各自的 DC 必须以能够在 IC 和系统级别实现硬件架构指标的方式进行指定。

4.2 IP 或 IC 级别推荐的硬件架构度量值和诊断覆盖率的可能例外情况

在本文的这一部分中，我们探讨了 SPFM、LFM 和 PMHF 目标值根据第 5.1 节中描述的指南的定义是否合适适用于所有 IC 和 IP。我们检查是否可能存在需要或可接受更严格或更宽松的目标值的例外情况。
    满足绝对和相对硬件架构指标

ISO 26262 规定了实现相对和绝对硬件架构指标的要求（ISO 26262-5 [3]，第 8 和 9 条）。必须满足所有要求才能达到 ISO 26262 合规性。这意味着仅满足相对硬件架构指标 SPFM 和 LFM 而不关心绝对 PMHF 指标是不够的。
这就是 ISO 26262 中要求的动机：PMHF 指标以绝对值表示汽车项目的剩余风险，必须加以限制。另一方面，相对硬件架构指标代表了人们应该投入的努力来降低系统的剩余风险。对于具有较高固有风险（具有较高 ASIL）的系统，即使绝对剩余风险水平可能已经相对较低，这种努力预计也会更高。
    基于系统或 IC 的总基本故障率，SPFM 与 ASIL 相关目标值的潜在偏差

PMHF 和 SPFM 目标都必须满足有关 PVSG 故障的项目。根据系统或 IC 基础故障率，这两个硬件架构指标中的一个或另一个将占主导地位。如果基础故障率低，则可以使用默认 SPFM 目标来实现 PMHF 目标，如表 1 所示。但是，如果基础故障率非常高，则此默认 SPFM 目标可能不足以同时实现 PMHF 目标.在这种情况下，有必要达到更高的 SPFM。我们建议尽早执行 PMHF 预算和 SPFM 目标调整（例如，在 SEooC 定义或 IC 级别的安全概念规范期间）。
    分别满足不同故障类型的硬件架构指标目标

ISO 26262-5 §8.4.7（注 1 和 2）[3] 和 ISO 26262-11，第 4.6.1.8 [4] 章（尤其参见第 4 段）明确指出对不同的故障类型分别进行分析，避免隐藏故障率较低的故障。对于 IC 或 IP，这意味着应该为硅芯片上的永久和瞬态故障以及与封装相关的永久故障（如果适用）指定和实现单独的度量目标值。
    ISO 26262 在项目级别定义的硬件架构度量目标值与组件和子部件的适用性和关系

ISO 26262 中的一些声明（例如，ISO 26262-4、§6.4.5.3 [5] 和 ISO 26262-5 § 8.4.7.b [3]) 可以解释为支持一个组件或子部分实现较低 SPFM 或 LFM 是可以接受的想法，如果其他组件或子部分可以用更好的方式弥补它 -超出要求的结果，以便在系统级别上仍然满足相关指标目标。但是，ISO 26262-5 §9.4.1.2 和 §9.4.1.3 强烈限制了这种方法，要求所有 ASIL C 或 ASIL D 硬件部件不得有任何单点故障或 SPFM 低于 90%（有一些例外）。在 IC 或 IP 中，例如 CPU，这两个要求应适用于 IC 或 IP 的所有主要子部件或子模块。
这些要求，包括 ASIL C 和 ASIL D 硬件部件的 SPFM 下限 90%，为 ISO 26262 合规性指定了明确的标准（例如通过功能安全评估）。除此之外，最好定义一个更严格的设计目标，即 ASIL X 硬件部件的 SPFM 绝不应低于 ASIL X-1 的默认 SPFM 目标（即 SPFM 绝不应低于 97% ASIL D，ASIL C 为 90%，ASIL B 为 60%）。

前面的例子说明，特别是 IC 或 IP 的 SPFM 目标值可能会偏离表 1 中与 ASIL 相关的默认值。稍低的 SPFM 目标值可能是可以接受的，或者可能需要更高的 SPFM 目标值来实现所有 IC，或系统级的度量要求。

5 系统级注意事项

5.1 提高 IP 或 IC 级实现的硬件架构度量和诊断覆盖率的方法和注意事项

如果在 IP 或 IC 级（例如，通过 STL）实现的实际 SPFM 低于所需目标，则结果可以通过以下方式改进：

    识别额外的、上下文感知的安全故障并获得荣誉

    在系统级别使用额外的安全机制或措施

5.1.1 识别额外的上下文感知安全故障

如图 1 所示，故障总数为安全故障和可能违反安全目标或安全要求的故障的组合。安全故障数量的增加也意味着可能违反安全目标的故障数量的减少。根据用例、配置、设计实施等各种因素在系统级别识别额外的安全故障有助于增强系统级别的 SPFM。安全故障可以分类为：

    架构安全故障 (Safearch)：这些故障是根据 IP 和网表的某些配置被识别为安全的。例如，由于同一门的另一个输入接地而阻塞的与门输入故障。

    例如，为了识别架构安全故障，IP 开发人员或 IC 集成商可以使用合格的工具对 IP 的特定配置和网表进行结构或形式分析。 IP 提供商通常会提供对某些配置或至少一个配置有效的架构安全故障列表。在 IP 级别计算 SPFM 时会考虑此类安全故障，并在示例 FMEDA 中提供。建议客户在确切实施的网表上执行其特定配置的结构分析，以推导出他们的 Safearch。
    依赖于应用程序的安全故障 (Safeapp)：此类别中的安全故障取决于应用程序，即最终的应用程序工作负载和活动模式。部分 IP 中的损坏结果可能永远不会被应用程序读取，或者在安全关键功能期间可能永远不会执行某个数据路径或完整块。例如，如果在实现中存在浮点单元 (FPU)，但该应用程序从未运行过浮点代码，则如果 FPU 中的故障不干扰其他活动部分，则可以认为 FPU 中的故障是安全的。知识产权。此外，一些芯片制造商随 SoC 提供的软件开发工具包 (SDK) 可以限制应用软件访问硬件的某些部分。与这些受限部件相关的硬件故障可以被识别为未使用区域，并且可以被制造商潜在地视为给定用例的安全故障。

根据使用硬件 IP 的应用程序，客户可以通过 Safearch 和 Safeapp 的组合得出安全故障总数。

5.1.2 在系统级别使用额外的安全机制或措施

在系统的各个抽象级别添加的安全机制或措施通过添加额外的保护层有助于项目的整体安全策略。这种分层方法直接或间接有助于增强 IP 或 IC 的 DC。本节详细介绍了如何通过将 STL 与可以在系统级别添加（或需要添加）的其他附加安全机制或措施相结合来增强 IP 的 DC。
这些安全机制或措施声称的诊断覆盖率应考虑 STL 故障覆盖范围的任何重叠以及在系统级别添加的任何其他机制或措施。工程判断以及本文提供的建议可用于估计 STL 的故障覆盖重叠以及确定 IP 或 IC 的整体 DC 的附加机制。这些建议基于统计估计而不是精确测量，因为在大多数情况下，一旦集成了 IC，就很难测量 DC 的门级故障。
通常，为 IP 中的每个块或子块生成 STL 测试模式。可以生成这些测试模式：

    通过创建针对特定逻辑或接口的特定场景来系统地（即定向测试）或

    随机地，例如通过使用随机指令集 (RIS) 生成工具。
在系统级别添加的附加安全机制或措施也可以归类为相对于 STL 的随机或系统。这些额外的安全机制或措施包括：

    可以添加到应用程序层的定向测试，通常用于覆盖 STL 未涵盖的系统其他部分的故障。 DC 和这些定向测试与 STL 涵盖的故障的任何相关性必须由系统集成商或开发人员确定。
    可以添加到应用层的随机测试。这些测试所达到的 DC 必须由系统集成商或开发商确定。例如，基于 RIS 的测试或为安全关键应用系统开发的应用软件（第 5.1.2.1 节）。

5.1.2.1 作为随机测试的安全关键应用的系统开发应用软件

从 SEooC IP 或 IC 的角度来看，可以假设通用应用软件随机运行和测试 IP 的整个部分或子部分，例如中央处理器。

根据 ISO 26262 第 6 部分 [6]（或 IEC 61508 第 3 部分 [7]）的建议，为具有集成软件安全机制的安全关键型应用系统开发的应用软件可以为随机硬件故障提供诊断功能。这些用于错误检测的软件安全机制的示例（ISO 26262-6:2018 7.4.12 注 2 [6]）包括：

    输入和输出数据的范围检查。例如，如果 ALU 发生随机硬件故障并生成超出范围的结果，则下一个范围检查会检测到这一点。
    合理性检查。例如，使用所需行为的参考模型，包括断言检查，或比较来自不同来源的信号。
    在软件中实现的访问冲突控制机制涉及授予或拒绝访问与安全相关的共享资源。这些可以检测寻址逻辑、内存保护单元 (MPU) 等中的随机硬件故障。
    细粒度的程序流监控，结合超时或窗口看门狗，实现对程序序列的时间和逻辑监控。这可以检测到影响正确程序流程的随机硬件故障。

如果有足够的证据或可以合理地假设，系统开发人员严格遵守 ISO 26262 第 6 部分 [6]（或 IEC 61508 第 3 部分 [7]）中推荐的软件安全机制，则可授予应用软件在改善随机硬件故障的整体DC。
应使用以下考虑因素来确定可声明的 DC：

    与应用软件定义的用例的系统相关的故障模式识别的完整性。
    为检测系统的不当行为而实施的集成软件安全机制（例如，范围检查、程序流监控等）的有效性。
例如，对于一个简单的应用，如轮胎压力监测系统，其中故障模式得到了很好的理解，并且软件安全机制（如范围检查、合理性检查等）得到了有效实施，如果它可以要求额外的 DC可以说得通。但是，如果它是一个复杂的系统，则声称的覆盖范围必须更低，以适应与故障模式识别和已实施软件安全机制的有效性相关的任何不确定性。

根据用例，应用软件还限制对 IP 某些区域的访问。这反过来又增加了安全故障 (Safeapp)，从而有助于改进 SPFM。不可能准确地确定通用应用软件对安全故障和 PVSG 故障的贡献。因此，我们建议不要在使用为安全关键应用程序开发的应用程序软件声称的诊断覆盖范围之外声称额外的假定安全故障 (Safeapp)，除非有理由。例如，通过分析是否可以证明特定用例的软件从未访问过 IP 的某些部分。

5.2 计算具有附加保护层的增强型 DC 时要考虑的因素

在确定通过添加附加保护层可以要求 DC 改进多少时，需要考虑两个因素，如第 5.1.2 节所述，“使用附加保护层”

5.2.1 附加安全机制或措施相对于 STL 的统计独立性

统计独立性存在于：

    两个随机机制或措施以及

    随机和非随机机制或措施的组合

如果添加了额外的保护层（例如具有集成安全机制的应用软件）并且 STL 在统计上是独立的，则两种机制实现的总体 DC 为：

    STL 覆盖的故障（DC1），加上

    随机覆盖的附加故障技术，即具有集成安全机制的应用软件（DC2），来自残余故障（1-DC1）。
这个 (DCnew) 可以使用以下公式计算：

5.2.2 IP现有覆盖率

根据经验，如果第一安全机制的DC较高，则第二安全机制检测到额外故障的概率较低。在 STL 的情况下，在覆盖率超过 60% 的 STL 之上添加随机安全机制或措施来改进 DC 只会在整体 DC 上提供一些增量改进。此外，很难确定目标的确切故障以及两种机制检测到的故障的重叠。因此，只能假设附加随机安全机制或措施的 DC。因此，在增加额外的保护层时，我们应该采用更保守的方法来计算 DC 的改进（DCnew），并且只考虑以非常高的概率（>0.99）检测到的额外故障。 5.2.2.1 计算达到 DC 大于或等于 DCnew 的概率

这可以使用概率的经典定义来计算，也就是说，事件的概率是对它有利的情况的数量与当没有任何情况导致我们期望这些情况中的任何一种情况时所有可能情况的数量之比应该比另一个发生更多。二项式系数可用于评估从 n 个元素的集合中选择 k 个元素的子集而无需替换的方法的数量。该系数也称为“组合”或“组合数”。符号 nCk 和用于表示二项式系数，读作“n 选择 k”[8]。

出于此计算的目的，我们使用 DC(%) 而不是故障总数来使计算易于处理。
通过 DC1 和 DC2 的 DC 的两个测试的组合实现 DC 大于或等于 DCnew 的概率为：

 

 如果 P(DCnew) 小于 0.99，我们建议仅声明 DCnew -adj（读作 DCnew 调整）的增强 DC，其概率大于或等于 0.99。当 DC1 和 DC2 已知时，可以使用公式 8 计算 DCnew -adj。以下部分显示了有关如何使用此方法的示例。

5.3 示例：使用系统开发的应用软件在系统级增强 DC

这是一个关于如何通过系统开发的具有集成安全机制的系统级软件提供的 DC 来计算增强 DC 的示例：

    IP 经受 STL 随机生成的测试模式，其 DC = DC1 = 75%。
    实现 STL 的系统复杂度低。
    在应用层中添加了按照 ISO 26262 第 6 部分 [6]（或 IEC 61508 第 3 部分 [7]）推荐的具有集成安全机制的系统开发软件。由于应用软件的复杂性较低，人们可以假设故障模式已被很好地理解。在这种情况下，可以为此应用程序 SW 声明 DC = DC2 = 60% 。

聚合这两个测试时的增强 DC 可以使用公式 7 计算，因为它们在统计上是独立的。这里的假设是检测到故障的概率不会因所讨论的特定故障而改变，例如，检测到故障 1 的概率并不比检测到故障 2 的概率高，并且对于所有可能的故障都是如此。
在我们的示例中，为简单起见，我们假设：

    总共 100 个 PVSG 故障

    STL 在这 100 个 PVSG 故障中检测到 75 个故障（DC1 = 75%）

    应用程序软件可以在 100 个 PVSG 故障中检测到 60 个故障（DC2 = 60%） ) 根据 5.2.1 节，应用软件检测到的 60 个故障可能包含

    在 STL 已经检测到的 75 个故障中，也就是说，没有发现其他故障，或者

    它可能是由 STL 检测到的一些故障的组合。 STL 和一些额外的故障。

假设具有集成安全机制的所有可能应用软件的范围是随机的、增强的 DC (DCnew)，使用公式 7：

DCnew = DC1 + DC2 - DC1。 DC2 = 90%。
这意味着当聚合两个串联执行的测试的 DC 时，诊断覆盖率为 90%，即 STL (DC1 = 75%)，然后是应用程序 SW (DC2 = 60%)。
使用第 5.2.2 节中的建议：

实现增强型 DC 的概率，DCnew ≥ 90% 可以通过检测到 90 个或更多故障的方式数除以可以检测到任何其他故障的方式总数来评估。

让我们假设：

    N1 是检测到最多 90 个故障的方式数

通过两次测试总共检测到至少 90% 的故障（DCnew≥90%）的概率为 P(DCnew) = N2/(N1+N2) = 0.5959 = 0.6（大约），即有 60% 的概率实现至少 90% DC。

由于实现 DCnew ≥90% 的概率仅为 0.6，因此进行了分析以评估 DCnew-adj，该概率至少为 0.99。

图 3 中的图总结了分析的结果，该分析结果用于评估 DC，通过两次测试可以达到的概率至少为 0.99。

    T1（STL，70%<DC1<90%）和

    T2（具有集成安全机制的应用软件，DC2=60%）

 图 3：概率大于 0.99 的新 DC，测试 1 (STL) 的 DC 在 70% 到 90% 之间变化，测试 2（应用软件）的 DC = 60%

该图显示，当聚合两个串联执行的测试的 DC 时，我们可以实现高达 85% 的 DC，概率至少为 0.99，即 STL (DC1= 75%) 和应用软件 (DC2 = 60 %）。

系统集成商可以使用这种方法来为系统开发的具有集成安全机制的应用软件（第 5.1.2.1 节）在系统上运行所提供的覆盖范围提供功劳。如果系统集成商希望在报告硬件架构指标时从中受益，则添加使用假设 (AoU)。

6. 结论

6.1 STL 供应商的结论和建议

STL 供应商在开发 STL 时，应努力实现 ISO 26262 为假定的 ASIL 设置的相关硬件架构指标。但是，如果 IP 级别的 SPFM 较低，系统集成商和系统开发人员可以将功劳归功于用例特定因素、在系统级别实施的额外安全机制或测试或技术，以提高 IP 的 SPFM 以满足默认值SPFM 目标由标准设定。

6.2 对于添加额外保护层的集成商或用户的结论和建议

STL 不符合 IP 或 IC 级别的 DC 和 SPFM 目标，仍可用于针对特定 ASIL（例如，ASIL B）的应用，作为硬件架构指标可以在系统级得到增强，方法是在 IP 级确定 SPFM 时不考虑应用特定的安全故障。此外，可以在系统级别实施额外的安全机制或措施或测试，以弥合 IP 目标中的任何进一步差距。
我们欢迎您对本白皮书中讨论的概念提出想法。请发送电子邮件至 safety.partners@arm.com 以分享您的反馈或有任何疑问。有关 Arm 功能安全的更多信息，请访问 www.arm.com/safety。

参考文献

1 “ISO 26262-1，道路车辆 — 功能安全 — 第 1 部分：词汇”。
2 N. Menon，“为 CP 添加功能安全的灵活方法”，[在线]。可用：https://community.arm.com/developer/ip-products/system/b/embedded-blog/posts/the flexible-approach-to-adding-functional-safety-to-a-cpu。
3 “ISO 26262-5:2018，道路车辆 — 功能安全 — 第 5 部分：硬件级别的产品开发”。
4 “ISO 26262-11:2018，道路车辆 — 功能安全 — 第 11 部分：ISO 26262 应用于半导体的指南”。
5 “ISO 26262-4:2018，道路车辆 — 功能安全 — 第 4 部分：系统级别的产品开发”。
6 “ISO 26262-6:2018，道路车辆 — 功能安全 — 第 6 部分：软件级别的产品开发”。
7 “IEC 61508-3，电气/电子/可编程电子安全相关系统的功能安全 - 第 3 部分：软件开发”。
8 K. P. Murphy，机器学习概率视角，2012 年。 9 “EN 50126：铁路应用——可靠性、可用性、可维护性和安全性 (RAMS) 的规范和演示”。