专业术语

SM（Security Manager）：安全机制。
DCLS（Dual-Core Lockstep）：双核锁步，用于 CPU 的最常见安全机制。
UART（Universal Asynchronous Receiver-Transmitter）：通用异步收发器，它将要传输的资料在串行通信与并行通信之间加以转换。作为把并行输入信号转成串行输出信号的芯片，UART通常被集成于其他通讯接口的连结上。
JTAG（Joint Test Action Group）：是—种国际标准测试协议，主要用于芯片内部测试。
RTEMS（Real Time Executive for Multiprocessor Systems）：实时多处理器系统，是一个开源的无版税实时嵌入操作系统RTOS。

概述

AutoSoC是一个开源测试套件，以可配置SoC的形式，整合了所有必需的组件。该套件通过提供各种硬件配置、安全机制和代表性软件应用程序来支持汽车领域的研究。
第一节描述了基于工业解决方案特征的 AutoSoC 功能要求的定义。
第 二、三、四 节中，描述了它的基本硬件和软件组件、安全组件和可用的基准配置。
第五节概述了针对不同 ASIL 配置的初步功能安全分析。

1. 汽车 SOC 架构

1.1 行业解决方案

汽车生态系统包括信息娱乐、动力系统、网络通信、驾驶任务自动化等，这些需要考虑功能安全和安全方面的问题。虽然有不同的商业解决方案，但架构具有相似性。文章通过探索这些相似性来定义汽车SoC的需求。一般来说，分析可以分为以下几个领域:

1)硬件架构:通用架构特点;
2)安全性:soc的哪些组件考虑功能安全合规性，以及通常实施哪些安全机制;
3)保密性:有哪些安全特性可用;
4)其他:常用外设(如通信协议、图形处理器、音频/视频dsp)。

CPU

在评估的解决⽅案中，⼀个显着的共同特征是多个 CPU 的可用性。
通常,专用硬件组件可用于安全关键和特定于应用程序的操作。这个概念允许为具有高处理需求的应用程序（例如视频处理）部署功能强大的CPU，而安全关键型应用程序则在具有专用安全机制的CPU中执行。例如，瑞萨R-Car M3包括两个用于普通应用的CPU和一个用于安全关键应用的双核锁步 CPU。英飞凌AURIX和德州仪器TDA2SG采用了类似的概念，包括一个CPU和用于专用功能的分离核心。
双核锁步(Dual-Core Lockstep, DCLS)是cpu最常用的安全机制。

存储器

对于存储器，包括 RAM 和⾼速缓存，工业解决方案通常部署纠错码 (ECC) 和奇偶
校验。 DCLS、ECC 和 Parity 在功能安全分析方面具有优势。

其他组件

其他组件可归类为通信协议、特定应用、安全和基础设施外设。

• 商业解决方案可实现多种通信外设，包括 CAN 和 FlexRay 等汽车协议，以及以太网、SPI 和 I2C 等通用协议。
• 大多数SoC旨在用于高级驾驶辅助系统(ADAS)应用,因此它们包括GPU、视频编解码器、图像处理单元和音频DSP等外围设备o在安全领域,除了未详细说明的专有功能外,最常见的组件是密码引擎,如高级加密标准(AES)数据加密标准(DES)、哈希等,此外,一些解决方案还提供访问控制功能,例如防火墙和受保护的内存区域。
• 此外，每个分析的解决方案都包括 JTAG、UART、GPIO 和调试组件等基础设施外设。

考虑到所评估的商业解决方案的特点，可以定义一组可以被视为汽车行业所需的通用功能。安全相关组件、特定应用单元、汽车协议和安全内核的添加可以作为代表性汽车SoC的基本功能集。在评估的商业解决方案中发现的共同特征总结见表1：

1.2 AutoSoC功能模块

功能块的定义旨在涵盖代表性汽车基准套件所需的最少功能集。AutoSoC是模块化的，因此它具有多种配置。不同版本的 AutoSoC 可以部署不同的硬件组件来覆盖每个功能块的需求。
AutoSoC 功能块如下：

两个主要单元

与大多数商业解决方案一样，AutoSoC有两个主要处理单元:

①安全岛(Safety Island) 安全岛处理ISO26262相关的所有安全关键进程。它由cpu和内存组成，根据ISO 26262的要求，必须由安全机制覆盖。
②应用专用模块(Application Specific Block):应用专用模块是执行应用程序进程的硬件，它可能包括用于高要求应用程序的 CPU 和内存、用于视频应用程序的 GPU 和图像处理单元等。每个给定 AutoSoC 配置的目标功能将定义特定应用程序块所需的硬件组件。
需要强调的是，安全岛和应用程序模块具有专用的软件堆栈来执行不同的应用程序，交互模块为内部通信部署Wishbone总线。

