内容提要：此文为该连载系列的“下”篇章，在该专题连载的“上”篇章中，我们已经对安全故障的背景知识及识别方法有了较全面地了解及认知。那么在此文中，我们将对安全故障自动识别的具体案例进行研究，并结合实验设置及结果进行阐述。

概 要   

《汽车SoC安全故障的自动识别》专题连载共分为“上、下”两个篇章。此文为该连载系列的“下”篇章，在该专题连载的“上”篇章中，我们已经对安全故障的背景知识及识别方法有了较全面地了解及认知。那么在此文中，我们将对安全故障自动识别的具体案例进行研究，并结合实验设置及结果进行阐述。

1、案例研究：AutoSoC基准套件

我们将提出的应用程序相关安全故障的识别方法，在AutoSoC标准套件上进行评估。AutoSoC是一个开源测试套件，以可配置SoC的形式，整合了所有必需的组件。该套件通过提供各种硬件配置、安全机制和代表性软件应用程序来支持汽车领域的研究。在本节中，我们详细说明其CPU和其他功能块。

1.1.AutoSoC架构

AutoSoC根据汽车领域使用的商用CPU的特性开发，具有两个主要处理单元，即安全岛和应用专用模块，如图1所示。安全岛处理ISO26262相关的所有安全关键进程，而应用专用模块是执行应用程序进程的硬件。需要强调的是，安全岛和应用程序模块具有专用的软件堆栈来执行不同的应用程序。而且，交互模块为内部通信部署Wishbone总线。此外，图1中的其余模块用来满足通信、网络安全和通用基础设施的要求。

由于AutoSoC是模块化的，因此它具有多种配置，我们使用的是一个叫做AutoSoC QM的配置。

此配置是对标套件的全功能版本。按照图1所示的AutoSoC的功能模块划分，AutoSoC QM配置只有应用专用模块，但我们的工作适用于AutoSoC的所有可用配置。

AutoSoC开发中使用的主CPU是OpenRISC的mor1kx实现。该实现提供了开发SoC所需的所有工具和示例，例如CPU、内存、调试单元、通信协议和总线。在软件资源方面，AutoSoC包含了多种选择，有的来自mor1kx封装，有的根据汽车功能安全分析自行开发。显然，这些软件资源既可用作BareMetal，也可用作多处理器系统(RTEMS)实时操作系统的实时执行程序。此外，我们还开发了巡航控制应用(CCA)，用于安全故障识别。该应用程序基于BareMetal和RTEMS操作系统，涵盖多项任务：从UART和CAN读取车辆传感器数据、计算执行命令和设置发动机参数。此外，AutoSoC具有针对CPU (mor1kx_cpu)的STL程序，这些STL程序是为AutoSoC的在线测试开发的。而且，开源AutoSoC包中提供的可用STL包含16个测试程序。

最后，AutoSoC在寄存器传输级（RT-Level）和门级都可用。使用Cadence GPDK045（45nm CMOS通用工艺设计套件）进行合成。本文提出的方法使用AutoSoC的门级模型进行了演示。

图1. AutoSoC功能模块。

1.2.串口IP

AutoSoC套件包括一个UART IP，它融合了行业标准National Semiconductors的16550A设备功能。此外，由于它是业界和学术界广为人知，且广泛使用的通信标准，我们的安全故障识别方法也扩展到了UART。

UART是一个电路模块，它采用可配置速度的异步串行通信。同时，它通过从外围设备或CPU接收数据来进行数据传输。此外，UART包括一个中断系统和控制功能，可最大限度地减少通信链路的软件管理。而AutoSoC中使用的UART IP，在与Wishbone总线完全兼容的32位总线模式下运行。如图2所示，UART内核由接收逻辑、控制和状态寄存器、调制解调器控制模模块、发送逻辑、波特发生器逻辑和中断逻辑组成。其中，传入的串行消息由RX移位寄存器接收，其波特率可通过波特发生器逻辑进行编程。如果传入的报文没有问题，则接收到的报文被放置在接收FIFO模块中。相反，TX移位寄存器处理写入传输FIFO模块的数据传输。此外，控制和状态寄存器允许规范和监测所使用的异步数据通信的格式。而调制解调器控制可以将控制信号传输到UART的调制解调器寄存器。UART IP则还有波特率发生器逻辑模块来控制发送和接收数据速率。最后，中断逻辑允许通过UART启用和禁用中断生成。

AutoSoC基准套件包括上述UART IP和一些测试程序，用于试验UART的功能，为研究人员开发和验证他们的方法提供了基准。

图2. UART IP框图。

1.3. CAN控制器IP

CAN是博世于1986年推出的一种通信总线标准。在汽车领域广泛用于控制器单元之间的串行通信。CAN有几个好处：成本低，具有自诊断和修复数据错误的能力。这些特性促进了CAN在汽车和其他一些行业（如医疗或航空航天）中的普及。由于它具有汽车行业的代表性，我们在CAN上验证所提出的安全故障识别方法。

AutoSoC对标套件采用SJA1000的开放式硬件实现，它是飞利浦半导体在2000年代初期开发的CAN独立控制器。图3显示了SJA1000 CAN的框图。CAN收发器是将其他节点连接到CAN的模块，CAN控制模块控制CAN帧的接收和发送。接口管理逻辑通过其寄存器集将CAN接口实现为与主机CPU的链接。此外，该模块配置CAN的运行模式，或者工作在BasiCAN模式或者在PeliCAN模式下。同时，发送缓冲区以扩展格式或标准格式存储消息。每当接口管理逻辑提出请求时，CAN控制模块就从发送缓存区读取消息。接收过滤器在接收消息时变得十分重要，它检查总线上的消息是否必须由CAN存储。并将所有接收到的消息，都存储在接收FIFO中。

由于AutoSoC套件使用Wishbone总线，因此采用CAN直接连接，无需在不同总线接口之间建立桥接。当需要添加另一个节点与主机CPU通信时，CAN收发器提供了一种直接的连接方式。此外，AutoSoC套件为CAN的自检提供了STL。STL基于功能方法对CAN实施有效的现场测试，并提供证据来证明其有效性。

图3. 采用的SJA1000 CAN控制器IP框图

2、测试环境搭建

本节首先描述了我们用来定量评估所提出方法的有效性的实验装置。然后，我们重点讨论CPU、UART、CAN以及最后的组合结果。

2.1 环境配置

为了证明所提出的App-Safe故障识别方法的有效性，我们使用了图4所示的环境配置。我们的装置由两个AutoSoC节点组成：每个都包含一个CAN和一个UART IP用来相互通信，并且假设两个AutoSoC（名为AutoSoC-0）中的一个是主动的，另一个（名为AutoSoC-1）是被动的。此外，CCA访问AutoSoC-0和AutoSoC-1中的CAN或UART。因此，每个CCA都有两种模式，即使执行的步骤是对称的。两个AutoSoC节点在相同的配置中，交替接收和发送消息。此外，在我们的实验中， AutoSoC-0首先接收消息，AutoSoC-1首先发送消息。最后，在门级对整个系统进行仿真。

关于EDA工具，我们使用Cadence Xcelium™ 进行逻辑仿真，使用Cadence® Integrated Metrics Center (IMC)进行覆盖度分析，使用Cadence® JasperGold® 功能安全验证(FSV) App进行形式分析，以及使用Cadence® Xcelium™ 故障仿真器(XFS)用于故障仿真。这些方法也适用于其他工具流程。

简而言之，我们首先使用前面描述的硬件配置执行逻辑仿真，它使用不同的输入数据集运行CCA SW应用程序，如专题“上”中的图4所示。然后，生成覆盖率报告，并将其转换为给定应用程序的形式属性，根据软件应用程序的行为配置形式分析环境。最后，部署正式的分析工具来识别App-Safe故障。

图4. 由两个AutoSoC节点组成的实验装置

2.2. 实验结果

本小节分别介绍了CPU、UART和CAN中已识别的安全故障。然后，报告CPU和CAN模块的组合结果“故障模仿真+形式分析”（此步骤不包括UART分析）。

2.2.1. CPU中的安全故障

首先，在运行软件应用程序时，在CPU内核（总共有96354个故障）中检查App-Safe故障识别。我们在表1中总结了CPU的安全故障。

表1根据我们运行的分析，对结果进行了分类。在第一行，可以看出我们进行了如下四次分析：

•独立于应用程序：形式分析工具部署在AutoSoC的门级网表上，没有任何形式属性，这意味着已识别的安全故障对任何软件应用程序都有效。

•BareMetal-CCA：CCA运行BareMetal，即在没有操作系统支持的情况下，直接在CPU上运行SW应用程序。为了执行此分析，AutoSoC的门级网表和形式属性（如此专题“上篇章”的第3.1.2节所述）做为形式分析工具的输入。

