In-depth analysis of key technologies and MCU solutions for automotive zone controllers

Figure 8: TC3xx/TC4xx MPU

In addition, the various functions in the regional controller will also use different MCU peripheral channels, and the peripherals also need to be well isolated. In TC3xx/TC4xx, each peripheral channel has access protection (Access Protection), which is implemented by assigning a master tag ID to each SRI bus master. Each peripheral channel can set which masters are allowed to access the channel. In this way, different peripherals can be assigned to different cores for access, thereby ensuring that other cores will not illegally control resources that do not belong to the core.

Virtualization Technology

The centralized architecture also has a huge impact on the organizational structure of the R&D team. In the future, multiple ECU functions may be integrated into the regional controller, and the R&D personnel who originally developed these functions may come from different teams, which will lead to several problems:

- How to coordinate these R&D personnel to develop regional controllers? It is necessary to consider that the development environments (such as operating systems, compilers, debuggers, etc.) used by these R&D personnel may be different.

- How to reuse software from previous projects?

- How to enable these R&D personnel to develop synchronously without interfering with each other?

Let me give you an example (which may not be true in reality). Now we need to develop a regional controller (placed in the left body domain). This regional controller must at least realize the I/O control and detection of the left body domain (similar to the previous BCM function), as a gateway for the body, and also as a power distribution center for the left body domain. Finally, we may have to consider the ability to perform firmware upgrades (OTA) for each ECU mounted on it. Assume that the original BCM and gateway software were developed by two different R&D teams, and they used different OS. Now we want to reuse the previous BCM and Gateway software, and then redevelop the left body domain power distribution center and the firmware upgrade function for each ECU. So how can we complete this project efficiently?

Virtual Machines (VMs) solve these problems perfectly. A virtual machine is a piece of software that encapsulates and executes other software by simulating a physical machine. The software being executed can be a single program or a complete operating system that performs tasks in the usual way. Hypervisor is an intermediate software layer that divides processing, memory, and communication resources between virtual machines, and schedules and migrates simultaneously running virtual machines to different resources. One of the main uses of virtualization is to integrate ECU functions that require different operating systems, as well as different versions of the same operating system.

From a microscopic point of view, each CPU core supports multiple VMs (such as vm0~vm7), and each VM actually time-shares the CPU, and each VM can use Level 2 MPU to isolate data and code. From a macroscopic point of view, each function can be implemented by a VM, and each VM actually corresponds to one or more CPUx.vmy.

Taking the above regional controller as an example, the BCM function is implemented by VM1 (assuming that it was originally made of a three-core MCU), the Gateway function is implemented by VM2 (assuming that it was originally made of a three-core MCU), VM3 implements the regional power distribution function, and VM4 implements the OTA function. VM1 actually contains cpu0.vm1, cpu1, vm1, cpu2.vm1, while VM2 actually contains cpu0.vm2, cpu1.vm2, cpu2.vm2, VM3 uses CPU3.VM1, and VM4 uses CPU3.vm2. In this way, VM1 and VM2 can still reuse the previous software (although they used the old version of AUTOSAR software and operating system), while the newly developed functions VM3 and VM4 can use the new AUTOSAR version. These virtual machines are managed and called by Hypervisor. In fact, the vm0 of each CPU runs in Hypervisor mode, which is used to schedule the virtual machines of each CPU, and the vm0 collection of all CPUs is the so-called Hypervisor mode in a macro sense.

Figure 9: Hypervisor Example

In addition, each peripheral channel can also set its own access protection (Access Protection). Each peripheral channel can set which VMs are allowed to access the channel, thereby achieving resource access isolation between VMs.

TC4xx MCU uses TC1.8 TriCore™ core, which supports virtual machines. Each core supports 8 VMs (VM0~VM7), which supports 3 sets of independent CPU core registers, VM0 and VM1 each have 1 set, and VM2~VM7 share another set of core registers, so it is possible to quickly switch from VM0 or VM1 to other VMs.

Figure 10: Hypervisor Example

4. OTA

The centralized architecture will make the hardware platform unified, including controllers, sensors, actuators and various interfaces. The realization of different functions is distinguished by software running on various hardware platforms, thus truly realizing "software-defined cars". The future regional controller is the hub of a certain area on the car. It needs to be able to update the software of various ECUs, sensors, and actuators mounted on it, and it also needs to be able to update its own software.