其余模块

其余模块实现通信、安全和通用 SoC 基础设施。

①Automotive Block：汽车模块负责SoC与车载系统的通信。车载通信最常用的协议是CAN。但是，也可以实现其他选项，如FlexRay、LIN、汽车以太网等等。
②Security Block：安全块负责执行AutoSoC的所有安全相关功能。最常见的应用是加密核心，如AES和DES。
③Infrastructure Block：基础结构模块负责SoC的在线运行状况监视。它包括诸如JTAG和UARTs之类的调试特性，以简化开发过程。
④Interconnect Block：互连块负责内部 SoC 通信。它可以部署常见的通信总线， 如 AXI 和 Wishbone，或更高级的选项，如片上网络 (NoC)。

2. Autosoc基础组件

名为 AutoSoC QM 的基准测试的初始配置是通过仅部署基本组件来设置的。 AutoSoC QM 是基准测试的全功能版本，可作为进一步配置的基础。

2.1 硬件组件

项目部署了 OpenRISC（mor1kx 实现）作为主要 CPU。
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个测试程序。
OpenRISC社区为SoC的开发提供了工具和示例。作为其中的一部分，有一个基于mor1kx CPU的示例。SoC该套件包括CPU内存、UART、JTAG和调试单元，所有这些都通过Wishbone总线连接。此外，示例SoC包含一个测试台，具有将软件应用程序加载到内存并通过JTAG连接到调试单元的功能。此示例用作 AutoSoC的基础，通过部署示例，我们可以覆盖基础设施和互连块。此外，我们可以重用部分提供的测试环境来加快开发速度。

2.2 软件资源

汽车功能安全分析的目标之一是避免随机硬件故障对系统安全相关功能的干扰。对于 SoC，由 CPU 执行的软件应用程序定义了功能。因此，软件堆栈是功能安全分析的重要组成部分。当前版本的 AutoSoC 包括几个软件选项。目的是将可用资源和我们自己开发的应用程序集成到 AutoSoC 仿真环境中的统一存储库中。通过适当设置配置文件，可以模拟所有可用的软件应用程序。
AutoSoC 包括几个按文件夹组织的软件资源：

• Baremetal 文件夹包括 Makefile、驱动程序和大约 50 个已编译测试应用程序等开发资源。
• Linux 文件夹中已编译的 Linux 内核（可在模拟中启动）可用。
• RTEMS 文件夹包含一个开发环境，其中包含 Makefile、驱动程序和应用程序。
  

最后，开发了汽车巡航控制应用程序。该应用程序基于 RTEMS 操作系统。它包括四个实时任务，用于读取车辆传感器数据、计算驱动、设置一些发动机参数和内务处理。

3. Autosoc安全组件

基准的另一个重要方面是安全岛安全机制的可用性。由于此块负责执行安全关键型应用程序，我们需要确保可以检测到潜在的错误，从而避免对预期功能的可能损害。CPU作为安全岛的主要单元，是安全评价的主要对象。设计了不同的安全机制方案，每个方案针对不同的汽车安全完整性等级(ASIL)。

3.1 双核LockStep

第一个选项部署时间分集双核锁步 (DCLS) 作为主要安全机制。 DCLS 配置包括 CPU 的冗余副本、用于时间分集的延迟单元和用于故障检测的比较单元。图 2 说明了具有时间分集的 DCLS 的实现。

主处理器的性能不受 DCLS 实施的影响。主 CPU 是唯一具有总线写入权限的 CPU，它控制着 SoC 的功能。另一方面，影子 CPU 不对 SoC 资源执行任何写访问。相反，影子 CPU 的输出仅由比较单元用于故障检测。如果两个处理器的输出不匹配，比较单元会激活警报。

尽管包括 DCLS 的额外故障覆盖范围，我们仍然需要考虑共模故障的影响，这些故障可能会影响两个处理器并且无法通过比较它们的输出检测到。为了最大限度地减少共模故障的可能性，DCLS 机制包括时间分集。时间分集通过在影子处理器的执行中应用延迟来工作。延迟是通过在CPU的驱动信号中包含一个延迟单元来获得的。延迟单元也被添加到主处理器的输出，以对齐比较单元的两个核心输出。延迟单元可以配置所需的时间偏移：当前版本对所有信号应用 2 个时钟周期的延迟。影子 CPU 执行延迟配置必须考虑最大容错时间的系统要求。由于此延迟也应用于比较单元的输入，因此只有在配置的延迟后才会检测到 CPU 输出之间的不匹配。