•RTEMS-CCA：与BareMetal-CCA不同，在此分析中，SW应用程序在操作系统上运行，这意味着它可以同时启动和停止不同的进程。

与BareMetal-CCA相比，RTEMS-CCA会导致更高的信号活动，因为它在触发更多信号的操作系统上运行。此外，与BareMetal-CCA相比，RTEMS-CCA使用了两个额外的操作码。这意味着RTEMS-CCA比BareMetal-CCA触发更多的设计组件。

•BareMetal-Sum：对于这个分析，我们使用与CCA完全不同的软件应用程序。该应用程序执行求和运算，它的操作码比BareMetal-CCA少。此SW应用程序，旨在展示当CPU运行不同的应用程序时App-Safe故障如何变化。

简而言之，App-Safe故障源于SW应用程序在IC中执行的操作。例如，在设计的使用寿命期间，某些设计组件无法访问，例如调试单元或扫描链。此外，未使用的操作码会导致App-Safe故障，这意味着如果在IC上运行的SW应用程序中未使用乘法操作码，则所有与乘法硬件相关的信号都会成为App-Safe故障，因为它们没用上。表1报告了CPU内核的结果，还详细说明了在其中的每个组件模块上取得的结果。在与应用程序无关的分析中，形式分析工具能针对CPU中的所有故障识别出8.785%的安全故障。我们强调，在与应用程序无关的分析中，识别出的所有安全故障都是Str-Safe故障，因为形式工具无法使用此专题“上篇章”的第2.3.2节中所提到的，没有形式属性的形式故障分析检查类型来识别任何安全故障。

关于三个依赖于应用程序的分析（BareMetal-CCA、RTEMS-CCA和BareMetal-Sum）：

•顶层模块包括连接信号和配置相关信号。其中，调试单元的地址和数据信号、中断请求信号、多核配置信号、专用寄存器信号，在所有分析中都被确定为安全的，因为它们由于软件应用配置而未被激活。根据应用程序中使用的操作码，BareMetal-CCA、RTEMS-CCA和BareMetal-Sum略有不同。例如，RTEMS-CCA触发异常信号，这些信号连接到顶层。

•Decode_execute Unit是指令内存管理单元(IMMU)和数据内存管理单元(DMMU)信号参与的模块。在IMMU和DMMU中识别出许多安全故障，但SW应用程序未使用这些故障。如上所述，由于RTEMS-CCA使用的异常信号，所以BareMetal-CCA和RTEMS-CCA之间的安全故障数量不同。另外，BareMetal-CCA和BareMetal-Sum之间的偏差是由于除法和乘法相关的信号，而BareMetal-Sum并未使用这些信号。

•加载-存储单元计算加载和存储指令使用的地址。可能存在安全故障，因为并非所有地址都被SW应用程序使用。此外，某些连接信号会在BareMetal-CCA和RTEMS-CCA之间产生细微差别。

•提取阶段，将下一条指令从内存中提取到指令寄存器中。因此，它与地址范围直接相关，软件应用程序没有完全覆盖。因此，可以在该单元中识别安全故障。此外，BareMetal-CCA和RTEMS-CCA的区别在于异常信号。

•控制阶段，对已识别安全故障的数量影响最大。该单元包含滴答定时器、中断和配置寄存器等功能。由于所有应用程序中的CPU配置都相同，因此配置寄存器会产生相同数量的安全故障。但是，tick-timer单元在RTEMS-CCA中具有更高的活动性；因此，当CPU运行RTEMS-CCA时，它的安全故障较少。

•关于算术逻辑单元，所提出的技术在BareMetal-CCA和RTEMS-CCA中识别出相同数量的安全故障，因为它们使用相同的算术操作码。但是，BareMetal-Sum只执行加法运算；因此，所有其他算术运算都会导致安全故障。

•解码单元直接受使用的操作码影响；因此，安全故障的数量存在差异，因为所有三种分析都使用不同数量的操作码。

表1中的结果表明，安全故障的百分比因模块而异，具体取决于模块执行的任务。此外，与App-Safe故障数量相关，在BareMetal-CCA、RTEMS-CCA和BareMetal-Sum应用中分别占20%、14%和40%左右。

表1. CPU 中的安全故障

2.2.2. UART中的安全故障

对于总共有19120个故障的UART模块，我们按照相同的流程比较了两个场景（独立于应用程序，运行CCA），结果如表2所示。我们还注意到BareMetal和BareMetal之间没有区别，因此我们仅将已识别的安全故障列入表2中的CCA。简而言之，所提出的技术识别出11.088%的安全故障，这是独立于应用程序的分析的两倍。

