功能安全入门-功能安全岛(FSI)

之前文章：汽车操作系统-现状及演进介绍了汽车上三大域对应的三个操作系统，同时也对应底层的硬件，车控OS的底层硬件突出了安全性，是传统旧势力的代表。智驾域和座舱域作为后来者当然都想吃掉车控域，统一三域才是最终目的啊。车控域虽然旧但是其一个护盾就是安全，也是智驾域（英伟达为代表）和座舱域（高通为代表）必须要跨越的阻碍。具体到硬件上就是智驾芯片或者座舱芯片上需要划出来一部分具有高安全性，先圈好地，才能把车控的应用挖过来嘛。

要跨越这个阻碍，一个利器就是功能安全。所以作为智驾芯片的英伟达Orin的一大亮点就是功能安全岛FSI。传统芯片公司想进军汽车行业，功能安全岛FSI也是必修第一课。之前介绍了功能安全规范ISO26262和GB_T 34590，本小节就来实例分析下。

1. NVIDIA官网介绍

官网介绍：

https://developer.nvidia.com/docs/drive/drive-os/6.0.9/public/drive-os-linux-sdk/common/topics/fsi_integration/Functional_Safety_Island.html

1.1 为什么需要FSI？

功能安全岛 (FSI) 是 Orin SoC 中的一个新硬件IP，其纳入的主要动机如下：

可为任何安全功能（例如传感器融合、车辆控制等）提供约 10K ASIL D MIPS，您可以通过映射到 FSI 来使用，以减少外部 MCU 总体上较高的 MIPS 需求。
FSI 硬件在系统学中被开发为 ASIL D，而 SoC 的其余部分则被开发为 ASIL-D Random，提供了更好的整体安全性 - 岛屿和水的类比。
FSI 硬件/软件可以集中监控 SoC 中发生的安全错误。

1.2 硬件组成

Orin SoC 中的 FSI 硬件设计为使用独立的电压/电源轨和独立执行安全功能所需的其他隔离来运行。

FSI HW IP 主要包含 4 个 DCLS（双核锁步）R52 (ARMv8-R) CPU 的 CPU 复合体。每个 R52 CPU 除了 32KB 指令缓存和 32KB 数据缓存外，还具有 ATCM (256KB)、BTCM (128KB)、CTCM (128KB)。

有关 R52 CPU 的更多信息，请参阅_ARM 参考手册_。

注意：ARMv8-R 不提供跨多核的缓存一致性。

FSI 有一个 3MB 的公共共享内存，通过结构/互连连接到 CPU。

在通信外设方面，FSI HW IP 有两个 CAN 控制器和一个 SPI 控制器。SPI 控制器专用于与外部 MCU 接口，以按照 DRIVE OS 提供的安全服务基础设施进行安全通信。

为了满足安全、密钥管理和加密需求，FSI 硬件 IP 具有加密硬件安全管理器 (CHSM) 模块，R52 CPU 可以将其用作硬件加速器。FSI 硬件 IP 具有访问阻止逻辑或防火墙，以在执行期间保持 FFI 与 SoC 的其余部分隔离。

从硬件安全方面来看，FSI 硬件 IP 具有硬件安全管理器 (HSM) 模块，可集中获取硬件中的各种安全错误通知，通知 R52 CPU，并断言连接到外部 MCU 的 Orin SoC 的 SOC_ERROR GPIO。

FSI 硬件 IP 通过独立且专用的 XTAL 和电压轨进行计时，以从 SoC 的其余部分实现 FFI。

FSI 硬件 IP 具有 DMA 引擎，可在不同内部存储器（TCM 和 SRAM）和外部存储器之间移动数据。

FSI 硬件具有用于调试和开发目的的 UART 外设。

FSI 硬件 IP 没有持久内存来保存任何数据。

1.3 FSI软件启动

作为 Orin 引导的一部分，MB2 阶段的引导加载程序将 FSI 二进制文件的各个组件加载到相关内存中，即。TCM 和 SRAM。

