汽车微控制器在线自测开发

原创于 2025-10-16 09:12:38 发布 · 334 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#核心自测 #CST #SBST #故障覆盖率 #ISO26262

汽车微控制器在线核心自测的开发流程

摘要

基于软件的自测试（SBST）是一种用于实现片上系统（SoC）在线测试的有效方法。在汽车领域，一组在任务模式下运行的SBST程序也称为核心自测（CST）库。本文提出了多项新贡献：（1）阐述了在生成用于在线执行的测试程序时需要考虑的多个问题；（2）提出了一种基于有序生成测试程序的整体开发流程，以最小化计算开销；（3）提供了指导原则，以确保CST库与任务应用共存的同时保证执行鲁棒性。所提出的方法已在大型工业案例研究中进行了实验验证。经过一年的团队工作，达到的故障覆盖率超过87%的固定故障覆盖率，且执行时间符合ISO26262规范。实验结果表明，其他替代方法可能需要过度的评估时间，从而使生成流程在大型设计中不可行。

索引术语

微处理器和微型计算机，可靠性与测试，基于软件的自测

1 引言

汽车领域电子系统的普及正在快速增加，汽车制造商不断要求电子制造商提供速度更快、成本更低、功耗更少且更可靠的设备。基于微处理器的系统被广泛应用于汽车中的多种场景，从信息娱乐到发动机和车辆动态控制，包括安全气囊和制动控制等与安全相关的系统。

在安全关键和任务关键型应用中使用此类设备，提高了对完全可靠性的需求。这一要求转化为一系列需要贯穿产品生命周期的系统审计流程。其中一些流程在当今的工业设计和制造流程中较为常见，包括自产品开发早期阶段就开始进行的风险分析、设计验证与确认，以及在制造和组装过程中及结束时执行的各种测试操作。越来越多的情况下，还需要在产品使用期间进行额外的测试操作，可能包括周期性的在线测试和/或并发错误检测。为满足可靠性要求，需在所选方案的故障/错误覆盖率能力与可接受的实现成本之间进行权衡。

在基于微处理器的集成系统范围内，软件自检（SBST）方法长期以来已被研究领域的不同团队所关注[1][2][3]。SBST技术基本上让中央处理器运行一系列专门用于激发和传播错误的代码字，以尽可能覆盖影响电路的最大故障集[4]。与基于硬件的测试解决方案（如内建自测试（BIST））相比，该方法具有诸多优势，包括能够在正常工作模式下自主地对微处理器和可控外设进行自检[5]和诊断[6]，无需引入任何硬件修改，并支持全速测试应用（即在电路额定频率下进行测试）。然而，片上自测试（SBST）方法多年来在工业应用中仍面临一些限制性问题：这些问题主要涉及编写高效且有效的测试程序，以及设计合适的测试应用方法论。

在制造测试领域，BIST解决方案通常更受青睐，因为其能够在短时间内实现高覆盖率，并具有简单的开发流程；而在在线测试应用方面，SBST正成为定期监控系统健康状况而不干扰正常任务行为的首选解决方案[7][8]。业界普遍采用的一种解决方案是周期性地应用由SBST测试程序组成的核心自测（CST）库进行测试。如图1所示，微处理器会周期性地被强制执行一段自检代码，以检测处理器核心本身及其连接外设中可能发生的永久性故障。这些过程经过专门设计，用于激活潜在故障，然后将自检结果压缩并存储在可用的内存空间中，或在测试未正确结束时发出信号。

就测试程序生成而言，文献中可以找到许多方法，这些方法采用手动或自动化的方式，适用于针对不同的处理器架构和故障模型的测试，如[4]中所述。然而，建立高效的CST开发流程涉及测试程序生成、组织和分级方面的若干额外问题需要解决[9]。应对这些在线需求意味着在测试程序生成过程中必须引入额外的规则，并且需要添加额外的代码部分，这可能会影响核心自测（CST）的开发时间。

示意图0

本文提出了一种创新且全面的方法，用于开发适用于安全关键型汽车嵌入式系统中微处理器的核心自测（CST）库，并将其集成到操作系统中。该方法旨在满足新兴标准（如ISO 26262[10]）所规定的可靠性要求，该标准要求在其任务生命周期内对电路中可能出现的永久性故障进行持续监测。