更具体地说： 

•regs单元具有配置寄存器，其值在初始化阶段写入。由于UART配置在CCA中是固定的，因此UART的某些部分未使用；因此，可以在该单元中识别出几个安全故障。

•发射器模块中的安全故障源于传输格式的配置，例如选择的波特率。因此，当软件应用程序被修复时，可以在本单元中找到更多安全故障，如本工作所示。相应地，发送器FIFO部分受这些因素的影响。

•关于直接受配置寄存器影响的接收器模块，观察到的安全故障数量显著增加。这主要源于接收模块负责产生中断的事实。但是，CCA在轮询模式下工作，不使用中断。此外，接收器模块具有调制解调器配置，而CCA不需要这种配置。通过扩展，接收器FIFO会受到部分影响，类似于发送器FIFO。

表2. UART IP中的安全故障

2.2.3. CAN中的安全故障

对共有38012个故障的CAN模块进行了相同的分析，结果如表3所示。在独立于应用程序的分析中，形式分析工具只能将所有故障的1.415%归类为安全故障。另一方面，当采用我们的方法时，安全故障的数量增加到12.909%，这是不可忽略的。

与UART类似，CAN中的安全故障数量直接受其配置影响。在CCA中，我们将CAN配置为在具有扩展帧格式消息的peliCAN模式下工作。当使用basiCAN模式时，可以识别出更安全的故障。下面明确地说明表3中给出的结果：

•Acceptance_code_mask定义是否将相应的输入位与acceptance_code_regs中的相应位进行比较。同样，bus_timing_regs定义波特率预分频器的值，并对CAN系统的周期进行编程。此外，clock_divider_regs控制微控制器的时钟频率，并允许停用时钟引脚。另外，CCA工作在轮询模式下，因此可以在IRQ寄存器中找到安全故障。因此，在初始配置后不应更改所有这些寄存器；同时，这会产生额外的安全故障。

•位时序逻辑直接受上面解释的bus_timing_regs影响，因此CCA在本单元中导致了一些安全故障。

•比特流处理器对应外设的控制和处理单元。它是一个控制发送缓冲器、接收FIFO和CAN总线之间的数据流的定序器。此外，错误检测、仲裁、填充和错误处理都在这个单元中完成。另外，比特流处理器受配置的影响，比如CAN的工作模式，又比如监听模式或者自检模式。CCA不使用这些模式，这些模式提供了表3中所示的安全故障。

•接受过滤器检查当前在总线上的消息是否必须由外围设备存储。如果消息被接受，则将其存储在FIFO中。换句话说，比特接受过滤器及其FIFO与acceptance_code_regs和acceptance_code_mask有关；因此，这些寄存器的固定内容会引起安全故障。

表3. CAN控制器IP中的安全故障

2.2.4. 总结：故障仿真和形式分析

在这一步中，我们将故障仿真和形式分析结合起来，来检查DC的增加。此分析针对AutoSoC中的CPU和CAN模块。

如该专题“上篇章”的第2.2节所述，故障仿真不足以对所有故障进行分类，因为用于故障仿真的工作负载无法激活和传播所有故障。因此，由于故障仿真，一些故障变得不能被检测到。需要分析这些未检测到的故障，以检查是否达到了所需的DC。如果DC不符合要求，则必须使用替代方法重新分析未检测到的故障，例如本工作中提出的技术。简而言之，此步骤的目的是，表明所提出的技术可以增加DC，以达到给定汽车安全完整性级别所需的数字。

为了进行这种分析，我们采用了STL形式的基于软件的自检(SBST)方法。在所考虑的场景中，AutoSoC在现场运行BareMetal-CCA，而STL在激活时会强制处理器执行正确的指令序列。然后，根据生成的结果生成签名，如果出现故障，应用程序可以将其与预期结果进行比较。

为AutoSoC CPU开发的STL是57个测试程序的组合。STL是作为一组任务开发的，这些任务既可以独立运行，也可以共同运行，具体取决于自检时间段。

应用以下步骤：

•首先，使用Cadence® JasperGol®功能安全验证(FSV)程序识别Str-Safe故障。

•其次，我们使用Cadence® Xcelium™ 故障仿真器在AutoSoC CPU和CAN模块的单元端口注入SA0和SA1故障，这些模块将STL作为工作负载运行。因此，故障被分类为检测到或未检测到。

•第三，使用(1)计算DC。

