汽车区域控制器的关键技术和MCU解决方案深度分析_汽车mcu com driver(1)_汽车区域控制mcu

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

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个队列发送的数据互不干扰。

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 (VM0VM7)，它支持3套独立CPU内核寄存器，VM0和VM1各独占1套，VM2VM7共享另外1套内核寄存器，因此从VM0或者VM1到其他VM可以快速切换。

Figure 10: Hypervisor Example

4 OTA

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

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

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

5 功能安全

随着车辆功能的复杂性增加，由于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

6 信息安全

网联化是实现未来中央集中式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国密算法。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

辄止，不再深入研究，那么很难做到真正的技术提升。**

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！