FSI 固件可以在没有配置密钥的情况下启动，并且不需要配置密钥的所有功能都可以按预期工作。这违反了安全架构，只能用于开发目的。

2. 功能监控层功能设计

内功心法ISO26262和具体的设计是相辅相成的。所以这里开始介绍的时候会进行穿插的方法，例如某个技术去找规范中对应的规定，然后对于规定去查漏技术是否有全面。

参考之前文章：功能安全入门-2 ISO26262说人话版本GB_T 34590中6-6 软件安全架构设计中，其中一大类就是功能监控的设计，本小节就就有了理论依据。这需要软硬件一块去实现。

2.1 错误检测概述

在Orin中实现了很多检测错误/故障和上报的机制，一般有两种方式检测错误：

通过专门用于检测硬件故障的诊断测试执行检测，例如ECC、奇偶校验和锁步实现等，该类错误软件无法处理，需要硬件自动去处理。
通过允许检测功能错误的其他方法执行检测，例如FIFO溢出、非法上电检测等，此类属于功能错误。

Orin硬件检测到的错误，处理方法可以分为两类:

纠正错误(CEs)：由硬件纠正的错误
未修正的错误(UEs)：未被硬件纠正的硬件错误

纠正错误(CEs)：硬件会纠正错误并记录有关此纠正的信息。例如，使用SECDED ECC保护的SRAM中的单位错误，在大多数情况下，错误已经在硬件中得到了纠正，不需要在软件中进行额外的纠正操作。但是如果内存中的某个位置出现了永久性故障，则从该内存位置的每次读取都表示已纠正的ECC错误。虽然错误被纠正了，但最好是识别出我们有一个永久性故障，它可能在暂态错误的情况下变成双位故障。所以如果纠正的数量超过了预期的纠正率，则可能需要采取纠正措施。例如，系统级错误处理程序应该监视已纠正错误的频率，以便对Orin硬件的状态做出额外的决定。Orin SoC 实现了错误计数器和错误日志寄存器，以提供已纠正错误的附加信息，以支持任何SoC或平台级纠正措施。

未修正的错误(UEs)：硬件不能处理的错误，需要软件进行处理，则被报告为此种错误。例如SECDED ECC保护的SRAM中的多位错误。在大多数情况下，未纠正的错误会导致硬件中不可预测的行为。应分析硬件的故障，以确定纠正措施。大多数的硬件故障都期望通过软件处理。

2.2 错误检测框架

对于错误的监测主要有以下几个方面：

外部监视器：Orin SoC存在一个外部监视器来控制SoC，以防检测到某些故障。外部监视器可以通过SPI接口监控FSI，例如FSI定时给外部MCU发心跳信号，如果超时则任务FSI出问题死了，需要外部MCU进行功能安全处理。
HSM（Hardware Safety Manager）：SoC还使用基于硬件的错误管理器(硬件安全管理器(HSM))，监测到的故障通过SOC\_ERROR引脚触发HSM中断进行处理，然后HSM将错误通过软件通知到外部安全MCU监视器，再进行功能安全处理。
FSI：专用的内部安全处理器(FSI或SCE)来监视其错误状态

对于错误的上报可以由硬件或者软硬件一块去完成。对于功能安全的处理则是依赖外部监视器,外部MCU应该监视SOC_ERROR引脚和心跳，然后在检测到错误时应用适当的响应。SOC_ERROR和心跳报告机制是互补的，在与安全相关的应用程序中，Orin必须使用这两种机制。

EC: 为了保持处理诊断错误报告的一致性，开发了一个名为Error Collator (EC)的常见错误收集插件。包含EC的模块将整理本地EC中的所有诊断错误，并将错误报告给HSM，作为已整理的已纠正错误或已整理的未纠正错误。本地EC还记录EC寄存器中检测到的实际错误的信息。

IPs: 功能块(IPs)通过HSM或遗留中断控制器(LIC)向软件报告错误，这取决于它们是诊断错误还是功能错误。功能错误预计将由软件作为其功能流程的一部分来处理，并附加向安全软件报告这些错误的要求。诊断错误通过HSM和内部安全处理器直接报告给安全软件。