本文的技术内容涉及在线测试程序特性和开发流程的最相关方面。本文通过描述和讨论，推进了该领域的现有技术水平。
1. 生成用于在线执行的自检程序时需要考虑的约束条件；
2. 在与嵌入式操作系统共存的情况下，自检程序需具备稳健的在线执行能力；
3. 一种有效的开发流程组织，旨在最小化计算开销。

本文最后展示了一个工业案例研究中收集的结果。通过对意法半导体（STMicroelectronics）制造的汽车系统级芯片中嵌入的大型32位处理器进行评估，分析了在线需求的影响。文中报告了代码开销以及生成策略针对在线应用的调整情况；实验结果还表明，除非在CST创建过程中规划适当的资源划分和顺序，否则在规模较大的处理器上开发核心自测（CST）可能会变得不可行。

本文的其余部分组织如下：第2节描述了在生成测试程序时遇到的在线约束条件。第3节详细说明了测试程序应具备的特性，以确保其具有鲁棒性并完全符合操作系统要求。第4节阐述了一种适用于大型微控制器的有效开发流程。第5节展示了实验结果，第6节得出了结论。

2 核心自测生成约束

基于软件的自检被广泛认为是一种精确且非侵入性的自主测试方法。简而言之，通过运行测试程序并简单地调用处理器功能来检测异常行为。该过程本质上符合功耗约束条件，因为测试程序使处理器在与任务模式下相同的工作条件下运行；不需要额外的测试电路，并且对测试设备所需的特性和资源要求较低，成本也相对低廉。

在处理必须在线应用的核心自测时，测试程序必须与负责管理任务的使命应用程序（即操作系统（OS））共享处理器资源；与通过片上自测试（SBST）进行的制造测试相比，这种共存带来了非常严格的限制：
1. 核心自检测试程序需要符合标准接口，使操作系统能够将其作为普通进程处理。该接口必须保证处理器状态的保存和恢复，即使在高优先级请求（例如抢占）的情况下也是如此；
2. 核心自测（CST）程序需要根据执行时间约束生成，因为这些资源占用必须在任务环境中可承受。特别是当测试因使用关键资源（即，特殊用途寄存器）而无法被中断时，这一点是严格要求的。
3. 由于表征操作系统的任务代码和数据对内存资源的使用存在严重限制。为应对这一问题，建议
- 将核心自测（CST）提供为一组预先编译好的程序，存储在二进制镜像中，可在任务模式下运行，可能由操作系统进行调度和加载；
- 跳转时不得引用绝对地址，意味着测试代码可存储在内存的任何位置，并可最终从其他位置复制和启动，而不会造成功能或覆盖率上的损失；
- 访问数据内存时不得引用绝对地址；
- 从操作系统限制的角度识别可能存在的内存约束条件，以及为测试目的必须保留的必要位置。

同样可以说，为了减少工作量，测试的创建还应考虑通用处理器系列的特性，以便在将CST库移植到同一架构家族中的另一个处理器核心时减少代码修改。接下来的段落将探讨这些问题，并提供一些指导方针，以方便尽早做出决策。

3 核心自测执行管理

正如引言部分简要描述的那样，在任务环境中集成SBST例程是一个关键问题。为应对这种集成所带来的复杂方面，我们建议在生成之外考虑三个主要问题，这些问题与测试程序的执行相关：
- 与其他软件模块的协作，通常与操作系统等任务环境相关
- 上下文切换和结果监控
- 在发生故障行为时的鲁棒性，这与中断管理密切相关。

3.1 测试封装

考虑到与操作系统启动的线程等其他软件模块的协作，测试程序套件需要包含关键特性，以实现测试的启动、监控，并最终能够被任务管理系统中的高优先级进程中断。

示意图1

图2以图形方式描述了测试程序的结构，以及为测试目的需要配置的存储器和外设资源。测试程序通常存储在闪存中并在此执行。

首先，为了与任务软件环境兼容，一个可行且强烈推荐的解决方案是采用嵌入式应用二进制接口（EABI）[11]，该接口规定了软件程序的文件格式、数据类型、寄存器使用、堆栈帧组织以及函数参数传递的标准约定。因此，每个测试程序都包含一个EABI序言和尾声，负责保存和恢复mission status。

在测试代码开始处创建了EABI框架后，任何调度器都可以启动测试执行，例如，运行测试例程的操作系统中可用的调度器。此外，我们建议包含特定测试调度器设置适当运行环境所需的额外信息。

