英飞凌 AURIX™ TC4x最详技术解读

在 6 月 28 日的第二届英飞凌汽车创新峰会上，英飞凌科技正式发布了采用28 纳米工艺技术生产的 AURIX™ TC4x 系列微控制器（MCU），进一步增强其 AURIX™ 微控制器家族的产品阵容。

图1

1.1 AURIX™ TC4x 产品总览

2014 年，英飞凌推出了第一代 AURIX™ TC2x  系列，首次在单片机中集成多达三个 TriCore™  内核，为汽车电子带来了前所未有的多核处理能力。

2018 年，第二代 AURIX™ TC3x 系列推出，进一步将多核处理能力提升到新高度，集成多达六个 TriCore™ 内核。该系列在实时性能、功能安全（最高等级 ASIL-D）、信息安全等方面表现卓越，特别适用于各种汽车应用，也在市场上或得了巨大的成功。

如今，英飞凌推出了新一代 AURIX™ TC4x  系列。该系列采用新一代 TriCore™  1.8 内核，并引入了增强性能的加速器套件，包括并行处理单元（PPU），为人工智能和实时控制应用提供强大支持。主要面向电气化领域（BMS、逆变器等）、区域控制、ADAS、底盘和车身控制领域，如下图所示：

图2

1.2 AURIX™ TC4x 功能概述

针对上述场景，TC4x 从功能安全、信息安全、高速内部通信路由、内核等方面做了进一步提升，整体架构如下图所示：

图3

与 TC3x 相比，TC4x 系列各方面进一步升级：

1. CPU 升级

• TriCore™从 v1.6.2 升级到 v1.8，频率从 300MHz 提升到 500MHz，最高支持 6 对锁步核同时运行，算力已逼近低端 SoC，例如 TC4Dx 系列算力可达 8000 DMIPS（双核 A53 算力 7360 DMIPS）；

• 新增两级 MPU，引入虚拟化功能；

• 新增双精度浮点运算，满足 IEEE754-2019；

• 新增 128bit load\store 指令以提升效率。

2. NvM 升级

• 容量上最高支持 25MB NVM，基于 TC3xx 的 A\B SWAP 机制进行迭代优化，真正实现了零停机升级；

• 在后续产品中引入 RRAM 技术，该技术与台积电共同研发已久，这对汽车 OTA 格局是不小的冲击。

3. 新增加速引擎

• PPU（Parallel Processing Unit) ：并行处理单元，旨在替 CPU 完成复杂信号处理和数学运算 ，助力 AI 功能在 MCU 中的安全实现；

• CSRM（Cyber Security Real-time Module）\CSS（Cyber Security Satellite）：硬件密码加速器；与 TC3x HSM 相比，TC4x 提供两个不同的硬件加密模块，支持的加密算法和加密性能得到进一步提升，在后量子密码时代独树一帜；

• CRE（CAN Routing Engine）\DRE（ Data Routing Engine) ：数据路由引擎；硬件层面实现 CAN-CAN 、CAN-ETH 、CAN-MEM 数据的路由和转发。

4. 新增可扩展高速通信接口

• PCIe

• CAN XL

• 5Gbps Ethernet

上述接口在区域控制器中以以太网环形网络架构中实现了高带宽 、低延迟的效果。

接下来，我们就详细解读其关键技术。

2.1 NvM

2.1.1 NvM 容量

NvM 容量和 RWW（Read-while-Write）特性向来是 Tier 1 、OEM 在产品芯片选型时最关心的 Feature 之一。

为适应新的区域控制器架构要求，支持多应用融合，TC4x 延续了 TC3x 的 NvM 设计精髓并做出优化，每个内核可通过独立接口快速访问 2 个 PFlash Bank，实现真正零待机 SOTA；设计出独立 Security P\DFlash ，保证 Host 与 HSM 之间物理隔离，具体示意如下：

图4

CPU 通过 PFI 接口可以独立访问与之关联的 PFlash Bank，实现快速指令访问，并且由于 CPU 关联两块 PFlash ，实现了 RWW，对 SOTA 非常友好。

通过 DMU 访问 DFlash ；通过 DMU 、FSI 对 P\D Flash 进行操作；

Host 每个 PFlash Bank 容量为 2MB， 最高支持 24MB(6 CPU*2 Bank*2 MB) ，Security PFlash 为 1MB， 总计 25MB；

DFlash0 最高 1MB，DFlash1 为 128KB，均用于 EEPROM。

从地址映射上，仍然延续 TC3x 的 Cacheable 地址 8H，Non-Cacheable 地址 AH，这在使用习惯上是非常好的继承。

然而随着 MCU 算力要求不断提高，倒逼工艺制造向先进制程进发，28nm、22nm 甚至 16nm 已经被提上日程，但 eFlash 微缩化困难严重阻碍了进程，该瓶颈亟待解决。

2.1.2 RRAM 开辟 NvM 新道路

据台积电官网介绍，英飞凌与台积电早已联合研发 RRAM(Resistive RAM) ，致力打破 22nm、 28nm 车规 MCU 的 NvM 瓶颈。

RRAM 相比于 eFlash ，具有更高的扩展性、更低的成本和更低的功耗。