对于没有实现本地EC的IP，错误信号要么通过IP块集群中的本地EC直接路由到SCE中的 HSM，要么在本地IP错误状态寄存器中进行整理。如果是自定义的错误整理，IPs还会向HSM报告已整理的已纠正错误和已整理的未纠正错误。

内部错误报告体系结构具有以下目标:

减少向HSM和外部监视器路径报告错误的概率；
在向HSM和外部监视器收集和报告检测到的错误时，避免引入延迟的元素，如中断；

CCPLEX: CCPLEX是CPU的集合，在Orin中为A78E核。iGPU通过LIC将错误作为失速中断或非失速中断报告给CPU Complex (CCPLEX)，并将这些信号路由到HSM。失速和非失速中断结合了所有事件，以及基于失速/非失速分类的错误和故障。这两个信号也被路由到HSM，但由于这些信号潜在的高断言率，它们不利于在内部安全处理器中立即处理。

如果使用Orin + dGPU配置，则dGPU通过PCI MSI机制向Orin报告错误。这些MSI PCI中断通过LIC路由到CCPLEX。根据HSM的设置，HSM可以驱动GPIO (SOC_ERROR)向外部代理(如安全MCU)指示错误的发生。此外，HSM可以通过向中断控制器断言LP_INT或HP_INT来中断内部安全处理器，如果它被编程这样做的话。在检测到HSM内部错误时，HSM还断言HSM_ERR中断。AVIC反过来向内部安全处理器生成FIQ或IRQ。

综上，涉及的硬件如下：

FSI，Functional Safety Island
SCE, Safety Cluster Engine，内部的R5已经不使用，HSM功能保留，用于汇总硬件错误并上报；
HSM, Hardware Safety Manager
IP中有Error Collator（EC）负责整理整个IP的错误，记录错误信息并上报。Diagnostic Errors直接上报HSM，Functional Errors则通过LIC通知CCPLEX
iGPU（SOC内部GPU）的错误即发送到CCPLEX又发送到HSM
HSM根据配置，可以将收到的错误通过GPIO(SOC_ERROR)发送给外部MCU，也可以将其发送到FSI的R52 CPU
R52还通过SPI接口提供心跳信息到外部MCU中，该信号与SOC_ERROR互补，共同协助外部MCU对整个SOC的监控

3. HSM(Hardware Safety Manager)介绍

3.1 HSM概述

HSM(Hardware Safety Manager)硬件安全管理器是一个硬件模块，用于监控来自芯片中所有安全关键模块的安全相关故障信号。如果发生了故障，HSM将通知处理器，并采取适当的操作来处理故障情况。

安全集群引擎(SCE)和功能安全岛(FSI)中都存在一个HSM实例。HSM的主要目的是监测来自安全关键模块的故障信号。如果检测到错误，HSM通过中断通知外部代理，如微控制器单元(MCU)和SCE/FSI处理器，以采取适当的操作。

SCE HSM整理来自SoC的所有错误，并将中断路由到SCE处理器。
FSI HSM对FSI内部的错误和SCE HSM中的错误进行核对。这个HSM实例驱动SOC_ERROR到外部MCU。

3.2 HSM Timer计时器

HSM 计时器提供了一种在观察到错误时延迟SOC_ERROR断言的机制。在HSM初始化期间，编写TIMER_THRESHOLD来控制允许解决错误的时间量。这将允许驱动程序或SCE/FSI在不断言SOC_ERROR的情况下解决错误或中断。只要断言错误，计时器就会倒计时。

如果在HSM计时器到期之前没有处理错误或中断，那么HSM会断言SOC_ERROR并继续正常的错误流。否则，如果该错误在定时器到期前由软件处理，则SCE/FSI用阈值重新加载HSM定时器。注意，计时器是通过挑战响应系统重新加载的，如下所述。

如果存在多个错误，建议在重新加载计时器之前处理所有错误。对于所有错误行只有一个HSM定时器，因此建议将TIMER_THRESHOLD值设置为处理软件可恢复错误所需的最长时间，该时间符合容错时间间隔(FTTI)。