附加测试信息包括：
- 栈帧大小
- 特殊用途寄存器设置，
- 内存保护设置以及
- 测试持续时间。

这些元数据由测试程序用于设置
1) 持续时间（即，看门狗设置）
2) 栈帧大小（即，可用于保存任务配置和测试程序局部变量的空间）
3) 处理器设置（即，特殊用途寄存器的特定值）
4) 内存配置（即，虚拟内存初始化）
5) 内存保护（即，通过异常处理错误的内存访问）

以及在测试程序执行结束时
6) 签名检查。

这种内存结构也可以存储在大容量内存中，直到被加载到可用内存的任何部分运行，具体方式如第2节（即重定位）中已描述的特性所示。

3.2 上下文切换到测试过程

如第3.1节所述构建的测试程序可作为正常系统任务集成到任何操作系统中。正确的上下文切换主要由EABI接口提供支持；额外的设置可能因测试程序的特性而异，并由测试程序利用元数据进行管理。

我们确定了三种一般情况，每种情况在设置过程中都需要使用适当的元数据：
- 运行时测试：通常用于覆盖算术模块等计算模块，可能会被任务请求中断。
- 非异常测试：出于测试目的需要操作SPR寄存器，例如测试寄存器文件
- 关键测试：有意触发中断并利用外围核心进行测试。

运行时测试是最容易管理的：只需根据EABI合规性创建一个栈帧；栈帧大小最小。建议以低权限（即用户模式）执行此类测试，因为在正常（无故障）情况下，它们永远不会请求中断或执行特权指令。无需其他特殊设置。EABI合规性可在整个执行过程中得到满足，这意味着另一个操作系统线程可以抢占测试的执行。

非异常测试较难管理，因为它们使用了在EABI环境下不允许直接使用的资源，例如特殊用途寄存器。对于此类测试，在运行测试之前必须执行额外的设置步骤。
- 禁用外部中断以避免被抢占
- 将所有特殊用途和通用寄存器保存到更大的栈帧内存区域，并
- 根据处理器设置信息修改其内容。

此外，在测试执行结束时需要进行一些收尾操作，以恢复初始配置。在执行这些测试期间，不允许发生抢占，因为无法保证符合EABI标准。

在考虑关键测试时，需要完成更严格的请求。除了保存和恢复所有寄存器并禁用外部中断源外，还需要保存更多信息，例如
- 用于测试目的时所需的中断向量表（IVT）以及相关寄存器，包括需要替代IVT的情况
- 所使用的外设模块的当前状态和控制寄存器，例如中断控制器配置和内存管理单元。

3.3 中断管理与鲁棒性

中断机制负责管理同步和异步异常，需要格外小心处理，因为它们不仅会为了测试目的而被有意触发。在我们看来，有以下三种类型的异常：
- 有意触发的异常，即用于测试处理器异常
- 意外，由错误执行引起，而错误执行是由故障配置所引发
- 任务模式中断。

故意引发的中断可以是同步或异步的。诸如系统调用、非法内存访问、非法指令和特权相关操作等情况属于同步中断，因为他们必须由代码本身触发。相反，异步中断则通过外围核心产生。

因此，要测试异常，必须既要引发异常，又要对其进行管理。该机制如图3所示。如果管理中断的电路未被故障破坏，则每个强制触发的异常都会被正确处理，即会调用一个特定测试的中断服务程序（ISR）。这样的ISR在调度执行过程中进行配置，并替换原有的任务ISR。

包含在中断服务程序（ISR）中的代码还负责将重要信息（例如状态寄存器）累积到特征值中。当发生故障时，标准执行流程可能会被偏离，导致本应被调度的异常并未被触发。在这种情况下，特征值更新不会执行，最终测试也就无法生成正确的特征值。

此外，异常管理对于应对由于各种故障导致的流程偏差也至关重要，这些故障可能引起处理器内部状态异常，并导致意外的同步中断。典型情况包括从合法指令格式变为非法指令格式、由内存保护单元机制保护的非法内存访问等。如果在任何测试程序执行期间发生此类情况，测试中断服务例程（ISR）应能够理想地恢复此类偏差，并记录观察到的错误行为。可以采取一些对策来识别意外的中断请求，例如在中断服务程序（ISR）序言中执行断言，以检查在有意触发中断之前存储在通用寄存器（GPR）中的密码。类似的方法也用于检查从中断的正确返回，例如通过在测试执行结束时添加断言来完成。