作为结构最简单的存储技术，它看上去像一个三明治，绝缘介质层（阻变层）被夹在两层金属之间，形成由上、下电极和阻变层构成金属-介质层-金属（ metal-insulator-metal ，简称 MIM）三层结构。

图5

RRam 利用阻变原理实现存储等功能，基于阻变层中导电通路（一般称为 conductive filament, 导电细丝）实现，通过在上、下电极施加不同的脉冲电压激励，使介质层发生阻变，产生物理性变化。

导电细丝会在阻变层中呈现导通或断开两种状态：非易失性的低阻态（Low Resistance State， LRS） 或高阻态（ High Resistance State， HRS），从而实现了“0”，“ 1”状态的区分和存储。

了解其原理后，作为软件工程师最关心的还是怎么用，如果能做到软件移植平滑，指令操作上比TC3xx更简单，这将在OEM/Tier1做区域控制器产品选型时是一个非常棒的加分项。

英飞凌与台积电联合开发 RRAM 已有十余年， 技术上是否有更进一步的创新？ 未来会用在 TC4x 哪些产品型号，我们拭目以待。

2.2 SOTA

之前我们描述了 TC4x 关于 NvM 的排布，很明显一颗 CPU 关联 2 块 PFlash Bank 是非常有利于 SOTA 实现。

在 TC3x 上面我们基于硬件做 A\B SWAP，特别是 TC39x 系列，虽然说存在异步域的情况，但在逻辑地址和物理 bank 的映射上还是存在让人困惑的地方，如下图：

图6

可以看到，虽然逻辑地址没有改变，但在不同地址映射模式下 PF0\1 与 PF2\3 切换，PF4 与 PF5 切换，最容易让人迷糊的就是逻辑地址与物理 Bank 的映射问题，锁板子的事情常常发生。

这个问题在 TC4x 系列有所缓解，在不使用硬件 SOTA 机制的情况下(这里暂时不聊 HSM PFlash)，最高可支持 6 核 24MB 线性地址访问(0x8000 0000-0x817F FFFF) ，如下图：

图7

那当我们使用了 SOTA 机制，好玩的来了，如下图：

图8

地址做成了连续，该模式下 Host 最高支持 12MB，同时，为了不混淆，还特意将 Inactive Back 的地址往后挪了一点(0x8200 0000) ，这样咱们在使用上就明晰了很多。

TC4x 的 SOTA 支持两种地址映射，上图为 A 模式， B 模式下灰色和橙色 Bank 对调即可。

当然 HSM 同理，虽然它只有一个 1MB 的 PFlash，仍然支持 A\B SOTA，看来这个 Flash IP 还重新规划了 Bank 容量的。

在 SOTA 使能和配置方面，继续使用 UCB 进行 SOTA 的使能和 Bank 切换，经典的 55h 对应 A 地址映射，AA 对应 B 地址映射。

总结下来，TC4x 应该是总结了 TC3x 用户反馈，并且基于区域控制器做了场景分析，从使用上来看更为方便，也更容易理解。

那么聊到了区域控制，就不可避免地要谈多功能融合，而对于一颗 MCU 来说芯片资源是有限的，因此资源竞争资源隔离成为了区域控制器实现的关键技术路径。

一般来讲，应基于硬件资源隔离是最可靠的方式，但是不能资源共享给应用；于是虚拟化隔离出现了，接下来我们从虚拟化技术分类开始，掌握 TC4x 虚拟化的基本概念。

2.3 虚拟化

2.3.2 虚拟化技术

虚拟化技术按照虚拟化层次通常可以分为硬件虚拟化和操作系统虚拟化两类。

2.3.2.1 硬件虚拟化

硬件虚拟化依赖 Hypervisor（虚拟机监视器）和 CPU 的虚拟化扩展，根据 Hypervisor 部署方式，可进一步细分为 Type1 和  Type2 两类；

• Type1 类型的虚拟化

Hypervisor 直接运行在裸硬件上，也叫作裸机虚拟化，如下图，

图9

该类型的 Hypervisor 能够直接操作控制硬件并管理多个虚拟机（ Guest VM）。每个虚拟机都有自己的操作系统和应用程序，可以完全独立运行。

• Tpye2 类型的虚拟化

与 Type1 类型的虚拟机不一样，Type2 类型虚拟化是指在已经装载好 OS 的硬件上运行 Hypervisor，这个软件作为应用程序管理多个 Guest VM。

图10

可以看到，Type 1 和  Type2 的虚拟化最大区别在于 Type 1 的 Hypervisor 可以直接操作硬件，没有多余的开销，性能相对较高；Type2 的 Hypervisor 访问硬件资源，还必须经过 Host OS。

因此在汽车领域，由于对功能安全等级、实时性有较高要求，一般均使用 Type1 的 Hypervisor，Hypervisor 之上直接运行多个客户操作系统  (GuestOS)；

那么 Hypervisor 是如何来管理和隔离硬件资源，保证各个不同功能的应用程序的资源使用安全和资源调度？

个人理解，资源安全需要从 vCPU 调度隔离、内存隔离、存储隔离、中断虚拟化及隔离 、网络隔离等方面来保证安全，如下图：

图11

