原创:SoC 安全岛应用和未来演进
之前在社区与大家交流的过程中，注意到大家在关注一些 SoC 功能安全岛在 SoC 芯片设计时的应用场景，以及未来觉得安全岛会怎么演进的话题，我大概整理了一些最近做智能驾驶芯片的时候对 SoC 安全岛的看法，主要内容会从三部分进行介绍，分别是：
1. 为什么最近几年所有的汽车 SoC 都会有一个安全岛的设计；
2. 针对市面上的典型 SoC 的安全岛设计，进行安全岛应用的介绍；
3. 未来智能驾驶或者智能座舱安全岛的应用场景变化和架构的演化。
文末原文查看“大型车规SoC芯片的安全岛作用和未来趋势演进”直播回放
01.为什么需要安全岛
为什么最近几年所有的汽车 SoC 都会有一个安全岛的设计，把这个问题换一个表达方式，其实就是为什么需要安全岛：
早年在没有智能驾驶和智能座舱的应用场景出现的时候，汽车电子控制芯片主要还是一些规模不大的 MCU 产品，当时的 MCU 为了满足功能安全的需求，会在 MCU 内部设计一个故障收集处理模块，如英飞凌的 SMU, NXP 的 FCCU 等，模块的设计很简单，如下图所示，主要分为两大部分，第一部分为状态机（FSM），一部分为配置寄存器（reg file）， 对于这个模块它的主要功能就是通过配置寄存器的提前对芯片内部的故障进行处理的设置，然后当故障真实发生的时候通过状态机的设计对故障进行分级处理，如产生一个中断给到 CPU, 或者对于一些严重程度较高的估值可以直接产生复位或者通过硬件信号送到芯片外部。
对于这样的故障处理模块它具有以下的几个优点：
1. 因为是硬件状态机的处理，所以从故障被检测到故障处理的行为发生，整个处理的延迟可以控制在纳秒级；
2. 因为是一个较简单的硬件状态机控制，模块的难度较低，硬件的稳定性较好；
3. 支持寄存器配置，可以满足 MCU 这一规模较小芯片所需的各种处理方式的设定。
但是等到智能驾驶和智能座舱的应用在汽车上普及和高速发展后，我们会发现芯片的规模在发生指数级的变化，下图为一个简单的智驾 SoC 的基本资源图，从图上可以发现在智能驾驶 SoC 中存在很多个不同功能的子系统，这些子系统的功能相对复杂，一个子系统的资源就基本上和之前三电 MCU 规模差不多，所以在芯片规模指数级变化的时候，对应的芯片内部的故障信号的数量也在指数级变化，举个简单的例子：对于传统的 MCU 芯片，如规模较大的英飞凌 TC3XX 的故障规模大概在 300~500 个左右， 而对于一个典型的智驾 SoC 的故障规模则大概在 1000~1500 的左右，对于一些超大规模的智驾 SoC 的故障规模甚至可以达到 5000 个左右的规模。如果这些故障规模庞大的 SoC 也使用传统 MCU 芯片使用的状态机管理的这种方案的话，整个 SoC 的故障处理设计会存在以下问题：
1. 因为故障数量较大，整个故障处理模块的设计会变得很复杂；
2. 整个芯片的物理实现也会因为故障信号数量的增加带来 routing congestion 等相关问题；
3. 因为 SoC 中的处理器的架构相比于 MCU 的处理器架构会更关注 performance，实时性上会比较差，整个芯片的故障处理的软件延迟会增加，无法做到快速，实时的故障处理。
为了解决上述的三个问题，在 SoC 的的设计中我们逐渐衍生出了安全岛的设计，最早的安全岛架构是由 ARM 提出的，ARM 基于市场上客户对故障处理实时性要求较大而 ARM 的 A 核无法满足的背景下，推出了高可靠&高实时的 R 核系列用于在 SoC 中进行单独的故障处理，最早使用安全岛架构设计的芯片为 TI 的TDA4，TDA4 的整体框图如下, 在 TDA4 的架构中，TI 使用了一对支持 DCLS的 ARM cortex-R5F， 这个 R5F 的核配合之前 MCU 中的故障处理的状态机模块和一些低速的外设构成了 TI 的安全岛，在这个架构下，TI 将 TDA4 中的故障信号和故障处理的软件都迁移到了安全岛中，在故障处理的过程中因为使用了高可靠&高实时的 R 核，所以整体的软件处理比 A 核更快，更稳定，相比于 A 核 ms 级的故障处理，安全岛架构下可以将软件的处理控制在 us 级，整个架构看起来可以很好的解决上述的三个问题，所以后续的芯片厂商在 SoC 中也大多沿用了安全岛这套架构。
图片来源：TI 官网 TDA4VM 数据表、产品信息和支持 | 德州仪器 TI.com.cn
02.当前安全岛的典型应用
当前智驾 ADCU 的安全岛使用的典型应用，硬件基本架构如下图所示：
1. 安全岛与外部 safety MCU 通过 SPI 等低速接口进行安全相关的通信；
2. 外部 safety MCU 作为 SoC 与安全岛的 common cause failure detect 机制，用于接收安全岛输出的 error pin；
3. 外部 safety MCU 与 SoC 通过以太网进行 function 相关的通信。
在该场景下，SoC 的安全岛主要负责 SoC 内部的故障诊断和处理，并通过 SPI 等低速接口向外部的 safety MCU 进行故障信息的上报。
Safety MCU 在当前应用下作为整个 ADCU 最后的安全防线，用于一些智驾实时性算法的运算和整个 ADCU 的故障诊断通过 CAN 总线将整个智驾 ADCU 的故障诊断信息上报到整车。
软件基本架构如下图所示：
1.内核诊断模块检测内核态的软件错误；
2.诊断进程收集软件错误；
3.安全岛诊断模块实时监控 ADAS 操作系统状态及诊断进程；
4.安全岛持续监控整个 SoC 的 hardware error 和 software error；
安全岛对 error 进行故障处理并对外进行 error 上报。
整个软件的基本框架被分为了两部分：
一部分为 AP 相关的嵌套在 kernel 中的 safety 诊断服务，对于这部分的诊断服务主要用于处理 ADAS 相关与业务挂钩的 safety error，这部分 error 的严重度一般，不会直接影响整个 safety goal，同时 kernel safety 诊断服务也会用于对 linux 进行 safety enhance，对于 safety enhance 的设计则取决各家对 linux 的具体设计。
第二部分则为 safety island 的 safety handle service，这部分业务主要布置在 safety island 的实时 core 上搭配的为 RTOS，主要用于 critical error 的处理，包含硬件故障和AP侧的 critical software error。
两部分软件的通信当前比较主流的是使用 mailbox 的机制，当前的 SoC 场景也基本上会提供一套封装号的高可靠的 mailbox 软件接口用于双方通信和握手。
03.未来安全岛的架构演进
基于 Topic2 当前的安全到应用，当前架构下的安全岛应用在量产过程中仍然遇到了一下待解决的问题：
1. 缺失业务信息，导致故障处理分段化
当前安全岛作为独立故障处理模块，缺失 Performance Core 的实时业务信息，导致与业务相关的故障无法处理，无法形成归一化的故障处理策略。
2. 故障处理颗粒度过大
当前安全岛因为无法感知业务的状态，无法进行较小颗粒度的故障处理，更多的处理方式还是较为粗暴的 reset。
3. 日益增大的 SoC，安全岛的统一管理带来的硬件成本的增加
当前随着 SoC 的功能不断扩展，SoC 的故障数量增加，安全岛的统一管理带来的是整体 SoC 的布局困难，导致面积成本的增加。
4. 日益增大的 SoC，安全岛软件复杂度的增加和对硬件性能的增加
当前安全岛主要功能还是故障的处理，对于 ADAS 域的高安全，高实时的算法主要还是在外部 MCU，受限于通信的带宽，导致部分高实时的应用受到时间的妥协，安全岛软件面临着日益增加的功能需求，对安全岛软件开发复杂度日益增加，同时对安全岛性能需求越来越大。
基于上述的几个问题和下一代智驾 SoC 正在向着多域融合的方向发展，整个安全岛的架构的也会随着多域融合逐从为集中式演变成分布式，整个安全岛的功能也会从简单的故障处理演变出多域时钟处理，多域电源管理，多域隔离管理等功能用于解决多域融合导致的新增的相关性失效的控制。
同时 ADCU 的产品形态上安全岛也会逐渐演进替换掉当前典型应用上 ADCU 部署的外置 safety MCU,如下图所示，对于该产品模式可以带来以下的收益：
1. 整体 ADCU BOM 成本降低；
2. 减少供应链依赖，无需适配不同类型的 safety MCU；
3. Safety MCU 由安全岛完全替代，内部总线替代以太网通信，带宽更富裕，通信延迟更小，对于高实时的应用如 AEB，可以大大减少算法时间。
但是该产品模式下因为将所有的安全业务和功能都放到了一颗芯片中，所以物理上带来了更多的相关性失效，如：共用内部总线，共用封装，热传导等，后续的 SoC 安全岛难点也就是如何在架构上去控制这些相关性失效并如何与 ADCU 的成本进行一个合理的 trade-off，因为上述相关性失效控制各家都还在专利布局阶段，本文在此不做深度探讨。
END
作者：刘擎宇
文章来源：sasetech
推荐阅读
更多物联网安全，PSA 等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入PSA 技术交流群，请备注研究方向。