这种技术使测试代码非常稳健，但如果处理器状态变得不稳定，导致出现虚假和重复的异常以及无限循环，则需要做更多的工作。在后一种情况下，必须实现外部机制以将系统转入安全状态，例如通过看门狗定时器。

这些情况如图5所示，其中实线表示预期的中断，而虚线表示处理器状态不稳定时的影响。在运行时测试程序期间，需要尽快识别并处理任务中断，即将其传递给操作系统。通过遵循EABI标准，可以轻松管理这种情况。

4 核心自测开发流程

核心自测开发流程中的主要成本和问题在于生成测试程序套件时所需的计算量。特别是故障分级过程[9]，其具有用于评估测试程序在故障检测中的有效性而进行的测试，代表了一个严重瓶颈。这种成本被前几段中描述的、由在线执行所要求的测试程序基础设施所加重。

例如，为了让读者了解这一成本，对于一个中等规模的嵌入式处理器，若其包含约20万个固定型故障，则在使用一台运行4个并行故障仿真进程的2GHz四核工作站时，对一个1ms的程序进行故障仿真的所需时间可能高达3天。

如果生成过程是迭代的[15]，并且在达到良好覆盖率之前产生许多需要评估的程序，则该成本变得不可持续。

因此，我们提出了一种基于以下原则的方法，以实现开发时间的减少和资源的优化：
1. 无法将嵌入式处理器作为一个独立模块来处理，而应分别考虑其子模块（例如，算术逻辑单元、控制单元等），这意味着处理器的故障集合被选择性地划分为多个较小的故障列表，以便在生成测试程序时能够有效应对；
2. 通过分别面对各个模块，当有多个工作站/测试工程师可用时，有助于实现开发过程的并行化（详见4.1节）；
3. 在为特定子模块开发测试时，可能会产生副作用，即覆盖属于其他子模块的故障。

我们提出的策略基于这些原则，其包括反复执行两个步骤，直到考虑所有子模块：
- 生成（可能并行）针对一组精心选择的子模块的测试程序（详见4.2节），直到这些子模块得到充分覆盖
- 在不同测试程序之间进行同步，以评估它们在更大故障列表上的有效性；同步意味着对为特定子模块生成的测试程序，在另一个不同（更大）的子模块列表上进行评估和协调

图4展示了所提出流程的简化示意图，该流程考虑了一个由四个模块（s1到s4）组成的微处理器（中央处理器）。在图2.B所示的第一步中，两个模块（s3和s4）被并行考虑并分别进行分级，即在为模块s3生成测试程序时，仅考虑其自身的故障列表。一旦这些子模块的覆盖率令人满意，生成的测试程序就会如图2.C所示，在中央处理器的其他部分上进行分级；这一同步步骤带来了正面的副作用，即在对s4的测试程序进行分级时，不仅提升了s1和s2模块的覆盖率，也提升了s3的覆盖率，反之亦然。随后，在s1和s2上启动新一代步骤；如图2.D所示，值得注意的是，之前的步骤已带来益处，因为在进入s1和s2的生成过程之前，它们的初始故障列表已被减轻。

采用这种方法的优势主要在于能够更快地开发测试套件，因为
- 需要考虑的故障列表远小于完整故障列表，从而实现了更快的故障分级，通常只需几分钟即可完成；
- 每次同步步骤后，新子模块中的活动故障数量减少，再次加快了故障仿真过程。

4.1 资源划分

如前一段所述，将处理器划分为子模块可以并行考虑多个独立的故障列表；在生成工作之前的初步阶段，其选择是主要问题。

为了实现独立性，故障列表需要
- 非重叠乒乓：一个故障只能属于一个故障列表
- 功能正交：同一独立故障列表中的故障需要属于与某一特定功能相关的模块

非重叠乒乓准则要求在过程中同一故障只能被考虑一次；另一方面，在处理正交性时，从相关门电路的功能性角度来看，故障需要被包含在最相关的故障列表中。

选择故障列表集的过程并非易事。在我们的流程中，此过程需考虑以下因素：
- 微控制器的手册和文档，包含有关微架构的具体说明
- 微控制器网表的层次结构
- 测试工程师经验

为了识别独立的故障列表
- 处理器功能的分析
- 在微控制器层次化网表上对功能进行映射