•第四，从未检测到的故障中，排除之前识别的应用程序安全故障。此过程是增量的，始终关注以前未检测到的故障。

•最后，使用(1)及使用新获得的数字再次计算DC。图5和图6详细说明了STL效率的结果，以及在识别App-Safe故障时DC的上升趋势。关于CPU中的分析，图5显示一开始就识别出8465个Str-Safe故障。然后，在部署故障仿真时，将检测到的71255个故障和16634个未检测到的故障分类。故障仿真后，DC为81.07%，按照（1）计算。然后，通过形式化方法应用安全故障识别技术，识别出5627个App-Safe故障，即将未检测到的故障减少到11007个。再次计算(1)，DC增加到86.62%。在CAN中进行了类似的分析，如图6所示。结果，DC从88.04%增加到91.97%。

图5. CPU的结果：当故障仿真和形式分析相结合时，DC呈上升趋势。

图6. CAN的结果：当故障仿真和形式分析相结合时，DC呈上升趋势。

我们提出的技术，似乎是一种通过安全故障识别对未检测到的故障进行分类的有前途的方法。结果表明，CPU的DC提高了约6%，CAN提高了4%。此外，凭借91.97%的最终DC，CAN无需修改设计即可达到汽车ASIL B硬件组件的要求。

2.3. 讨论

安全标准（例如，ISO26262）要求对达到的安全水平进行估计，这反过来又需要识别安全故障。本文为自动识别CPU和外围设备中的安全故障提供了一种新技术。所提出的技术可以显著降低安全故障识别的成本和工作量，表明该方法可以识别大量安全故障。

该方法的主要优点是，其采用了具有代表性的汽车硬件和软件应用程序进行安全故障识别的自动化方法。该方法减少了基于专家的人工分析的限制，因此同时降低了验证工作的时间和复杂性。这也有助于缩短上市时间，这是IC设计行业面临的最大挑战之一。此外，所提出的方法是系统的，建立在逻辑仿真和形式分析的基础上，由工业级工具支持，适用于汽车行业和功能安全验证。它可以进行准确的安全指标评估，符合ISO26262功能安全要求。缺点是没有关于要运行的逻辑仿真数量的分析计算。我们在工作中使用不同但真实的输入数据序列，运行了几个逻辑仿真（如此专题“上篇章”的第3.1.1节所述），并在覆盖率报告相同时停止运行新的逻辑仿真。此外，关于所提出技术的计算复杂性，它取决于形式分析评估的故障数量。

3、结论

功能安全验证是一项至关重要且不可妥协的要求，必须在整个安全关键IC设计周期中加以考虑。因此，制定了ISO26262功能安全标准来指导如何实施这一要求。根据ISO26262，随机硬件故障可能在IC的生命周期内发生不可预测的情况。因此，必须根据其影响对随机硬件故障进行分类，即它们是否会破坏任何安全关键功能。然而，这种分类过程既昂贵又容易出错，因为它需要结合工具和专家的设计知识提供的输入。本文中提出的方法为这一挑战带来了解决方案。

我们提出的方法侧重于在运行单个软件应用程序时识别SoC上的安全故障。我们通过识别与应用相关的安全故障来扩展功能安全故障。显然，该流程依赖于通过逻辑仿真和形式化方法进行的代码覆盖分析。而且，该方法从分析代码覆盖率开始了解目标系统的运行行为。换句话说，首先通过代码覆盖分析来识别不干扰任何安全关键功能的故障。然后，将代码覆盖率结果转换为形式属性，再将其转换为形式分析工具，从而约束环境以识别安全故障。当巡航控制应用程序运行时，使用其CPU、UART和CAN在AutoSoC上测试了该方法。

我们计算了已识别的安全故障的数量（特别关注stuck故障）。此外，我们结合故障仿真和所提出的形式化技术来证明诊断覆盖率的提升。CPU、CAN和UART模块的安全故障数量分别占20%、11%和13%。诊断覆盖率在CPU和CAN模块中分别增加了6%和4%。该分析还证明，对于相同的STL，CPU和CAN的未检测故障数量减少了1.5-1.6倍。显著增加了SoC的诊断覆盖率。在未来的工作中，还需要分析具有各种场景的不同汽车代表性软件应用程序。此外，将创建FMEDA，并在识别安全故障时，计算安全量化指标。与此同时，还将部署针对AutoSoC和外围设备的不同STL，并分析安全级别的提升情况。

有兴趣的朋友，可以添加牛小喀微信：NewCarRen，加入专家社群参与讨论。

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！