实现区域控制器的关键技术以及MCU解决方案

汽车工业经过百年发展，已经进入了有史以来最激动人心的时刻，技术的进步有望带来无与伦比的安全性，更高的生产率和更好的环境利益。但具有自动驾驶功能的纯电动汽车不可能在一夜之间成为主流或平价。OEM意识到，他们需要为当下和未来的汽车建立正确的架构基础。区域控制器是整车EE架构的重要部分。本文讨论实现区域控制器的关键技术以及MCU解决方案。

区域控制器是汽车中的节点，在汽车的一个物理区域内，为各传感器、执行器等设备提供电源分配，数据连接和I/O采集与驱动需求。MCU是区域控制器的大脑，区域控制器中的MCU一般需要具备强大的处理能力，有很丰富的通讯接口，同时具备一定功能安全和信息安全等级。下面介绍区域控制器的一些关键技术和MCU解决方案。

高算力多核处理器

围绕区域控制器和中央计算单元的EE架构车辆，会使车辆中的ECU的数量减少，但也增加了一些ECU的处理器负载，因为有更多的功能部署到这些。在物理上，区域控制器是多个ECU的逻辑集中点，这对于区域控制器中MCU的算力有了更高的需求。在传统功能单一的ECU中往往使用性能较低的单核MCU即可满足要求，而对于区域控制器，往往需要高性能的多核MCU才能满足要求。

在多核MCU中每个核可以跑一种单独功能，多核即可实现多种功能，从而实现多种ECU功能的融合。

TC3xx微控制器是第2代AURIX产品，搭载了多达六个TriCore 1.62嵌入式内核，每个内核的时钟频率最高可达300MHz。下图是TC3xx家族中的TC39x系列MCU模块图，TC39x的算力达到了4000 DMIPS。

Figure 1: TC39x Block Diagram

TC4xx微控制器是第3代AURIX产品，搭载了多达六个TriCore 1.8嵌入式内核，每个内核的时钟频率最高可达500MHz，并且集成一个PPU协处理器，可实现快速向量运算，基础神经网络算法以及其它一些复杂数学算法。PPU在未来的区域控制器中可以被应用于建模，模型预测控制以及防入侵检测等一些信息安全算法中。下图是TC4xx家族中的TC4Dx MCU的模块图，TC4Dx的算力达到了8000DMIPS+72GFlops*1。72GFlops是由PPU贡献的。

Figure 2: TC4Dx Block Diagram

*1. FLOPS是每秒浮点运算次数。1GFLOPS = 每秒十亿（=10^9）次的浮点运算。以多层感知器（Multi-Layer Perception ，MLP）为例，在输入层神经元数量=14，隐藏层神经元数量=20，输出层神经元数量=1的情况下，大约需要1.7GFLOPS的算力。

连接和互通

在区域控制器体系中，每个传感器和执行器都根据其位置连接到本地区域控制器，然后区域控制器执行一些数据帧格式转换，汇总数据并通过高速以太网将数据传送至中央处理单元。区域控制器一般通过控制器CAN或LIN总线和挂载在它上面的传感器和执行器通信，或者通过低速以太网或LVDS与摄像头或其他ADAS传感器进行通信。

这就要求区域控制器的主控MCU有丰富的CAN和LIN的通讯接口以及高速以太网接口。在区域控制器进行数据转发的过程中，还需要考虑通信延迟的问题，在中央集中式架构中，大部分的控制和执行命令是由中央处理单元发出，有些命令（例如底盘和动力）对于延时有严格的要求，因此对于区域控制器中从高速以太网转发到CAN/LIN/低速以太网接口的延时时间也有了要求。

TC3xx/TC4xx家族产品都有丰富的CAN/LIN/Ethernet通讯接口。

Figure 3: TC39x/TC4Dx CAN/LIN/Ethernet Channel

TC4xx产品中更是集成专用的硬件通讯路由模块CRE (CAN Routine Engine)/DRE (Data Routine Engine)。TC4xx中的一个CAN模块中集成了4个CAN 节点，当相同模块中的CAN节点进行数据通信时，可以通过CRE直接实现CAN数据转发，无需CPU和软件介入。当不同模块中CAN节点进行数据转发或者CAN节点和以太网之间进行数据转发，则可以通过CRE+DRE的方式直接实现数据转发，也无需CPU和软件介入。

Figure 4: TC4xx CRE & DRE

这种硬件路由引擎直接实现数据转发的方式大大减少了数据延迟，CAN到Ethernet的转发延时最少可以到15us，CAN到CAN的转发延时最少可以到5us。

Figure 5: TC4xx Communication Latency