大多数故障列表可能源自特定模块，但当涉及相同处理功能时，也经常需要将多个子模块压缩到单个故障列表中。例如，乘法单元的故障通常构成一个独立的故障列表。相反，存在多个看似独立的网表模块的多路复用器，但实际上这些多路复用器组成了处理器流水线中的前馈逻辑；因此，属于这些多路复用器的故障必须归入同一个故障列表中，该列表在功能上是正交且不与其他模块重叠的。

关于计算资源的分配，一旦确定了独立的故障列表，为了最大化可并行考虑的故障列表数量：
- 根据以下因素，在单个或多个故障分级线程上对单个子模块进行覆盖率计算：
- 每个中央处理器可用的线程数量；
- EDA工具许可证数量；
- 故障列表大小
- 通过使用多线程实现结果同步。

4.2 优化的测试程序生成顺序

根据上述描述的副作用原理，在测试程序生成过程中，选择最有前景的顺序至关重要。该决策需要根据正在分析的特定架构进行定制。

接下来，我们提出了一些通用准则，用于确定考虑汽车领域最常见和广泛使用的微处理器架构的测试程序生成顺序。

在我们的开发流程中，我们根据横向和纵向的流程规则来组织生成顺序。

垂直流程规则要求将流程划分为连续的层级，使得在测试完某一特定层级中的所有模块后，在进入下一层级时，故障覆盖率方面会观察到显著的正面副作用。我们目前提议根据以下规则将流程划分为不同层级：
1) 首先考虑那些可映射到特定汇编指令或特定架构程序设计机制的单元；
2) 接着处理存储和控制流程资源；
3) 最后处理对程序员透明功能的模块。

根据所提出的策略，在完成当前考虑的层级后，进入下一级之前需要进行同步步骤；该同步步骤涉及下一级的所有子模块，即逐步减少需要考虑的故障列表的大小。

通过以水平方式审视问题，还可以识别出许多仍然符合垂直要求的并行分支。这种水平视图包括识别分支，使得可忽略的副作用跨越属于不同水平视图的分支。

根据上述规则，针对典型的汽车应用架构，我们基于3个层级和2个分支划分了一种开发流程。然而，在考虑配备特殊功能的微处理器时，例如缓存[12]、共享内存方案[13]和浮点单元[14]，可以增加额外的分支。

我们建议首先考虑两类子模块：
第1层–A分支）算术逻辑单元子模块：易于测试，需要执行特定的算术和逻辑指令。通过精确选择用作操作数的寄存器以及控制流管理中的寄存器，可使对寄存器文件的影响最大化。

第1级–分支B）特殊子模块：它们包括异常处理、分支预测和虚拟内存相关模块，例如内存管理单元（MMU）模块。这些子模块难以覆盖，需要特定的指令和指令序列。它们将产生非常大的正向响应。对与地址相关的模块产生副作用。

一旦这些子模块达到足够的覆盖率，建议进入同步过程。为1A)开发的程序集将在寄存器文件故障列表上进行评估，而1B)则在与地址相关的模块上进行评分。结果，需要考虑的活跃故障数量大大减少。

第2级—分支A）寄存器文件：寄存器文件的测试是直接的，已有许多论文描述了有效的测试序列。在所提出的生成方法中，建议重新排列指令和操作数，以引发流水线中数据依赖结构的使用。

2级—分支B) 地址相关模块：通过完成1B)，地址相关模块中包含的大部分故障（如分支单元、有效地址计算和程序计数器）已得到覆盖。因此，此步骤主要是对前一步骤的补充，主要通过增加内存操作以及针对特定地址的分支来实现。

然后对PIPELINE和CONTROL UNIT模块执行同步步骤，接着是三级且不再有分支，这包括针对这些级别模块的专门生成步骤。

为了完成该流程，需在整个处理器故障宇宙上评估通过此流程获得的完整测试套件，最终通过添加细化程序来覆盖之前步骤中未考虑的边界情况和特定配置。

5 32位汽车设备上的结果

为了评估其有效性，本文提出的方法已应用于一款包含基于Power ArchitectureTM的32位流水线微处理器的片上系统。该片上系统用于安全关键型汽车嵌入式系统，如安全气囊、防抱死制动系统和EPS控制器，目前由意法半导体制造。

5.1 研究案例

该微控制器的高性价比处理器核心基于Power Architecture技术构建，专为嵌入式应用而设计。该处理器集成了两个整数执行单元、一个分支控制单元、一个取指单元和一个加载/存储单元，以及一个多端口寄存器文件，能够在每个时钟周期支持六次读取和三次写入操作。大多数整数指令可在单个时钟周期内执行。分支单元执行分支目标预取，使得在许多情况下可实现单周期分支。该处理器包含一个内存管理单元（Memory Management Unit），并集成了一个Nexus Class 3模块。