双核锁步是针对 ASIL D 应用程序的处理器最常用的 SM 方案。然而，并非所有应用程序都需要 ASIL D 以及包含 CPU 冗余副本的额外成本。因此，AutoSoC 结合了针对不同 ASIL 要求的额外配置。

3.2 软件测试库

Software Test Libraries 软件测试库，也称为STL，是在开机（keyon）、关机（key-off）或定期运行的软件测试的集合，以防止故障导致单点故障或防止它们由于多点故障而成为潜在故障。
该软件机制旨在检测在安全应用程序执行期间随时可能发生并可能导致安全违规的永久性故障。一个 STL 对应一组软件程序，通常用汇编代码、C 代码或两者的组合开发。这些可以在启动时或运行时执行。在前一种情况下，它们需要管理员功能，因此，为了避免与操作系统 (OS) 发生冲突，通常在开机和关机期间执行。另一方面，当 STL 在运行时执行时，它们必须与操作系统共存。然后，必须让这些测试在短时间内运行，通常是几毫秒，以避免影响在同一硬件上运行的其他软件应用程序的行为。
当硬件空闲或运行时间敏感度较低的应用程序时，软件调度程序将按指定的时间间隔安排这些测试。

3.3 内部ECC

通常，在复杂的 CPU 中，内部存储器占据物理设备上的最高区域。由于组件大小与故障概率直接相关，因此内部存储器是 SM 的主要目标。 ISO 26262 标准包括对众所周知的内存安全机制的建议。根据行业解决方案特性的建议和发现，错误检测纠正码 (ECC) 被选为保护 CPU 内部存储器的选项。安全岛 CPU 的当前实施包括七个内部 RAM 块。在 CPU 的 RT 级表示中，内部存储器共同代表了总故障目标的 91.3%。
在所有内部存储器上部署具有高诊断覆盖率的 SM，如 ECC，将为整个 CPU 提供令人满意的覆盖率

3.4 外部ECC

还必须验证安全岛的其他元素是否存在单点故障的可能性。通常，软件应用程序必须加载到外部存储器才能由 CPU 执行。此外，应用程序利用内存来存储数据和控制参数。
由于软件应用程序功能依赖于外部 RAM，因此内存故障会对预期功能产生直接影响。外部 RAM 也必须由 ECC 覆盖，以避免将内部存储器故障传播到安全岛的输出。

3.5 总线奇偶校验

数据总线负责内存和CPU之间的数据传输。因此，数据总线中的故障可能会传播到 CPU 或内存，而不会被它们的 SM 检测到。为了避免这些情况，包含了一个奇偶校验器来覆盖 CPU 和内存之间的数据传输。奇偶校验器监控数据总线传输，并为 CPU 和内存之间的所有通信计算奇偶校验位。奇偶校验位通过奇偶校验块之间的直接连接传输。如果奇偶校验错误，则会设置警报以通知系统。

3.6 检查点控制

即使使用了 DCLS SM，两个 CPU 也可能卡在同一个软件指令中，并且上述 SM 都无法检测到此故障。为此，实施了检查点控制安全机制。检查点控制监视数据总线，期望特定内存位置中的预定软件签名。该机制作为硬件看门狗工作，而不是期望来自软件应用程序的单次刷新，它期望每个软件任务都有不同的签名。因此，SM 不仅能够验证软件应用程序是否正在运行，而且能够验证控制流是否符合预期。检查点控制在细化过程中是完全可定制的，允许定义软件签名、预期顺序和截止日期。

3.7 安全监视器

最后，开发了一个安全监视器块来集成所有检测警报。在任何 SM 检测到故障的情况下，安全监视器都会生成一个外部警报和一个错误代码，以指示检测到故障的位置。图 3 说明了 AutoSoC 安全配置的架构，包括 DCLS、外部存储器 ECC、总线奇偶校验和检查点控制。

4. AUTOSOC配置