在 vCPU 的调度中，常见的Armv8-R 架构提供了 EL0-EL2的等级，每个等级可运行的指令不一样，通常EL0 运行 APP，EL1 运行 GuestOS，EL2 运行Hypervisor（负责 vCPU的上下文切换），实现 GuestOS 和Hypervisor的隔离。

2.3.2.2 操作系统虚拟化

操作系统虚拟化一般就是指容器技术，由操作系统内核提供的资源隔离和控制功能，创建出多个相互隔离但共享系统内核的用户空间实例，从而实现对多系统运行能力的支持。

进一步讲，容器技术就是将操作系统所管理的计算机资源，包括进程、文件、设备、网络等分组，然后交给不同的容器使用。

容器中运行的进程只能看到分配给该容器的资源。从而达到隔离与虚拟化的目的。实现容器技术需要用到 Namespace 及 cgroups 技术。

典型代表就是 Docker 公司在 2013 推出的轻量级虚拟化技术--Docker 。结构如下图：

图12

在这种虚拟化机制下，操作系统内核被每个容器共享，每个容器使用相同的 OS，由 OS 来分配资源，不过正是因为这种多个 App 共享内核的机制，可能存在漏洞或攻击风险。因此目前容器化场景在汽车中还没看到实际应用。

2.3.2 MCU 为什么要提虚拟化

在汽车行业里，虚拟化的概念最先由座舱域引入，目的是在同一颗 SoC 上实现仪表和中控两个系统的功能，在 Hypervisor 的管理下基本可以不修改旧代码就可移植到最新的硬件上，如下图：

图13

随着区域控制器概念的提出，以前底盘、车身域控下挂节点的功能有可能会被整合或者直接移植到高性能的区域控制器 MCU 中，这种集成难度和整合工作难度不小；

试想，BCM、PowerControl、BMS 等功能即使在 OEM 里也是不同部门进行开发，在操作系统、硬件资源上差异可能很大，要想减轻集成难度，充分利用 MCU 资源，在没有虚拟化的情况下势必需要重新规划软硬件架构；

再恶劣的情况，如果下挂子节点是由供应商黑盒交付，OEM 想要完成集成工作，引入虚拟化是最省钱省事的方案，如下图：

图14

在上述示意中，我们通过 VM(Virtual Machine，虚拟机)来实现上述集成工作。虚拟机模拟了一个完整的计算机系统，包括处理器、内存、存储设备和其他硬件，这就意味着在同一台物理计算机上可以同时运行多个操作系统和应用程序。

其中，VM0 用于运行 Hypervisor，用于创建和管理虚拟化环境，例如 VM1-4，同时还负责 VM1-4 的时间调度、资源管理、数据通信等；VM1 用于电池管理系统、VM2 涵盖了 DC/DC 和充电功能 、VM3 集成了 Inverter 和 PDC，VM4 可以运行车身控制，每个 VM 都可以使用独立的操作系统（ RTOS、AUTOSAR OS 等等），从某种意义上讲，VM1-4 甚至都认为自己独占了整个 MCU 资源。而从硬件角度，CPU0 里既包含了 VM1 还包含了 VM2，CPU1 里包含了 VM2 和 VM3，依次类推。

2.3.3 TC4x 的虚拟化

由于 VMn 是基于时间片分时复用芯片资源，因此对于算力和硬件虚拟化特性都提出来以前 MCU 没有的新需求。

TC4x 设计了 TC1.8 ，最高主频可达 500MHz，算力上得到巨大增加。

同时支持虚拟化辅助功能，该功能可以根据需要进行使能；

针对虚拟化，每个核有三套独立硬件资源 HRHV 、HRA 、HRB，可支持最大 8 个 VM，其中 VM0 运行 hypervisor，VM1 运行实时虚拟机，VM2-7 运行其他 VM，如下图所示：

图15

• HRVH – Hypervisor hardware resource（ VM0）；

• HRA – Real time virtual machine hardware resource (VM1)；

• HRB – Other virtual machine hardware resource (VM2-7)。

MCU 上电后，如果内核支持虚拟化，那么所有 HRHV 里的资源均可以被访问了，这个时候启动代码就可以开始设置 Hypervisor 需要的状态，这里面包含了虚拟化功能的使能、关于 NMI 处理层级的配置(Hypervisor 或者普通 VM 处理) 、目标 VM 的序号等等，如下图：

图16

既然每个核支持最大 8 个 VM，那么针对中断的处理也有对应 8 套资源，那么就引发了几个问题：

• 假设被分配到的 VM 此时还没有运行怎么办？

• 假设被分配到的 VM 此时正在处理中断怎么办？

我们按照正常物理中断处理流程做出假设，VM 之间也可以进行抢占，得到如下：

正常时间片为 2000us，VM1 占用 500us，VM2 占用 1000us，VM3 占用 500us；

当 VM2 正在运行时，此时来了一个 VM1 的中断，该中断可以抢占 VM2 的时间，所以此时 Hyperviosr 需要将 VM2 的上下文保存，并切换到 VM1，让其完成 ISR 处理，然后恢复现场 VM2 继续运行；

当 VM3 正在运行时，此时来了一个 VM2 的中断，但它不可抢占 VM3 的时间，所以需要 VM3 运行完毕后切换到 VM2 的 ISR 进行处理，当然这里也挤压了 VM1 的时间。

TC4x 是如何实现上述功能的呢？