32位处理器采用五级流水线进行指令执行。这些阶段包括：
- 取指（第1阶段）
- 指令译码/寄存器文件读取/有效地址计算（第2阶段）
- 执行0/内存访问0（第3阶段）
- 执行1/内存访问1（第4阶段）
- 寄存器写回（第5阶段）

各阶段以重叠方式进行操作，使大多数可用指令能够在一个个时钟周期内执行。

整数执行单元由一个32位算术单元（AU）、一个逻辑单元（LU）、一个32位桶形移位器（Shifter）、一个掩码插入单元（MIU）、一个条件寄存器操作单元（CRU）、一个计数前导零单元（CLZ）、一个32x32硬件乘法器阵列以及结果转发硬件组成。整数EU1还支持硬件除法。大多数算术和逻辑操作均可在单个时钟周期内完成，乘法操作除外，其采用2周期流水线硬件阵列实现；除法指令亦不在此列。计数前导零单元可在单个时钟周期内完成操作。

提供了两个执行单元，以支持大多数指令的双发射。仅提供了一个单通道加载/存储单元和一个单通道整数除法单元，因此一对除法指令无法同时发射。

5.2 实验结果

经过一年的团队工作，我们收集了大量模块的结果。通过软件测试处理器是一个被深入研究的领域；因此，在许多情况下，所采用的技术均借鉴自文献，并经过调整以覆盖所考虑的处理器核心的特定模块。表1列出了为实现每个模块高故障覆盖率而采用的生成技术。

在选择这些技术时，我们参考了当今文献中关于测试程序生成的一些最重要提议。

关于自动方法，我们采用了基于自动测试模式生成的技术以及基于进化算法的优化技术。其他一些技术（标记为确定性）指的是利用子模块规则性来提出明确定义的测试算法的现有解决方案。最后，标记为手动的行指的是测试工程师通过利用处理器用户手册、指令集架构以及可用的HDL处理器描述所执行的纯手动策略。

如第2节所述，每个单个测试程序的测试持续时间和大小是在线要求，可能会根据任务应用和微控制器的物理限制（例如可用的存储空间）而变化。在我们的案例研究中，对单个程序的持续时间以及整个测试套件的总体占用情况都提出了限制。具体而言，标记为运行时测试的单个程序的最大持续时间不应超过512个时钟周期，而用于测试目的的FLASH存储区域被限制为256KB。

为了满足这些约束条件，每种生成方法都需要及时进行相应调整：
- 基于ATPG的生成方法可以通过要求自动测试模式生成引擎实现高压缩率，并将生成限制在最大模式数量范围内；生成的模式最终可以转换为多个符合持续时间约束条件的测试程序。
- 在进化计算实验中使用的适应度值包括程序大小和长度测量；通过这种方式，超出施加限制的程序将被舍弃；
- 确定性和手动方法需要测试工程师额外努力以满足程序长度和大小的要求；如果程序过长，更简单的方法是将其拆分为多个较短的程序。

在所有情况下，还考虑了符合在线测试要求的代码特性，例如代码可重定位（不允许使用绝对分支和通过绝对地址访问内存位置），并且仅使用为测试目的预留的有限内存空间（1kB）。

如第3节所述，每个生成的程序都被封装到EABI标准框架中，并包含确保测试鲁棒性的附加代码序列。对于当前的研究案例，符合EABI的框架在过程开始时仅占用很少的指令（例如3-5条指令）；而该数量在以下情况下会增加：
- 在使用之前必须保存额外的寄存器，并最终将其恢复到原始值（例如，非易失性寄存器或特殊用途寄存器，如微处理器状态寄存器）
- 需要保护内存资源（例如，利用内存保护单元）
- 需要对外设资源进行编程以确保测试的鲁棒性（例如，看门狗定时器）

为实现鲁棒性而非仅满足EABI标准所需增加的指令数量约为20条。此外，为了进一步增强鲁棒性，在因测试需要而通过异常主动触发上下文切换时，增加了额外的指令。关于开发流程，故障列表的生成及所采用的生成顺序遵循第4节中提供的通用指导。