在未来的中央集成EE架构中，通讯数据量不断增加，高速以太网逐渐成为EE架构中的主干网。而为了考虑数据通信安全和冗余，以太网环网架构逐渐成为主流，区域控制器和中央控制单元则都是以太网环网架中的节点。TC4Dx中有2路5Gbps的高速以太网接口和4路10/100Mbps接口，2路高速以太网接入以太网环网（1进1出），4路低速以太网则可以接雷达或者摄像头传感器。

2路高速以太网可以通过内部集成的高速以太网桥（G-Ethernet Bridge）直接进行以太网帧转发。4路低速以太网接口之间也可以通过低速以太网桥（L-Ethernet Bridge）直接进行以太网帧转发。低速以太网接口和高速以太网接口之间也可以通过低速以太网桥+DRE+高速以太网桥直接进行以太网帧转发。这种方式大大减少以太网接口之间数据转发的延时时间。

Figure 6: TC4xx Ethernet Bridge

在中央处理单元和区域控制器为节点的以太网骨干网络中，往往需要传输多种以太网数据帧，有些数据需要进行确定性的传输（例如控制类数据），有些数据则会占用很大的带宽（例如音视频数据，ADAS传感器数据等），有些则是常规数据（例如对于传输延时没有要求）。

因此，在这个骨干网络中，需要对于以太网帧进行分类，对于控制类数据要保证在可控的延时时间内可以发送出去，对于音视频或者ADAS传感器数据要保证在正常传输的同时不能干扰网络中其他以太网帧的传输，造成其他高优先级以太网帧阻塞。

Ethernet TSN协议很好的解决了这个问题，其中IEEE802.1Qav实现了流量整形，优先级划分和队列管理，很好的解决了数据冲突的问题，而在此基础上形成的IEEE802.1Qbv实现了时间整形（Time-aware Shaper）机制，允许端口按照一定的时基来控制流量是否允许传输，传输的开关通过传输门（Transmission Gate）和门控制表（Gate Control List，GLC）来控制。

通过这种时隙划分机制，隔离了时间敏感消息流和其他普通消息流，既能够实现时间敏感消息的确定性传输，使得消息到达时间可预测，又能避免普通消息的干扰，提高实时性。IEEE802.1AS则给以太网网络中各个节点提供了时间同步的机制，IEEE802.1AS-rev在此基础上又增加了主时钟冗余和多时间域的概念。

TC3xx/TC4xx以太网控制器支持的AVB/TSN协议如下：

Figure 7: TC3xx/TC4xx Ethernet TSN Support

*1) IEEE802.1 Qbv-prelim: 是指TC3xx的GETH的通道/队列中支持一种slot功能。例如可以把一个同步周期分为3个slot, 然后配置3个队列，每个队列占用一个slot，这样就能实现3个队列发送不同的以太网帧以及3个队列发送的数据互不干扰。

互不干扰性

在面向区域的中央集中式架构中，ECU的数量将大幅度减少，这一部分减少的ECU有一部分将并入区域控制器中，有些则会把控制功能往上传至中央处理单元来实现，而自身则转变为一个智能传感器或者智能执行器。在这个过程中，区域控制器会承载越来越多的功能，而各个功能独立运行和互不干扰至关重要。

按核划分

目前多核MCU在汽车电子上得到了广泛的应用，可以每个核分配一个功能，这样每个功能并行运行，提高运行效率，并且能保证互不干扰，当然这个需要依赖Memory Protection Unit (MPU)。TC3xx/TC4xx有多达6个CPU内核，且每个CPU都支持Memory Protection Unit (MPU)。以TC3xx为例，每个CPU内核都6组保护设置，每组保护设置有18个数据保护区，10个代码保护区。

当配置代码数据和代码保护区后，其他CPU将无法访问这些区域。另外考虑一个CPU中运行操作系统的情况，当有多个任务同时执行时，可以给每个任务分配一组保护设置，这样可以做到任务之间数据和代码的隔离。

Figure 8: TC3xx/TC4xx MPU

另外区域控制器中的各项功能也会使用不同的MCU外设通道，也需要对外设进行很好的隔离。在TC3xx/TC4xx中每个外设通道都有访问保护（Access Protection），其实现的原理是给每个SRI总线master分配一个master tag ID，每个外设通道都可以设置允许哪些master可以访问该通道。通过这些方式可以把不同的外设分配给不同的内核进行访问，从而保证其他内核不会非法去控制不是属于该内核的资源。

虚拟化技术

中央集中式的架构对于研发团队的组织架构影响也是巨大的，在未来的区域控制器中可能整合了多种ECU功能，而原来开发这些功能的研发人员可能来自不同的团队，那么就会面临几个问题：

- 如何协调这些研发人员开发区域控制器？需要考虑这些研发人员以前使用的开发环境（如操作系统，编译器，调试器等）可能是不一样的。

- 如何重用以往项目中的软件？

- 如何让这些研发人员同步开发而且相互之间没有干扰？

举一个例子（不一定符合实际情况），现在要开发一个区域控制器（放在左车身域），这个区域控制器至少要实现左边车身域的I/O控制和检测（类似以前的BCM功能），作为车身的一个网关（Gateway），还要作为左车身域配电中心（Power Distribution），最后可能还要考虑能够对于挂载在它上面的各个ECU进行固件升级（OTA）。

假设原来BCM和网关的软件是不同两个研发团队开发，他们用的OS也是不一样的，现在想重用以前的BCM和Gateway的软件，然后重新开发左车身域配电中心和对各个ECU进行固件升级的功能。那么如何才能高效的完成这个项目？

虚拟机（VM, Virtual Machine）完美地解决了这些问题。虚拟机是一种通过模拟物理机来封装和执行其他软件的软件。被执行的软件可以是一个单一的程序，也可以是一个完整的操作系统，按照通常的方式执行任务。Hypervisor是一个中间软件层，用于在虚拟机之间划分处理、内存和通信资源，并将同时运行的虚拟机调度和迁移到不同的资源上。虚拟化的一个主要用途是整合需要不同操作系统，以及相同操作系统的不同版本的ECU功能。

从微观上来讲，每个CPU内核支持多个vm（例如vm0~vm7），各个虚拟机之间实际上是对CPU进行分时复用，每个虚拟机之间可以用Level 2的MPU进行数据和代码的隔离。从宏观上来讲，每个功能可以由一个VM来实现，而每个VM实际都对应一个或者多个CPUx.vmy。

以上述区域控制器为例，BCM功能用VM1来实现 (假设原来是用一个三核MCU做的)，Gateway功能用VM2来做(假设原来也是用一个三核MCU做的)，VM3则实现区域配电功能，VM4实现OTA功能。VM1实际会包含cpu0.vm1, cpu1, vm1, cpu2.vm1，而VM2实际会包含cpu0.vm2, cpu1.vm2, cpu2.vm2, VM3用CPU3.VM1，VM4用CPU3.vm2。

这样，VM1和VM2依然还是可以重用以前的软件（尽管以前用的是老版本的AUTOSAR软件和操作系统），而新开发的功能VM3和VM4则可以用新的AUTOSAR版本。这些虚拟机之间用Hypervisor进行管理和调用，实际上每个CPU的vm0就是运行在Hypervisor模式，用于调度每个CPU的虚拟机，而所有CPU的vm0集合就是宏观上所说的Hypervisor模式。

Figure 9: Hypervisor Example

除此之外，各个外设通道也可以设置各自的访问保护（Access Protection），每个外设通道都可以设置允许哪些VM可以访问该通道，从而做到VM之间的资源访问隔离。

TC4xx MCU所使用的是TC1.8 TriCore内核，支持虚拟机。每个内核支持8个VM (VM0~VM7)，它支持3套独立CPU内核寄存器，VM0和VM1各独占1套，VM2~VM7共享另外1套内核寄存器，因此从VM0或者VM1到其他VM可以快速切换。

Figure 10: Hypervisor Example

OTA

中央集中式的架构会使硬件平台变得统一化，包含控制器，传感器，执行器和各种接口，不同功能的实现全由运行在各种硬件平台上软件进行区分，从而真正实现“软件定义汽车”。未来的区域控制器是车上某个区域的枢纽，它需要能够对挂载在它上面各种ECU，传感器，执行器的软件进行更新，除此之外它还需要能够对自身的软件进行更新。

TC3xx/TC4xx MCU都可以实现无感OTA，即TC3xx/TC4xx MCU有两个独立Bank的Flash, 当程序运行在其中一个Bank的Flash时，可以把更新的程序写入另外一个Bank，在这个写入过程中，自身的程序的运行不会受到影响。

另外TC3xx/TC4xx MCU可以支持EMMC接口，最高访问速度可达400Mbps，可以把其他ECU或者传感器的更新固件放在外接的EMMC存储器中，等到合适的时机，再对其他ECU或者传感器进行程序升级。

功能安全

随着车辆功能的复杂性增加，由于EE系统的故障而导致的不安全行为的可能性大大增加。这迫使OEM厂商严格按照安全标准来开发车辆。目前，汽车EE架构事实上的功能安全标准是ISO26262。

TC2xx/TC3xx/TC4xx都可以达到ISO26262 ASIL D的功能安全等级。英飞凌的质量管理体系秉承“零缺陷”的文化理念，在研发AURIX MCU产品过程中拥有一支专业的功能安全开发和管理团队，参与MCU设计，开发和验证中的各个流程。英飞凌不仅可以提供ASIL D功能安全等级的MCU产品，同时还可以提供完整的功能安全文档（如安全手册，FMEDA表格等）以及安全软件库 (Safety Library)。