本节概述了可用的基准配置以及如何通过启用不同的安全组件来设置它们。可用配置符合功能块：安全、汽车、基础设施和互连(如图 1 所示，Safe, Automotive, Infrastructure and
Interconnect)。特定应用程序块和安全块将在我们工作的下一阶段开发。 AutoSoC 的模块化设计允许在以后的配置中重用在本文范围内执行的功能安全分析。
作为其模块化概念的一部分，通过启用上述组件的不同组合，可以实现 AutoSoC 的多种配置。要根据提供的模拟文件夹定义新配置，用户必须在详细配置文件中选择硬件组件，选择软件应用程序并通过将定义添加到“plus args”配置文件来启用安全机制的任意组合（例如 +define+DCLS）。然后可以使用提供的 Makefile 详细说明和模拟新配置。尽管可以创建任何可能的组件组合，但我们已经为 AutoSoC 定义了一组初始配置。
这些配置基于行业解决方案中的常见 SM 组合。表 II 说明了 AutoSoC 的一些潜在配置。在本文范围内，我们对三种配置进行了初步安全评估。 AutoSoC ECC、AutoSoC STL 和 AutoSoC DCLS 配置作为针对不同 ASIL 级别的候选配置进行了分析（见下一节）。

5.初步功能安全分析

本节介绍 AutoSoC 的一些可用配置的功能安全分析。

5.1 AutoSoC DCLS 配置

硬件冗余方案，如双核锁步，由 ISO 26262 定义为处理单元的推荐安全机制。该标准定义了这些机制的典型诊断覆盖率很高，这意味着 99% 的随机硬件故障检测。DCLS 的实施应旨在通过逐步比较两个处理单元同步运作产生的结果来提供故障的早期检测。AutoSoC DCLS 配置旨在符合 ISO 26262 的描述。此外，时间分集的实施通过解决共模故障的影响来增加 DCLS 功能。
对 mor1kx cpu 描述的初步调查表明可能有 337,752 个可能的故障目标。如果我们考虑 SA0 和 SA1 故障模型，按照 ISO 26262 永久故障分析的要求，共有 675,504 个故障需要分析。 DCLS 安全机制旨在识别 mor1kx cpu 中的故障。根据 ISO26262 为 DCLS 定义的诊断覆盖率，我们可以假设 mor1kx cpu（主）中 99% 的故障将被锁步控制器检测到。凭借 99% 的故障覆盖率，我们可以预期 AutoSoC DCLS 是符合 ASIL D 要求的理想选择。表 III 说明了 AutoSoC DCLS 配置的潜在故障范围。

5.2 AutoSoC ECC 配置

ISO 26262 还包括针对易失性和非易失性存储器的安全机制的建议。其中一项建议是使用纠错码 (ECC) 部署内存监控。使用 ECC 或奇偶校验保护高速缓存是一种常见的设计实践。在 AutoSoC 设计中，考虑到 SA0 和 SA1 故障模型，内部存储器代表了 633,344 个可能的故障目标。这个数字占整个 CPU 故障目标总数的 93.7%。出于这个原因，添加SM 到内部存储器代表了对 CPU 故障的良好整体覆盖。 AutoSoC 内部 ECC 配置考虑了将 ECC 合并到所有内部存储器中。
表 IV 展示了每个内部存储块的 ECC 故障覆盖率。考虑到 ISO 26262 定义的 99% DC，ECC 涵盖的故障总数为 627,011 个故障。此覆盖率代表整个 CPU 的 92.8% 诊断覆盖率。这些数字说明 AutoSoC 内部 ECC 配置是符合 ASIL B 要求的良好候选者。

5.3 AutoSoC STL 配置

事实证明，部署软件例程来识别永久性故障在 CPU 的多个单元中是有效的。虽然通过部署 STL 并不总能达到 ASIL D 故障覆盖要求，但当与其他安全机制结合使用时，它们是一个很有吸引力的替代方案。汽车行业的一种常见做法是在 CPU 的内部存储器中将 STL 与 ECC 相结合。能够实现 84.4% 的永久故障覆盖率。 AutoSoC CPU 包含 42,160 个用于固定 0 和固定 1 故障的目标，不考虑内部存储器。如果我们考虑中的故障覆盖率，STL 将能够检测到 35,583 个故障。如果我们在 AutoSoC ECC 配置 VII-B 中包含 STL 例程，组合的安全机制将检测到 662,594 个故障。由于故障总数为 675,504，因此综合检测率表示诊断覆盖率为 98%。该图将使 AutoSoC STL 和 ECC 配置的组合成为符合 ASIL C 要求的良好候选者。

Reference

1.AutoSoC Benchmark Suite
2.AutoSoC Benchmark Suite – Description
3.汽车SoC安全故障的自动识别（上）：逻辑仿真和形式分析_NewCarRen的博客-CSDN博客4.汽车SoC安全故障的自动识别（下）：案例展示和指标分析_NewCarRen的博客-CSDN博客