Key Technologies for Automotive area Controllers

After a century of development, the automotive industry has entered its most exciting time ever, with technological advances promising unparalleled safety, higher productivity, and better environmental benefits. But pure electric vehicles with autonomous driving capabilities are unlikely to become mainstream or affordable overnight. OEMs realize they need to build the right architectural foundation for the vehicles of today and tomorrow. Area controllers are an important part of the overall vehicle EE architecture. This paper discusses the key technologies to implement area controllers and MCU solutions.

A zone controller is a node in a vehicle that provides power distribution, data connectivity, and I/O acquisition and drive requirements for various sensors, actuators, and other devices in a physical area of the vehicle. MCU is the brain of the zone controller, and the MCU in a zone controller generally needs powerful processing capabilities, a very rich communication interface, and a certain level of functional safety and information security. Here are some key technologies and MCU solutions for regional controllers.

1. High computing power multi-core processor

EE architecture vehicles around regional controllers and central computing units will reduce the number of ECUs in the vehicle but also increase the processor load of some ECUs because more functions are deployed. Physically, the regional controller is a logical centralization point for multiple ECUs, which places a higher demand on the arithmetic power of the MCU in the regional controller. While traditional single-function ECUs often use lower-performance single-core MCUs to meet the requirements, for regional controllers, high-performance multi-core MCUs are often required to meet the requirements. In a multi-core MCU, each core can run a separate function, and multiple cores can achieve multiple functions, thus achieving the convergence of multiple ECU functions.

The TC3xx microcontroller is a 2nd generation AURIX? product with up to six TriCore? 1.62 embedded cores. Each clocked at up to 300 MHz. the following figure shows the TC39x family of MCU modules in the TC3xx family. The TC39x has an arithmetic power of 4000 DMIPS.

The TC4xx microcontrollers are 3rd generation AURIX? products with up to six TriCore? 1.8 embedded cores, each clocked at up to 500 MHz, and an integrated PPU coprocessor for fast vector operations, basic neural network algorithms, and other complex mathematical algorithms. The PPU can be used in future area controllers for modeling, model predictive control, and some information security algorithms such as anti-intrusion detection. The following figure shows the module diagram of TC4Dx MCU in the TC4xx family. The TC4Dx has 8000DMIPS+72GFlops*1 arithmetic power.

2. Connectivity and Interoperability

Each sensor and actuator in the area controller system is connected to the local area controller according to its location. Then the area controller performs some data frame format conversion, aggregates the data, and transmits it to the central processing unit via high-speed Ethernet. The area controller typically communicates with the sensors and actuators mounted on it via the controller CAN or LIN bus or with the camera or other ADAS sensors via low-speed Ethernet or LVDS. This requires the master MCU of the area controller to have a rich communication interface for CAN and LIN and a high-speed Ethernet interface. There is also a communication latency issue to consider in the process of data forwarding in the area controller. In a centralized architecture, most control and actuation commands are sent from the central processing unit. Some commands (e.g., chassis and power) have strict requirements for latency, so there are also requirements for the latency time of forwarding from the high-speed Ethernet to the CAN/LIN/Low-speed Ethernet interface in the area controller.

The TC3xx/TC4xx family has an extensive CAN/LIN/Ethernet communication interface.

The TC4xx products have a dedicated hardware communication routing module, CRE (CAN Routine Engine)/DRE (Data Routine Engine), which integrates four CAN nodes in one CAN module. When CAN nodes in different modules be forwarding data or CAN nodes are forwarding data between CAN nodes and Ethernet, can the data be forwarded directly by CRE+DRE without CPU and software intervention?

This direct data forwarding by the hardware routing engine greatly reduces the data latency to at least 15us for CAN to Ethernet and at least 5us for CAN to CAN.

In the future centrally integrated EE architecture, the communication data volume is increasing, and high-speed Ethernet is gradually becoming the backbone of EE architecture. To consider data communication security and redundancy, the Ethernet ring architecture is becoming mainstream. The area controller and central control unit are both nodes in the Ethernet ring frame. 2 x 5Gbps high-speed Ethernet interfaces and 4 x 10/100Mbps interfaces are available in the TC4Dx, and 2 x high-speed Ethernet are connected to the Ethernet ring (1 in and 1 out), and 4 x low-speed Ethernet can be connected to radar or camera sensors. The two high-speed Ethernet interfaces can be connected to the Ethernet ring (1 in, 1 out), and the four low-speed Ethernet interfaces can be connected to radar or camera sensors. Two high-speed Ethernet interfaces can be directly forwarded via the integrated high-speed Ethernet bridge (G-Ethernet Bridge), and the four low-speed Ethernet interfaces can be directly forwarded via the low-speed Ethernet bridge (L-Ethernet Bridge). Ethernet frames can also be forwarded directly between the Low-speed Ethernet interface and the high-speed Ethernet interface via the Low-speed Ethernet Bridge + DRE + high-speed Ethernet Bridge. This approach significantly reduces the delay time for data forwarding between Ethernet interfaces.

In an Ethernet backbone network with central processing units and regional controllers as nodes, there are often multiple Ethernet data frames that need to be transmitted. Some data need to be transmitted deterministically (e.g., control data), some data take up a lot of bandwidth (e.g., audio/video data, ADAS sensor data, etc.), and some are regular data (e.g., no requirement for transmission delay). Therefore, in this backbone network, Ethernet frames need to be classified to ensure that control data can be sent out within a controlled delay time, and audio/video or ADAS sensor data must be transmitted normally without interfering with the transmission of other Ethernet frames in the network and causing blocking of other high-priority Ethernet frames.

Ethernet TSN protocol is a good solution to this problem, where IEEE802.1Qav implements traffic shaping, priority classification, and queue management, which is a good solution to the problem of data conflict, while IEEE802.1Qbv formed on this basis implements the time-shaping (Time-aware Shaper) mechanism, which allows the port to control the traffic according to a certain time base whether Allowed to transmit, the transmission of the switch through the Transmission Gate (Transmission Gate) and Gate Control List (GLC) to control. This time slot division mechanism isolates the time-sensitive message flow and other ordinary message flow to achieve deterministic transmission of time-sensitive messages, making the message arrival time predictable, and avoiding the interference of ordinary messages to improve real-time. IEEE802.1AS then to the Ethernet network in each node to provide a time synchronization mechanism, IEEE802.1AS-rev in this basis and added the concept of master clock redundancy and multiple time domains.

Previous: In-vehicle Ethernet Recorder Solution?

Next: Foundations for Software Defined Vehicles - FOTA, SOTA Solutions