3.3 Challenge Response System挑战响应系统

HSM实现了一个挑战响应系统，以避免通过安全软件误执行关键功能：取消SOC_ERROR断言、重置请求和重新加载HSM计时器。

SOC_ERROR信号只有在安全软件从SCRAMBLE寄存器读取一个置乱值、解乱并将结果写入DESCRAMBLE字段后才会被解除断言。只有当结果与预期值匹配时，SOC_ERROR才会被取消断言。

在来自安全软件的复位请求的情况下，电源管理控制器(PMC)是在安全软件从FSI_HSM_SCRAMBLE_0寄存器的SCRAMBLE字段读取已置乱的值后被断言的，去置乱，并将期望的值写入FSI_HSM_RSTREQ_0寄存器的DESCRAMBLE字段。

为了重新加载HSM定时器，安全软件从FSI_HSM_SCRAMBLE_0寄存器的SCRAMBLE字段中读取打乱的值，然后进行打乱，并将期望的值写入DESCRAMBLE字段。

4. FSI(Functional Safety Island)

4.1 FSI概述

功能安全岛(FSI)是一个处理器集群，旨在运行ASIL D及以下的功能安全应用程序或其他实时应用程序任务。它包括多个Cortex-R52实时处理器和一个Cortex-R5F实时处理器以及专用的I/O控制器。

FSI与SoC的其余部分隔离，并具有自己的电压轨、专用振荡器、专用锁相环和大型内部SRAM。它还支持FSI中的控制平面和数据平面中的许多防火墙。这确保了从SoC的其他部分的干扰(FFI)的自由程度。FSI允许Orin运行关键的安全软件，减少外部安全微控制器(MCU)的负载。

FSI具有在汽车系统中作为ASIL D安全处理器所必需的硬件特性。它包括:

Cortex-R52处理器----一个安全的CPU，在双核锁定步进(DCLS)模式下，有多达4个软件可见核，共多达8个物理核。它可以运行经典AUTOSAR操作系统，并可以实现Error处理和其他工作负载。这些处理器是公开供客户使用的。
Cortex-R5F处理器----一个加密硬件安全模块(CHSM) CPU，用于运行加密和安全用例，如通过CAN接口的安全板上通信(SecOC)。该处理器由NVIDIA编程，通过api公开。
紧密耦合的内存，指令和数据缓存的每个核心的安全和CHSM cpu。
在岛内的片上专用RAM总计高达5.5 MB (3 MB SRAM, 2 MB Cortex-R52 TCM, 0.5 MB Cortex-R5 TCM)，以确保代码执行和数据存储可以保持在FSI内。
总缓存高达320 KB: 32KB指令缓存，32KB数据缓存每个Cortex-R5和Cortex-R52 CPU。
I/O接口，如CAN、SPI、SBSA UART和gpio，用于与外部组件通信。
硬件安全机制，如DCLS, CRC, ECC，奇偶校验，超时等，所有的ip在FSI。
专用的热，电压和频率监视器。与Soc其余部分的逻辑隔离。

对于某些平台，FSI可以用来卸载主CPU以进行计算卸载。为此，FSI还实现了一个来自SoC LIC的中断通道。这允许SoC IP中断路由到FSI。但是，来自FSI的中断不能路由到LIC。

4.2 FSI硬件接口

外部I / O接口:

一个SPI接口，用于与外部安全MCU通信。安全单片机进行错误记录时，在此接口上发送心跳信号和错误信息。有关更多信息，请参阅串行外围接口(SPI)部分。
四个gpio用于杂项控制。
两个can向执行器发出命令。有关更多信息，请参阅控制器区域网络(CAN)部分。
一个SOC_ERROR信号到安全单片机。该信号与安全单片机通信，故障已经检测到。
Coresight和调试接口。
一个用于调试的SBSA UART。有关更多信息，请参阅SBSA UART部分。

与非 FSI 部分交互的内部接口:

到SoC数据结构的内存接口
SoC控制Fabric的接口
来自SoC HSPs的中断
从SCE到HSM的错误中断信号
从LIC到FSI的中断

4.3 Freedom from Interference

FSI用于运行独立于运行在SoC其余部分上的软件的软件。重要的是要确保它的功能不受Orin其余部分故障的影响。

采取措施尽量减少来自Orin其他部分的干扰。FSI有专门的资源用于以下方面：

FSI有自己的时钟单元、锁相环和时钟分布。FSI时钟来自一个专用的晶体。
只有DFT扫描时钟由SoC提供给FSI。
FSI由三条独立的电压轨供电。
FSI实现了自己的温度监视器。

在FSI与Orin其余部分的接口处，采用以下措施减少干扰：

如果需要，可以在FSI中断控制器上禁用从LIC发送到FSI的中断。
FSI的引导是由MB2中的SoC发起和驱动的，来自SoC控制平面(也称为CBB)的控制路径仅在引导阶段是有效的。但是由于该路径在引导后被禁用，所以在引导后Soc控制平面无法访问FSI资源。
在启动过程中，key-unwrap key通过keymover接口从SoC转移到FSI CHSM SE。SE使用该密钥进行安全操作。keymover接口被禁用，启动后不再进行进一步的数据传输。
在任务模式下，通过FSI控制位禁用调试接口。
产生FSI复位的逻辑在RTC轨道上的CAR逻辑中，因此绕过了其他SoC轨道。

FSI DRAM接口通过在FSI的HW中添加诊断来提供ASIL-D级别的覆盖(接口不是专用的，实际上是与SoC中的其余流量合并)。

FSI可以访问FSI本身之外的资源。例如，FSI可以通过专用的SoC DBB主接口访问DRAM。FSI也通过控制平面访问某些SoC资源。邮箱就是一个例子，它用于处理器之间的通信。在FSI中实现超时，以确保在SoC端挂起的事务不会导致FSI中的挂起。当没有未完成的事务时，可以使用这些接口上的监视器，以阻止响应路径上的虚假或意外数据或事务。

4.4 FSI的错误上报和处理

Orin错误上报处理架构包括以下主要组件:

硬件/软件诊断以检测错误。如ECC等诊断也可以纠正某些错误。
除FSI外，所有部分/模块的误差都在SCE_HSM中进行整理。
SCE_HSM可以将从错误源收集的错误详细信息传递给FSI。
FSI还可以直接从错误源(包括HSM中的错误源)收集错误信息，但从CCPLEX和İGPU中的错误源除外。
CCPLEX可以将LIC接收到的与错误相关的中断转发到SCE_HSM或直接转发到FSI。
FSI确定错误的严重性并采取适当的纠正措施。这还包括通过冗余方法(SOC_ERROR信号和通过FSI SPI的心跳消息)将错误通信到外部MCU。

4.5 FSI错误类型

ORIN硬件检测到的错误分为两类:

纠正错误
未改正的错误

被纠正的错误是指硬件能够执行补救操作，且错误不影响操作的错误。例如，用SECDED ECC保护的SRAM中的一个单比特错误就属于这一类。硬件记录和报告已更正的错误信息。Orin实现错误计数器和错误日志记录寄存器提供已纠正错误的附加信息，以便实施SoC或平台级纠正措施。

未修正的错误是硬件无法修正的硬件错误条件。例如，SECDED ECC保护的SRAM中的2位错误就属于这一类。软件可以确定适当的动作。与未纠正错误相关的信息也会被记录下来。

4.6 FSI错误上报给SCE

Orin在FSI之外的大多数IP，直接或通过本地错误整理器(EC)向SCE中的硬件安全管理器(HSM)记录错误信息和路由错误信号。ECs向HSM报告已纠正或未纠正的错误。错误信息也记录在本地ECs或IP错误状态寄存器中。ECs至少会跟踪发现、纠正和报告的错误数量。

一些IPs只通过LIC报告错误(包括在iGPU中检测到的大多数错误和IPs中的功能错误)，或者双重向SCE-HSM和LIC报告错误。

iGPU主要通过LIC向CCPLEX报告错误，要么是失速中断，要么是非失速中断，要么是向HSM报告。时钟监视器(FMON)错误从iGPU直接信号到HSM。

FSI HSM聚合各种安全关键组件的所有故障，一旦检测到故障，就通知安全CPU和/或外部MCU。它在每个故障的通知方面提供了一定的可配置性。

4.7 FSI启动

Orin实现了一个多阶段引导过程。引导序列以一种模式启动，在执行一些检查之前，该模式尚未准备好运行安全应用程序。引导序列可以包括IST测试序列，以检测Orin中的潜在故障。

在Orin中，初始引导序列以SOC_ERROR GPIO开始，这表明Orin还没有为安全应用程序做好准备。一旦软件错误处理程序上线，引导期间发生的任何安全错误都由FSI(或SCE)处理。这里必须考虑两种情况，每一种错误都必须检查并归类为以下一种:

该错误被认为是复位的副作用，一个例子是SRAM被擦除之前读取的SRAM上的奇偶校验错误。
错误不是预期的，可能是底层错误的结果。错误处理程序需要在启动安全应用程序之前解决这些类型的错误。

4.8 FSI Crypto Hardware Security Module

该模块由必要的组件组成，为各种加密操作提供硬件加速和硬件辅助的密钥保护。

5. SCE(Safety Cluster Engine)

SCE中的Cortex-R5计算子系统没有计划在Orin中使用，因为它正在被FSI所取代，而且它的使用正在被弃用。SCE中的HSM仍将用于Orin的故障聚合。

安全集群引擎(SCE)是一个基于ARMCortex-R5F的通用计算子系统，旨在帮助进行安全管理和处理。

SCE子系统提供所有必要的硬件特性，以提供故障管理功能。SCE处理器集群由一个Cortex-R5处理器以及一个紧密耦合的RAM、支持外设(如计时器、中断控制器)和路由逻辑组成。简单地说，SCE中使用的Cortex-R5F核心被称为CortexR5或仅称为R5，但它包含浮点和双精度浮点功能。

SCE具有以各种方式保护的模块，当故障发生时，它们都会产生错误。这些错误由错误整理器聚合并路由到硬件安全管理器。

硬件安全管理器(HSM)汇集来自SoC的各种安全关键组件的所有故障，并在检测到故障时通知FSI HSM和SCE Cortex-R5。然后FSI HSM依次通知FSI CPU和/或外部MCU故障。HSM为每个故障的通知提供了特定方面的可配置性。

6. 错误检测数据流

Error Flow：对于错误的类型和上报错误的方式在初始化的时候需要进行配置，上报错误的时机例如立即上报还是延时上报，上报的方式例如使用中断或者SOC_ERROR引脚。

Non-GPU Error Flow：来自Orin系统的错误(包括CCPLEX和SCE内部错误)被发送给 HSM 经过校正、未校正或未整理的错误信号。根据HSM的配置，HSM向安全MCU断言SOC_ERROR并中断内部安全处理器。在内部安全处理器上执行的安全软件通过SPI向安全MCU提供额外的错误信息，并查询在CCPLEX上执行的安全软件以获得错误的解决状态。如果错误条件完全解决，内部安全处理器软件在成功完成与HSM的挑战-响应后，将SOC_ERROR解除断言到安全MCU。同时，内部安全处理器软件将向安全MCU提供错误解析状态信息。如果错误无法解决，则安全MCU负责执行必要的操作，如重置Orin以从错误中恢复。

iGPU/dGPU Error Flow：来自iGPU和dGPU的错误通过CCPLEX发出信号并传播。dGPU通过MSIs对PCle产生错误。这些MSIs会导致对CCPLEX的中断。iGPU产生两个中断(失速和非失速)，向CCPLEX发送错误信号，CCPLEX又向CCPLEX安全软件报告错误，CCPLEX安全软件再向内部安全处理器软件报告错误。内部安全处理器软件通过HSM断言SOC_ERROR，并通过SPI向安全MCU提供任何额外的错误状态信息。

CCPLEX Error Flow：CCPLEX将已纠正和未纠正的错误路由到HSM。CCPLEX错误流在ARM RAS文档中有描述。

Error Handling：Orin硬件错误由3LSS框架处理。在内部安全处理器上执行的安全软件负责将错误信息发送给CCPLEX安全软件。CCPLEX安全软件的任务是向SCE安全软件提供错误解决状态。SCE安全软件通过SPI将错误解决状态转发给安全MCU，如果错误解决而没有任何额外的恢复步骤，则可以取消SOC_ERROR断言。为了帮助软件记录错误信息，Orin在PMC中分配了非易失性空间。通过定期通过SOC_ERROR引脚和SPI通信错误状态，它还可以减轻任何故障。

Error Output Pin：SOC_ERROR引脚是从HSM模块到外部管理器的错误输出引脚。Error，或者来自整个芯片元件的信号被路由到HSM。如果在HSM中配置了这些错误信号，那么每个错误信号都可以触发SOC_ERROR引脚的断言。所有被认为与安全相关的错误都必须配置为断言SOC_ERROR引脚。

Heartbeat Over SPI：Orin SoC对外部系统具有连续的状态指示。这被认为是一个心跳消息，由一个挑战响应机制通过SPI接口从外部监督程序生成到内部安全处理器。心跳包含来自整个芯片的运行状况信息和诊断测试结果。

3LSS框架的三层错误处理：

每个IP内部有L1的错误处理（如CPU上的Partition Monitor），当遇到错误时会上报到FSI；
FSI进行L2的错误处理，遇到不可恢复或严重错误时，会将错误通知给外部安全MCU；
外部安全MCU上做L3的错误处理，所以外部MCU也会运行一部分Nvidia提供的软件（称为Safety Services）；

7. Orin功能安全例子

参考：
https://docs.nvidia.com/igx-orin/product-specification/latest/safety-mcu.html

来感受下基于Orin功能安全能做的事情，上图显示了IGX Orin Board 的复杂功能安全用例示例。

IGX Orin Board 的最初用例是使用视觉分析等人工智能功能来监督预防性和主动安全功能。

在复杂的功能安全用例中，IGX Orin Board 补充了在事物级别实现的安全功能，以提高功能安全性。黄色框代表 IGX Orin 板。

一类机械（例如机械臂）配备有本地传感器、PLC、控制系统，包括运行安全功能的反应式安全装置，负责检测和控制故障（例如 ESTOP、PSTOP）。
其他类型的机械（例如传送带）配备有 PLC 和控制系统，但依靠 IGX 平台来执行反应式安全功能。
在 IGX 上，来自摄像机和其他传感器的数据用于主动安全监控，例如潜在的安全违规会为机械 (PLC) 生成保护性停止并触发警报。
安全相关数据（例如，故障检测和控制警报）通过安全工业协议（例如 Profisafe）在 IGX 和连接到机械的设备之间进行交换（例如，告诉机械停止、移动、更改功能以更换）设备故障等）。
安全相关数据被汇总、预处理并存储在云端，以实现安全预测（事故记录、安全分析和置信度视图）。它们可用于重新训练和 OTA 传输回设备。

后记：
硬件芯片的功能安全设计有些也是需要软件去配合实现，而且软件配合可以后续进行OTA升级改变策略，灵活性更高，也更加的方便，当然可能安全性可能不如硬件的高，在可以忍受的范围内就可以尽可能在软件上实施。
在芯片安全性实施的过程中，可能SoC上只有一个核或者一部分模块可以做到功能安全，然后再逐步推广到其他的IP，还要考虑成本，有时候自己的芯片设计功能安全可能成功太高，可以借助同一块板卡上的其他成熟低成本已过功能安全的芯片（即外部MCU，往往是国外货）来组合实现，把系统中最重要的一些部分防到有功能安全的硬件上去运行。总之需要根据成本去权衡，专业的事交给专业的模块。

作者：thatway
文章来源：OS与AUTOSAR研究

推荐阅读

更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。