在他们的设计中，每个中断 SRN 都可以被拓展分配给 1 个 VM；每个 VM 都有自己独立的中断状态控制寄存器，包括当前 VM 中断系统是否使能(简称 VMIE) 、当前 VM 的优先级(简称 VMCP) 、Pending 中断优先级(简称 VMPIP)；

为了实现运行 VM 在收到其他 VM 中断时可被抢占，新增了抢占阈值寄存器，简称 THR，好玩的就来了。

假设当前正在运行 VM1，此时来了一个 VM0 的中断，如果此时进来的 Pending 中断优先级高于 VM0 配置的抢占阈值，同时高于 VM0 的当前优先级，那么 Hypervisor 就需要进行上下文切换，返回到VM0 处理中断，伪代码如下：

if (INT.VM_coming == current VM){        if ((VMPIP > VM_coming.VMCP) && (VM_coming.IE )        {               isr_routine();          }        else        {                Keep INT Pending          }}else (INT.vm_coming == VM0 ){        if ((VMPIP > VM0.VMCP) && (VMPIP > VM0.THR)
        {            Switch to HRHV                isr_routine();        }        else        {            Keep INT Pending        }}

同理，如果当前 VM0、VM1、VM2 同时运行，也需要执行上述步骤 。如 VM2 要抢占 VM1 时，由于 VM1 独享 HRA，因此可直接切换到 HRB 让 VM2 进行中断处理。

本质上，这样的机制和透传很像，只是我们可以通过 Hypervisor 配置每个 VM 的中断状态控制器寄存器、抢占阈值寄存器来实现中断实时性的控制，  例如：

当我们把阈值配置为最大时，此时谁也无法进行抢占(Trap 除外)，只能得到时间片走完；如果阈值配置为最小，那就是直接透传，这时候性能最优。

2.3.4 基于 TC4x 的 Hypervisor

通过 2.3.3 小结，我们对 TC4xx 的虚拟化有了一定的了解，也不难看出，其中最关键的还是运行在裸板上的 Hypervisor 软件。

目前已知的 关于MCU Hypervisor 软件主要由基础软件供应商提供，例如Vector 的 veHypervisor，基于 Type1Hypervisor 架构实现，满足 ASIL-D 要求，如下图：

图17

EB 与英飞凌联合开发基于 AURIX TC4x 的 AutoCore OS 和 EB tresos Embedded Hypervisor，支持 OEM 和 Tier 1 更轻松地开发和部署基于  AUTOSAR Classic 标准的汽车 E/E 架构，助力下一代车辆的加速开发：

图18

ETAS RTA Lightweight Hypervisor

图19

不管上述各家对于 Hypervisor 的描述如何变化，本质上还是在强调在一颗 MCU 里多 VM 场景的并行运行和资源隔离，不仅要支持不同操作系统，还要需要稳定安全高效的时间调度机制来支持多 VM。

2.4 加速器

2.4.1 PPU

在 ADAS 领域里，大家很有默契地几乎都用 TC39x 系列作为功能安全岛，除此之外 MCU 还承接车内 CAN 报文收发，雷达数据等辅助处理，常见架构如下：

图20

根据雷达在汽车布局位置分为前雷达(Front Central Radar) 、侧后雷达(Side-Rear Radar)以及泊车系统使用的超声波雷达(Ultra Sonic Sensor)；

根据测距不同分为 24GHz 和 77GHz 雷达，可见信号处理上的复杂性；而在雷达数据的处理上通常都会用到快速傅里叶变换(FFT)用于频率分析、波束形成等等，在数据处理上针对单个数据点使用标量算法，针对多个数据点组合进行向量运算等，在波束形成时进行矩阵运算，在 TC3x 系列中，我们使用 RIF 和 SPU 来完成上述计算，如下图：

图21

图22

• 标量处理单元里包含了一颗 32bit 标量核，它支持双精度浮点运算，用于执行大量标量运算；

• 向量 DSP 处理单元，位宽 128~256bit ，支持 SIMD(单指令多数据)指令，支持浮点向量运算、专用信号处理，提高计算效率；

• DMA、Memory：分别用于数据搬运，输入和输出临时存储等。

除了智驾方面应用，PPU 也可应用在电机矢量控制上，在算法上坐标变换使用三角函数、观测器迭代、锁相环鉴相等等操作是非常消耗 MCU 的计算资源，PPU 中的 Vector DSP 单元可以有效加速实时观测计算，从而帮助 Tricore 提高运行效率。

PPU 还可用于基于 AI 的电池诊断，包括镀锂层检测，电池健康状态(SoH)和老化轨迹预测，剩余使用寿命（RUL）预测等等。

在开发 PPU 时，我们可以结合相关应用模型和 PPU 对应软件库。

Mathworks 在官方提供了基于 TC4x 的 Tricore 与 PPU 通信的模型、基于 PPU 的电机矢量控制模型等；

新思科技为 TC4x 的 PPU 提供了丰富的软硬件支持，在向量 DSP、神经网络处理、AUTOSAR 适配等提供了丰富的资源，例如 MetaWare Development Toolkit、MetaWare Neural Network SDK 用于基于 PPU 优化的模型变异等等；

图23

总体而言，PPU 主要是为了 Tricore 承接了 A I 、电机控制、区域控制等复杂的信号处理和数学运算；由于 PPU 本身特性，在计算效率上更快，Tricore 则主要用于控制，这与现有异构 SoC 的设计理念已经非常相似了；我想这也是未来 MCU 的发展趋势之一。

2.4.2 数据路由加速器

在整车中央计算平台等架构里的网络通信概念通常以以太网为主干，它连接了中央计算平台、各区域控制器；在区域控制器里使用其他通信网络连接下挂节点。

架构概念如下：

图24

目前主流的车内通信手段是以 CAN \ CANFD 和车载以太网为主，区域控制器间通过以太网为通信，在区域内仍以 CAN、CANFD 为主 。因此，不同域之间的 ECU 节点进行通信，就必须要经由 CAN->ETH->CAN 的通信路径，所以这中间就存在如下问题：

• 以太网应该使用什么传输协议保证 CAN 的有效 paly load 不丢失；

• CAN 是周期广播形式，以太网多是点对点事件触发，这需要做什么样的优化？

• 区域控制器承接部分网关作用，在数据路由上需要达到什么样的性能？

对于网关来说，最重要的就是路由数据一致性和时效性。在 AUTOSAR 技术视角里，报文的路由基本都会放在PduR层级进行处理。以CANFD路由到CAN 为例，通常会经过 CAN0->CanIf->PduR->CanIf->CAN1 这样一个路径，其路由表在PduR 定义，显而易见，这在数据延迟方面做不到性能最优，我曾经为了百 us 级的路由在 CanIf 层手撸了一套定制化的PduR，头大不已。因此一直在想如果在硬件设计这样一套路由机制，将PduR中的路由表承接下来，那这数据路由的延迟将会大大降低，概念如下图所示：

图25

为此，英飞凌 TC4x 提出了 DRE、CRE 等等用于 CAN2ETH 、CAN2CAN 等数据路由硬件加速功能。

TC4x 芯片所有加速硬件的总体结构如下：

图26

我们主要介绍 CRE 和 DRE 两个模块。

• CRE：位于 CAN 模块内部， 可用于路由 CAN 消息到模块内部其他节点。

TC4x 支持 5 个 CAN 模块，每个 CAN 支持 4 个节点，总计 20 个 CAN Channel。在每个 CAN 模块内部有一个 CRE(CAN Routing Engine) ， 用户只需要配置相应的路由表（寄存器），即可实现模块内部节点间的 CAN  路由，如下：

图27

• DRE：用于 CAN 和 Ethernet 的相互路由，和 CRE 完成 CAN 帧到不同 CAN 模块的路由。DRE 最重要功能就是把 CAN 帧路由给 Ethernet 帧，这就涉及到我们前面提到的问题：这种  CAN->ETH 应该以什么样的格式对数据进行封装？

在 DRE 里采用的是 ACF 格式对 CAN 进行封装。ACF 全称 AVTP Control Format，它是 AVTP 协议的子集，AVTP（Audio/Video Transport Protocol）里定义了 CAN\CANFD ACF message 数据格式，如下图：

图28

在两个区域内节点需要互相通信时，发送端通过 DRE 将 CAN 报文封装 ACF 格式数据，接收端接到以太报文后根据协议提取 CAN 报文。

除此之外，DRE 配合 CRE 可完成 CAN 报文路由到特定系统 SRAM、指定其他 CAN 模块的不同节点。

2.5 信息安全

2.5.1 TC4x 信息安全系统概述

随着 R155\R156 、国家标准《汽车整车信息安全技术要求》等汽车网络安全法规逐步强制执行，汽车网络安全的重要性被提升了到新的高度，因此从 OEM 到 Tier 1 再到 Tier 2 急需从 Security 方面优化各自产品。

TC4x 系列在吸纳 TC3x HSM 子系统的优点后，针对当前区域控制器重构信息安全系统，首创 CyberSecurity Cluster 的概念，规划出 CSRM（ Cyber Security Real-time Module）和 CSS （ Cyber Security Satellite） 两个子系统，如下图所示：

图29

CSRM 和 CSS 主要负责密码算法硬件加速，除了支持国际密码算法，还支持国家密码算法 SM2\3\4 ，其中：

CSRM 包含：

• 非对称算法加速引擎，支持 RSA 和 ECC；

• 随机数生成器，支持 TRNG、DRNG 和 HRNG；

• CSCU 用于与其他核通信、控制调试访问、PIN 脚输出等

  
  

CSS 主要用于对称和摘要算法加速，包含：

• 内部私有 RAM 用于存储密钥和 IV；

• 内部支持多达 21 个通道(1 个给 CSRM 独享)支持不同密码任务；

在 Cluster里，除 CSRM、CSS 外，还包括 TC1.8替代 TC3x中HSMM3内核、内部独立的 PFlash 和DFlash，同时可以用过软件配置各种外设成为 Cluster 里的部件，例如配置 Secure SPI与外部 TPM 交互。在 inSE的大背景下，该方案提升了 OEM\Tier 1 在布局汽车网络安全的灵活性和可靠性。

2.5.2 针对通信场景的优化

从上图可以看到支持 sym 和 hash 算法的 CSS 在布局中更为靠近 Host CPU，这样做的目的是什么呢？简单来讲，架构变化要么是性能优化，要么是安全优化，安全这块目前看不出来，但是从性能的优化我们需要从特定场景进行思考。

在 CP AUTOSAR 中，基础软件开发工程师大多从 SecOC 入门信息安全。在现有 MCU 里，针对 SecOC 数据验签的做法通常是 Hsot CPU 将待校验数据放置 Host 共享内存并置起请求 Flag，HSM CPU 侧轮询或者中断接收该 Flag 后去共享内存获取数据并进行加解密，如下图：

图30

这种针对 ECU 间的安全通信在当前架构下对 MCU 的 HSM\SHE 等要求不算严苛，但是在区域控制器多功能融合、多 VM 通信的场景下，当前 MCU 就存在加密引擎实例和性能不够、多 Host 通道不足的问题，例如当区域控制器里融合了网关和 BMS 功能，当二者同时要使用 HSM 时，势必会形成资源竞争；

在车联网的大背景下，TLS 被引入到 DoIP 安全会话流程，在车机端也被用于车云通信，而 TLS 的引入也带来了巨大的通信负载（ 4 次握手，比 TCP 还多一次），流程定义了，那么只能在密码服务的性能做优化。

为此 CSS 站了出来，它提供独立的 SRISlave 接口（类似 TC3x 的 Bridge 模块）来实现与 CPU 之间的通信，内置 21 个独立通道和多个对称、摘要实例来实现多主机的并行访问，相较于之前 Host、HSM 之间交互，Host 仅需配置 SRISlave 接口里的特殊寄存器，即可完成 SYM 和Hash 引擎的使用。理论上省却了 Host 与 HSM 通信交互，提供了多通道平行接口，确实可以提高不少效率。

咱们做出这样一个畅想：在 SecOC AES-CMAC 校验时只需要告诉引擎在哪里获取数据，引擎自动获取数据并分块、填充完成数据校验，不需要像以前通知 HSM CPU 去获取数据，手写代码对数据进行分块、做填充。从代码层面上至少省却了通信这一大模块，然后减少 For 循环分块填充数据到引擎的代码，效率大大增加。

2.5.3 针对强标的对策

随着车辆网的发展，汽车网络安全已经被提升到了需要强制 OEM 考虑和执行的阶段，耳熟能详的就是 UNECE R155、 R156 以及对应国标《汽车整车信息安全技术要求》、《汽车软件升级通用技术要求》。

以 R155 为例，读过这份标准的同学应该最开始都是云里雾里，它主要涉及汽车的网络安全管理体系（ CSMS）及特定车辆型式认证（ VTA）两部分。

前者要求每个 OEM 都必须有一个稳定的网络安全管理体系，但是没有具体说应该如何去建立；后者要求 OEM 去识别特定车型的相关网络安全风险，但传统汽车人对这块确实一头雾水。

为此，ISO 和 SAE 与 2021 年联合发布了 ISO\SAE 21434 标准，旨在指导 OEM、Tier1 如何建立起有效的网络安全组织，同时为车辆的整个生命周期(从研发到报废)建立起有效的流程体系，以保证其免受信息\网络安全攻击。

换句话说，R155 是指导性文件，告诉做什么；ISO\SAE 21434 是执行性文件，告诉 OEM 怎么做。

图31

由于 R155 针对 OEM 提出了宏观纲领，那么分解到 Tier 1 、2 ，自然就需要 21434 来进行指导如何干活；

TC4x 信息安全子系统不仅符合 EVITA-Full，还通过了 ISO\SAE 21434 的认证，英飞凌从企业内部建立起 CSMS(Cyber Security Management System) ，针对风险评估方法、概念阶段、产品开发、运维、持续网络安全活动等方面定义了相关流程，致力于辅助加速 OEM 针对 R155 的认证。

2.6 功能安全

2.6.1 SMU 继续发挥作用

如果说重构的信息安全系统是 TC4x 在跨域融合产品的亮点，那么 TC4x 的功能安全则是整个芯片正常运行的基石。

在 TC4x 中，大部分功能安全机制沿用 TC3x，而与我们开发最相关的 SMU 仍继续发光发热。在 TC3x SMU 的基础上，新增了关于 Security Domain 的 alarm 处理模块，同时设计了 Security 方面的 alarm；为满足区域控制下多 vECU 对于 alarm 处理的资源竞争，设计了两个 safety  alarm 处理模块。

其结构如下图：

图32

虽然没有了解到具体 Safety Manual，但是从 SMU 整体架构我们不难得出，所有功能安全机制触发的 alarm 可以被分为三大类：

• Safety 相关的 alarm；

• Security 相关的 alarm；

• Safety 和 Security 兼顾的 alarm。

因此，针对这些 alarm 的处理，首先就是需要选择路由给哪些 alarm 处理模块。在 SMU 模块里提供了 alarm 选择功能，可以根据寄存器配置路由给不同的处理模块等，那么路由到目标处理模块后，对应行为是什么呢？

不难推测，为实现 TC3x 到 TC4x 的平稳迁移，当然就是继续采用内部行为和外部行为，如下图：

 图33

内部行为对应 NMI、 IRQ、SYS_RESET、CPU_RESET，外部行为毫无疑问就是 FSP 等。

不过在 SMU_CS 的处理上，由于涉及到 Security，因此行为多在 Security 子系统里内部处理，包括 CSIRQ\NMI\RET，以及特殊的对所有秘钥上锁、对 Debug 方面进行上锁等。

针对信息安全子系统设计的相关 Security\Safety 机制，解答了我一直以来的疑惑，Security 与 Safety 到底应该如何融合：个人理解，虽然 Safety 和 Security 有各自的重点和侧重点，但它们的共同目标都是保护车辆、乘员和其他道路使用者的安全；同时二者关系也非常紧密，例如车辆的信息系统受到黑客攻击或恶意软件感染，可能会导致车辆失去控制、系统故障或其他安全问题，从而危及车辆和乘员的安全。

正如我们设计系统安全启动功能时，不仅要从 Safety 角度进行 HARA 分析，还需要从 Security 角度进行 TARA 分析，双剑合璧，才能加固系统。

2.6.2  功能安全闭环设想

在区域控制器架构下，不同 vECU 都会有自己的功能安全方案，有些方案甚至已有量产经验，那么在做跨入融合如何降低集成成本？我们这样设想，vECU 在运行中感觉不到自己是虚拟环境里，那么我们仍然可以从以往控制器的功能安全方案中吸取经验。

TC3x 的 ErrorPin(P33.8) 与 PMIC TLF35584 的 Error PIN 相连接， 35584 在接收到相应的错误状态后，可以通过 SSx(Safety State)脚再向外输出错误状态，例如控制逆变器功能降级、通知 Transceiver 关闭通信等，使 ECU 进入到安全状态。

采用这样的思路，在区域控制器的大背景下，需要解决的就是多 vECU 对于 SMU 的资源竞争。

我们以 SMU 中 Alarm 行为 IRQ 为例来预估这样一条路径，如下图所示：

图35

当功能安全机制触发对应 IRQ 行为的 alarm 给到 SMU 后，通过 IR 给到目标 CPU，然后就是中断虚拟化的处理，Hypervisor 下对 VM 调度进行上下文切换，并通知相应 VM 进行功能降级。

如果使用到了 FSP，我们最关心的 Error Pin 继续兼容 TC3x， 并在此基础上新增了两个 PIN，这样相对来说资源上是能够支持与外部 PMIC 或者用户自定义引脚相连。

在 TC4x 推出的同时，配套 PMIC TLF4xx85 也同时推出，提供整套电源管理方案。

2.7 TC4x 在调试、标定上的优化

2.7.1 Overlay 继续沿用

TC1.8 继续沿用 CPU 视角下的 Overlay，这个功能我之前已经讲过多次，主要是用于 XCP 中页切换的实现同时也减少软件标定栈集成工作，具体如下：

当我们在上位机选择 WP 时，此时对应下位机(ECU)应该反馈 RAM 的值；选择 RP 时，对应下位机应该反馈 Flash 的值，如下图：

图36

在最初没有 Overlay 功能，要实现页切换，需要定义多块 RAM，其中包括一块临时 RAM，如下图：

图37

切换 WP 或者 RP，为保证 WP 数据不丢失，此时需要将 WP copy 至 Temp RAM；然后将 Flash 值 Copy 至 RAM；而这样内存 COPY 对于资源消耗和性能都有比较大的影响，为此英飞凌基于内核视角提出了 overlay 机制，如下图：

图38

这样的好处在于，假设修改标定量导致系统进入临界工况，例如车速突然增加(同一油门踏板开度，不同输出曲线)；此时快速切回 RP，可有效降低工程事故。

需要注意的是，当虚拟化开启后，如何通过 MPU 、Hypervisor 来保证不同 VM 的资源隔离，特别是对于 overlay 的 Flash 的选定，这是需要在实际工程中进行重新布局和调整。

2.7.2 调试系统

在调试系统上继续沿用 TC3x 的 Debug 接口，例如 JTAG\DAP\DAPE； 不过针对 Trace 接口提出了新的优化。整体架构如下图：

图39

在之前我们做高速测量时供应商都会针对 Trace 接口设计相应的 POD 接口，具体结构如下图所示：

图40

这对于 OEM 或者 Tier 1 在使用上有成本和性能上的综合考虑。

在 TC4x 的设计中，Trace 的数据可以通过 SRI 总线路由到 ETH 和 SRAM；我们做出这样猜想，在高速测量场景中，可以直接通过 ETH 将 Trace 数据给到上位机，这样不仅节省了成本，也提高了效率：

图41

在上图中，Trace 数据通过 Trace 模块存放在 SRAM(作为临时 Buffer) ，CPU 仅需触发 DMA 搬运数据到 ETH 模块，通过 Ethernet 与标定测量系统进行数据传输，虽然会消耗很少部分 CPU 资源，但是相较于之前 MCU 从通用性和成本上确实提升了不少。

2.8 工具链及生态解读

2.8.1 集成开发环境及调试器

据统计，目前我们常用的商业版集成开发环境(含编译器)Tasking、Hightec、GHS 全面支持 TC4x 产品，调试器劳特巴赫、iSystem、PLS 均已全面支持。

图42

图43

英飞凌也推出里免费集成开发环境 ADS Limited，将代码编写、编译、调试融为一体，供 TC4x 新用户上手评估。

图44

2.8.2 基于 TC4x 的 AUTOSAR 基础软件

英飞凌本身不提供 AUTOSAR 基础软件，但行业中的主流 AUTOSAR 工具链厂商都已完成了 TC4X 的适配，国产的包括东软睿驰、普华基础软件、经纬恒润，国际厂商包括 Vector、ETAS、EB、SIEMENS 都对 TC4x 做了适配。

图45  东软睿驰基于 TC4x 的配套产品

2019 年，特斯拉这条鲶鱼带来的汽车电动化、智能化、网联化震撼人心，随着这股风潮的推动，汽车电子电气架构逐步由传统分布式 ECU 向域控/中央集中架构方向发展。

在以往传统分布式 E/E 架构下，汽车智能化程度的提高主要依靠整车 ECU 数量的增加，往往一台高端车型的 ECU 数量就超百个；然而 ECU 数量的增加势必造成整车布线复杂冗长、线束成本剧增，同时不同 ECU 之间信息交互的效率和精度也大打折扣，为此域控概念开始提出。

博世关于整车EE 架构的演进在之前文章里已经谈过多次，它主要是依据控制器功能划分为动力域、底盘域、信息娱乐域、自动驾驶域和车身域五大域控，这也是目前多数 OEM 的架构；

特斯拉领先一步，根据空间位置分为 CCM（中央计算模块）、LBCM（左车身域控）、RBCM（右车身域控），这也是中央集中架构的雏形。

虽然上述两类控制器均带有域，但是英语单词上存在比较大的差异，

• 域控制器：DomainController，针对的是控制器功能，我们常见的是五域架构：智驾域、座舱域、动力域、底盘域、车身域就是此类域控制器；它按功能对整车布线，以提供对整个车辆的控制。但随着智能网联汽车发展，新的需求和功能导致ECU 增多（据统计智能汽车含 100-150 个ECU），汽车内部布线逐步复杂。从电源到ECU 再到执行器的连接导致了整车布线多半是打补丁的方式，冗余且浪费。这种方式在未来智能驾驶的实现有着极大的扩展限制。

• 区域控制器：Zonal Controller，面向的是整车空间的一个布局，在区域控制器下可能会实现多个功能，这也是下一代 MCU 考虑的事情，在硬件层面重新规划 I/O 等硬件资源，打破域控架构下的原有功能边界，大大缩短了布线长度，简化了电源和信号传输，并释放了更多空间，为下一次电子电气架构演进奠定了基础。

当架构逐渐集中，对于汽车软件功能新增和聚合的需求也日益凸显。据《中国汽车基础软件发展白皮书》统计，智能网联汽车运行代码量已经高达 2 亿行，在未来 L3\L4 及以上级别的自动驾驶汽车代码量甚至会增加到4 亿行 。代码量的增加对汽车芯片的资源、算力、外设、性能的要求与日俱增，这对在汽车芯片占比高达 30% 的 MCU 提出了更大的挑战，各大国际 MCU 厂商纷纷加大投入，融入新技术，即将推出的汽车 MCU 产品更像是一颗低端 SoC 芯片，这对以往基于 MCU 研发的工程师来说将会是一个新的领域。

那么具体来看，区域控制器会为整车带来什么的好处？

1. 线束减少影响整车重量

据统计，在当前功能域架构下的整车线束在 50-60 公斤，展开长度可达 5-6 公里，这对于电动汽车的成本、日常使用续航等有着重大影响；采用区域架构可以有效减少线束，减轻了车辆的重量。这对电动汽车尤其有益，因为每节省一公斤就意味着里程的增加和性能的提高。特斯拉采用类区域控制架构，将整车线束重量减小至至 20 公斤，大家可以发现在 18 、19 年续航里程上国产电动车宣传都有一点虚高，特斯拉则是实打实标称；

值得一提的是随着车辆从 12V 电气系统迁移到 48V 电气系统，可以在更低的电流下提供相同的功率，从而减少电线的厚度和相应的重量，这种重量进一步得到改善。通过更细的线束和更简单的布线，也为其他功能系统腾出了更多的空间。

2. 提升整车制造装配的效率

随着区域架构采用标准化和模块化的设计，整车装配线进一步简化，模块化使得线束可以预组装，标准化使得整车装配模块即插即用。这些进步带来了更大的灵活性，更容易自动化，更少的错误，并大大降低了电气子系统的制造成本。

3. 简化 OTA 难度

在分布式甚至功能域架构下，ECU 个数仍居高不下；如今智能网联大背景下，汽车软件 OTA 更加频繁，因此 OEM 需花费大量成本、人力资源来协调和管理 ECU 供应商的软件更新和管理。

在中央集成+区域控制架构下，ECU 数量减少，中央计算平台与区域控制器采用以太环网进行数据交互，区域控制器下挂节点利用高速总线接入网络，不仅简化了 OTA 升级节点个数，还提高了 OTA 升级速度。

就目前来说，域集中已经成为了汽车行业共识，我们可以从主机厂发布的域架构可以看出，汽车电子电气架构沿着预轨道发展，正朝着中央式进发，如下图所示：

图46

“ 中央集成+ 区控制器”架构将是长期趋势，也是当前汽车未来研发重点。

-end-