故障列表主要根据与网表层次结构中特定模块直接相关的处理器功能生成。存在一些例外情况，因为所考虑的微控制器采用双发射架构，复制的算术模块（如加法器）被视为唯一的故障列表；此外，数据转发单元由多个多路复用器组成，其故障被统一考虑。另一个有趣的资源划分案例涉及多端口寄存器文件，它贡献了两个故障列表：寄存器存储体和寄存器端口（解码器和多路复用器）；这既是因为故障列表大小需要拆分，也是由于功能上的差异。

子模块	技术	参考文献
算术加法器	确定性 + 约束自动测试模式生成	[15][16]
除法单元	进化式	[17][18]
逻辑单元	确定性
乘法单元	确定性
移位器	约束自动测试模式生成
异常	手动	[19]
分支单元	确定性	[20]
定时器	手动
寄存器组	确定性	[21]
寄存器端口	确定性	[21]
EA加法器	基于循环
加载存储单元	手动
程序计数器	进化式	[22]
转发单元	确定性	[23]
解码单元	确定性	[24]
状态/控制标志	确定性
取指单元	确定性	[25]

表1 生成过程中使用的片上自测试（SBST）策略

表2显示了开发流程中覆盖率的演变。最终故障覆盖率达到故障列表的87.23%，该故障列表包含约75万个固定型故障。

存在未被充分覆盖的模块：
- 异常管理模块，因为不可能有意地测试所有这些模块（例如，无法强制产生总线错误来让异常处理单元介入）
- 分支预测、程序计数器和加载/存储单元；由于特定片上系统的内存映射配置，并非地址寄存器中的所有位都能被功能访问。
- 状态和控制标志，因为许多此类标志无法使用，其控制电路位于处理器核心之外。

子模块	故障数量	单通道1A FC [%]	同步1A FC [%]	单通道1B FC [%]	同步1B FC [%]	单通道2A FC [%]	单通道2B FC [%]	同步2A+2B FC [%]	单通道3 FC [%]
算术加法器	5,996	95.03	97.93	--------	98.27	–	98.52
分隔符	19,018	83.98	83.98	--------	83.99	–	84.82
逻辑指令	22,294	76.32	78.57	--------	78.70	–	83.34
乘数	78,094	91.18	92.62	--------	92.62	–	95.90
移位器	14,172	87.95	92.96	--------	93.97	–	96.32
异常	40,718	----	66.08	67.17	----	68.16	–	72.48
分支预测	24,489	----	70.91	70.95	----	72.67	–	72.67
定时器	7,683	----	88.21	88.43	----	88.46	–	89.70
寄存器组	83,764	–	71.21	----	84.15	–	89.38	–	92.66
寄存器端口	126,329	–	69.17	----	94.93	–	97.67	–	98.09
程序计数器	26,060	------	66.07	–	68.66	69.42	–	70.09
EA加法器	5,228	------	66.51	–	92.02	93.75	–	94.57
取指单元	71,582	------------	69.45	82.39	83.54
转发单元	84,758	------------	70.95	84.29	84.82
状态标志	33,277	------------	59.31	78.08	78.61
控制标志	10,328	------------	64.21	66.83	69.83
解码单元	62,876	------------	50.12	92.46	93.08
加载/存储单元	15,971	------------	73.50	75.42	76.73
胶合逻辑	19,425	----------------	63.36
总计	756,789	–	36.07	–	9.74	----	76.87	–	87.23

表2 开发流程中的覆盖率演变

作为故障覆盖率测量的补充，表3包含了在整个开发流程中测试的维度、持续时间和覆盖率。在150 MHz的工作频率下，执行全部73项测试所需的总时间约为0.8 ms。

值得注意的是，同步阶段对尚未考虑的模块产生了非常显著的正向级联效应；至少在接下来的生成步骤中将要被考虑的模块中，有一半的故障无需额外 effort 便已从列表中剔除。

表2还表明，如第4.2节所述，同步步骤也对同一分支当前及先前层级的模块带来了覆盖率的提升。

通过合理的设计开发顺序以最大化级联效应，可在缩短分级时间方面取得显著优势。例如，在1A（第1层—A分支）中包含的算术模块的139,574个故障上采用所提出的顺序生成的测试程序，对2A产生了积极的副作用，即在210,093个故障中有147,029个故障（约占70%）已被覆盖，而无需针对2A进行任何特定生成努力。换句话说，针对第2A层进行的故障仿真实验仅需考虑63,064个故障。