TC3xx/TC4xx MCUs can achieve non-sensitive OTA, that is, TC3xx/TC4xx MCUs have two independent banks of Flash. When the program is running in one bank of Flash, the updated program can be written to the other bank. During this writing process, the operation of the program itself will not be affected.

In addition, TC3xx/TC4xx MCU can support EMMC interface with a maximum access speed of 400Mbps. The updated firmware of other ECUs or sensors can be placed in the external EMMC memory, and the program of other ECUs or sensors can be upgraded when the time is right.

5. Functional safety

As the complexity of vehicle functions increases, the possibility of unsafe behavior due to failure of EE systems increases significantly. This forces OEMs to develop vehicles strictly in accordance with safety standards. Currently, the de facto functional safety standard for automotive EE architecture is ISO26262.

TC2xx/TC3xx/TC4xx can all reach the ISO26262 ASIL D functional safety level. Infineon's quality management system adheres to the "zero defect" cultural concept. In the process of developing AURIX™ MCU products, it has a professional functional safety development and management team that participates in various processes in MCU design, development and verification. Infineon can not only provide MCU products with ASIL D functional safety level, but also provide complete functional safety documents (such as safety manuals, FMEDA forms, etc.) and safety software libraries (Safety Library).

Figure 11: AURIX™ Safety Cornerstones

The TC3xx series MCU is the world's first MCU product to obtain the IEC26262-2018 certificate.

6. Information Security

Networking is the foundation for realizing the future centralized EE architecture. While the Internet of Everything brings convenience to users, it also brings safety risks to traditional cars. In the centralized EE architecture, Ethernet is used as the backbone network. The central processing unit and the regional controller communicate through Ethernet, and the regional controller communicates with the sub-ECU, sensors and actuators through the CAN/LIN bus. In this network, any ECU/sensor/actuator can be upgraded using OTA. In this process, if the upgraded firmware is illegally tampered by hackers during the transmission process, it will bring serious consequences. This requires the regional controller to support encrypted transmission, signature, signature verification, secure boot and other functions.

The Full EVITA HSM module inside the TC3xx MCU includes an ARM Cotex-M3 processor, an AES acceleration engine, a PKC module, and a Hash module. The AES acceleration engine supports the AES128 algorithm (symmetric encryption algorithm), and the PKC supports ECC256 (asymmetric encryption algorithm), SHA256, and a true random number generator.

Figure 13: TC3xx HSM

In addition, our third-party partners can also provide HSM commercial software that complies with AUTOSAR specifications.

Figure 14: TC3xx HSM Software

TC4xx MCU will use the new Cyber ​​security realtime module (CSRM) as the trusted hardware environment, which includes a 500MHz Tricore 1.8 kernel, PKC module, TRNG and CSS module. Its performance is 5~15 times higher than that of TC3xx HSM. More importantly, TC4xx MCU CSRM not only supports EVITA Full, but is also compatible with ISO21434 specifications. In addition to supporting the algorithms in the original TC3xx HSM, TC4xx CSRM also supports SM2/3/4 national encryption algorithms.

Figure 15: TC4xx CSRM

7. Low power consumption

With the advancement of electrification, the utilization rate of high-power and high-computing chips has increased, and the power demand of vehicle loads has also been increasing. If the power consumption problem is not handled properly, especially for new energy vehicles, it will directly affect its range, cost and customer experience. In order to meet functional requirements while minimizing power consumption, in addition to optimizing system design, it is also necessary to pay attention to power consumption indicators in different modes when selecting components.

TC3xx/TC4xx MCU divides the power supply domain into the main power supply domain (Power-On Domain) and the sleep domain (Standby Domain). The main power supply domain is powered by Vext, and the sleep domain is powered by Vevrsb. Vext and Vevrsb can be connected together or divided into two independent power supplies. When the MCU enters sleep mode, the main power supply domain is turned off and the sleep domain continues to work. There is a sleep controller (SCR, Standby Controller) in the sleep domain. It is mainly composed of an 8-bit 8051 core and can also be programmed, which greatly improves the flexibility of the wake-up mode setting in sleep mode. The following table shows the basic resources of SCR and the power consumption of sleep mode: