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

发布时间:2026/7/9 14:12:10

功能安全入门-功能安全岛(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.html1.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进行功能安全处理。HSMHardware Safety ManagerSoC还使用基于硬件的错误管理器(硬件安全管理器(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。综上涉及的硬件如下FSIFunctional Safety IslandSCE, Safety Cluster Engine内部的R5已经不使用HSM功能保留用于汇总硬件错误并上报HSM, Hardware Safety ManagerIP中有Error CollatorEC负责整理整个IP的错误记录错误信息并上报。Diagnostic Errors直接上报HSMFunctional Errors则通过LIC通知CCPLEXiGPUSOC内部GPU的错误即发送到CCPLEX又发送到HSMHSM根据配置可以将收到的错误通过GPIO(SOC_ERROR)发送给外部MCU也可以将其发送到FSI的R52 CPUR52还通过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.1 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)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 InterferenceFSI用于运行独立于运行在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错误上报给SCEOrin在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 FlowCCPLEX将已纠正和未纠正的错误路由到HSM。CCPLEX错误流在ARM RAS文档中有描述。Error HandlingOrin硬件错误由3LSS框架处理。在内部安全处理器上执行的安全软件负责将错误信息发送给CCPLEX安全软件。CCPLEX安全软件的任务是向SCE安全软件提供错误解决状态。SCE安全软件通过SPI将错误解决状态转发给安全MCU如果错误解决而没有任何额外的恢复步骤则可以取消SOC_ERROR断言。为了帮助软件记录错误信息Orin在PMC中分配了非易失性空间。通过定期通过SOC_ERROR引脚和SPI通信错误状态它还可以减轻任何故障。Error Output PinSOC_ERROR引脚是从HSM模块到外部管理器的错误输出引脚。Error或者来自整个芯片元件的信号被路由到HSM。如果在HSM中配置了这些错误信号那么每个错误信号都可以触发SOC_ERROR引脚的断言。所有被认为与安全相关的错误都必须配置为断言SOC_ERROR引脚。Heartbeat Over SPIOrin SoC对外部系统具有连续的状态指示。这被认为是一个心跳消息由一个挑战响应机制通过SPI接口从外部监督程序生成到内部安全处理器。心跳包含来自整个芯片的运行状况信息和诊断测试结果。3LSS框架的三层错误处理每个IP内部有L1的错误处理如CPU上的Partition Monitor当遇到错误时会上报到FSIFSI进行L2的错误处理遇到不可恢复或严重错误时会将错误通知给外部安全MCU外部安全MCU上做L3的错误处理所以外部MCU也会运行一部分Nvidia提供的软件称为Safety Services7. 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往往是国外货来组合实现把系统中最重要的一些部分防到有功能安全的硬件上去运行。总之需要根据成本去权衡专业的事交给专业的模块。公众号“那路谈OS与SoC嵌入式软件”欢迎关注个人文章汇总https://thatway1989.github.io

相关新闻