SASETECH
建立安全生态圈，成为汽车安全的布道者
进入主页添加星标，第一时间获得消息⭐
原创
SoC安全岛应用和未来演进
之前在社区与大家交流的过程中，注意到大家在关注一些SoC功能安全岛在SoC芯片设计时的应用场景，以及未来觉得安全岛会怎么演进的话题，我大概整理了一些最近做智能驾驶芯片的时候对SoC安全岛的看法，主要内容会从三部分进行介绍，分别是：
1. 为什么最近几年所有的汽车SoC都会有一个安全岛的设计；
2. 针对市面上的典型SoC的安全岛设计，进行安全岛应用的介绍；
3. 未来智能驾驶或者智能座舱安全岛的应用场景变化和架构的演化。
“大型车规SoC芯片的安全岛作用和未来趋势演进”直播回放
➡本文主要内容（约3000字，15分钟阅读）
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
近期热门
汽车安全沙龙火热报名中
往 期 精 选
JOIN US
长期招募
杭州
— 高级信息安全工程师
欢迎将个人简历发送至邮箱：
double.ma@sasetime.com
SASETECH是国内首个由汽车安全专家发起组建的技术社区，致力于为汽车安全的从业者提供交流、学习、合作的中立性平台。
SASETECH
扫码联系管理员加入交流群→