为了完整性，我们还计算了采用另一种生成顺序所得到的结果，即首先考虑2A模块，然后考虑1A模块。我们对寄存器组和端口的210,093个故障进行了处理，获得的故障覆盖率与表2中的结果相当，并评估了这些程序对1A模块的影响：在算术模块总共139,574个故障中，仅有10,318个故障（即7.4%）已被覆盖。

通过合理排序子模块并对故障列表进行同步，实现了故障列表基数的减少，从而因大幅降低故障仿真工作量而显著节省了时间。这种效果不仅限于连续同步，还允许按照进化算法的要求实现更快的生成迭代。

开发步骤	测试程序数量	持续时间 [周期]	Code size [kB]
单通道 1A	29	8,840	23
同步 1A
单通道 1B	8	19,716	11
同步 1B
单通道 2A	10	32,634	36
单通道 2B	8	28,212	17
同步 2A+2B	55	89,402	87
单个3	18	26,700	32
同步3	73	116,102	119

表3 测试程序数量、持续时间和代码大小

表4显示了两种情况下故障仿真所用的时间：
1) 一种原始的开发流程，不使用同步，而是简单地分别考虑子模块
2) 一种遵循建议顺序并在层级之间实施同步的开发流程

所有实验均在2 GHz处理器的单核上执行；通过运行多进程故障仿真，所需时间将减少。

值得注意的是，如果不实施同步，故障模拟时间将变得过度。

此外，开发顺序对于最小化故障模拟工作量非常重要。再次假设在第一级分支A之前考虑了二级分支A，则故障模拟节省的CPU时间从约37小时减少到34小时，与正确顺序相比，这是可忽略的增益。

故障仿真时间 [小时]	1) 无同步	2) 有同步	已保存 time
一级分支A	37	-
一级分支B	122	-
二级分支A	217	55	74.7%
二级分支B	72	23	68.1%
三级	630	195	69.0%

表4 有同步与无同步方法的CPU时间比较

5.3 任务期间的测试部署

上述开发阶段产生的测试程序套件已集成到意法半导体的一个工业演示项目中。该项目通过两个软件模块来管理完整的测试程序集，并为项目集成商提供了一个软件应用程序编程接口（API），以便将其集成到任务应用中。
- 上电测试：44个测试程序，包括非关键测试和关键测试，由名为启动时自检模块（BTSTM）的专用软件模块调度
- 运行时测试：29个运行时测试程序，由AUTOSAR 4.0复杂驱动器处理[26]名为CST库。

CST库和BTSTM均在编译时提供配置能力，使得项目集成商可以选择性地激活全部程序或整个套件中的子集。API用户需选择适当的测试组合和调度执行顺序，以满足系统的安全要求。

在设计的演示中，上电测试执行完成后（耗时约0.7毫秒），运行时测试根据任务集成的一些特定要求进行了调度：
- 自检块必须小于5微秒
- 每500微秒自检中断一次任务应用

在任务中，使用所提出的演示设置，整体自检长度不超过100微秒，且完整的自检在2毫秒内完成。即使该自检可随时被抢占，任务应用的可用性仍降低了约1%。

在开发过程中，演示测试套件包含了多个验证和确认阶段，以实现软件的成熟度，其中包括通过特殊注释（例如 Doxygen标签[27]）对代码进行嵌入式文档记录，这些注释由外部工具解析，用于自动生成用户手册。

测试程序还提供返回测试结果的服务，即由测试程序计算出的AUTOSAR DEM错误和故障特征码，用于后续对失效芯片的检查。BTSTM假设所有可用的处理器功能均可专用于测试目的；而CST库则具有更严格的限制要求。

为了验证，我们最终进行了两种模拟系统现场行为的实验：
1) 为了验证无故障行为，考虑了一个示例操作系统，该系统在自检按上述定期执行的同时，频繁触发任务中断；一个物理目标被编程加载了这样一个完整的软件环境，并持续运行数小时，跟踪测试响应的正确性以及系统的活性
2) 为了研究在故障情况下的鲁棒性，通过完整的仿真（即不丢弃故障）进行了一次特定的故障注入实验，以对错误行为进行分类，如第3.3节中先前介绍的那样：
a) 自检以错误签名结束
b) 由于死锁配置，自检未结束
c) 由于以下原因导致自检在未经处理的异常管理下结束：
i) 执行了非法指令
ii) 在内存保护单元配置所保护的内存区域中出现错误分支