Figure 11: AURIX Safety Cornerstones

TC3xx系列MCU是全球第一个获得ISO26262-2018证书的MCU产品。

Figure 12: TC3xx ISO26262-2018 Certification

信息安全

网联化是实现未来中央集中式EE架构的基础，万物互联给用户带来便利的同时，也同时会给传统汽车带来安全隐患。在中央集中式EE架构以以太网作为骨干网络，中央处理单元和区域控制器通过以太网进行通信，区域控制器则通过CAN/LIN总线和子ECU，传感器以及执行器通信。

在这个网络中，任何一个ECU/传感器/执行器都可以用OTA进行升级，在这个过程中，如果升级的固件在传输的过程中被黑客非法篡改，那么将会带来严重的后果。这个就要求区域控制器可以支持加密传输，签名，验签，安全启动等功能。

TC3xx MCU内部的Full EVITA HSM模块，包含ARM Cotex-M3的处理器，AES加速引擎， PKC模块和Hash模块。AES加速引擎支持AES128算法（对称加密算法），PKC支持ECC256（非对称加密算法），SHA256，和真随机数产生器。

Figure 13: TC3xx HSM

另外我们的第三方合作伙伴也可以提供符合AUTOSAR规范的HSM商用软件。

Figure 14: TC3xx HSM Software

TC4xx MCU会使用全新的Cyber security realtime module (CSRM)作为可信硬件环境，其中包含最高500MHz Tricore 1.8内核，PKC模块，TRNG和CSS模块，其性能比TC3xx HSM提升5~15倍，更重要的是TC4xx MCU CSRM不仅支持EVITA Full, 而且兼容ISO21434规范。另外TC4xx CSRM除了支持原来TC3xx HSM中的算法之外，还支持SM2/3/4国密算法。

Figure 15: TC4xx CSRM

低功耗

随着电子化程度的推进，高功率及高算力芯片使用率的提升，整车负载的用电需求量也在不断提高。功耗问题处理不好，尤其对新能源车来说，会直接影响其续航里程、成本和客户体验。如何一方面满足功能需求，同时将功耗降到最低，除了系统设计上的优化外，在元器件选型时也要关注不同模式下的功耗指标。

TC3xx/TC4xx MCU把供电域分为主供电域（Power-On Domain）和休眠域两部分（Standby Domain）。主供电域由Vext提供电源，休眠域由Vevrsb提供电源，Vext和Vevrsb可以接在一起，也可以分成两个独立电源供电。当MCU进入休眠模式后，主供电域关闭，休眠域持续工作。在休眠域中有一个休眠控制器（SCR, Standby Controller），它主要以8位的8051内核构成，也可以进行编程，这样就极大得提高了在休眠模式下对于唤醒模式设置的灵活性。下表是SCR的基本资源和休眠模式功耗情况：

Figure 16: SCR/Standby Current

延续性考虑

在OEM或者Tier-1进行区域控制器主控MCU选型时除了产品本身符合应用需求之外，一般还需要考虑研发时间和成本。MCU是ECU中最复杂的半导体器件，研发团队需要花很长时间才能熟悉一个MCU平台。目前TC3xx MCU产品已经在国内多家OEM的区域控制器中得到广泛的应用，这类区域控制器目前主要还是负责车身部分的控制。TC4xx MCU对于TC3xx MCU有很好的兼容性考虑，主要有下面因素：

开发速度：

TC3xx是基于TC1.6.2内核，而TC4xx是基于TC1.8内核，TC1.8兼容TC1.6.2。TC4xx的开发环境和TC3xx完全一样（编译器，调试器等），如果研发工程师已经熟悉TC3xx开发环境，那么对于TC4xx可以迅速上手。

软硬件兼容：

TC4xx和TC3xx大部分外设资源都保持一致，引脚分配也保持很大部分的兼容性。因此，硬件工程师可以沿用大部分之前的设计经验，软件工程师可以沿用各个外设模块的理解，无需再学习一遍。对于相同部分的外设资源，MCAL部分的配置也是保持不变的。

安全概念：

TC4xx沿用了大部分TC3xx的安全概念，例如CPU锁步，Flash/RAM ECC保护，电源和时钟检测等。因此，对于功能安全开发部分，如果之前是基于TC3xx MCU进行开发的，TC4xx也可以沿用大部分的功能安全开发和设计理念。

可靠性：

TriCore内核推出至今已经有20年以上的时间，被多家OEM广泛使用。TC3xx/TC4xx MCU中的很多外设模块也是很老的IP模块，经过20多年的迭代和更新，目前已经变得非常稳定和可靠。