ECU is an electronic control unit, a special microcomputer controller for automobiles, which controls all electronic equipment on the vehicle and the driving state of the vehicle through sensors, actuators, and buses. The more complex the vehicle function, the more ECUs are required. EEA is an electrical/electronic architecture, which refers to the design of vehicle software and hardware such as sensors, actuators, ECUs, wiring harnesses, and operating systems to achieve efficient signal transmission and wiring harness layout in the vehicle. The electrical and electronic architecture is evolving with the increase of automotive functions. EEA design needs to comprehensively consider the customer's functional requirements, the difficulty and cost of installation, configuration, maintenance, etc., and it needs to be moderately advanced.
EEA Advanced Route: Simplified Architecture and Concentrated Computing Power
Different OEM and Tier 1 all have their own ideas on the evolutionary path of EEA, with the general tone that it is certainly expected the number of hardware is reduced, the ECU functions are simplified, the computing power is centralized, and the future is clouded concentrated.
Let us take the classic six-stage division proposed by Bosch as an example. The initial state of Generation1 is modular, that is, one ECU only carries one function, and each ECU has embedded software; ECUs are connected by bus technology, in which the more complicated the wiring harness layout, the higher the cost.
Generation2 is distributed and integrated, that is, functional integration brings ECU integration, in which one ECU corresponds to multiple functions; The number of ECUs at this stage has been reduced, but the vehicle ECU has no technological breakthrough.
Generation3 is the functional domain centralized. OEM and Tier1 divide the electronic control unit into several modules according to the function, with different division method; the functions in each domain used to be responsible for multiple ECUs. At this stage, it is unified by a DCU, which has more powerful computing power than ordinary ECUs and is equipped with multi-core processors; common in-vehicle networks such as CAN and Flex Ray are still used in the domain. The communication between domains requires the introduction of a vehicle ether.
Generation4 realizes cross-domain integration, that is, replacing part of DCU with multi-domain controllers (MDC), and integrates data from different functional domains in the same controller for fusion processing. For example, autonomous driving needs to integrate multi-domain signals such as cameras, GPS, and wheel speed sensors.
Generation5 is in-vehicle computer and area architecture of the spatial area. At this stage, only Tesla achieves the goal. Compared with the "functional domain" of Generation3, the area architecture at this stage greatly simplifies the difficulty of the mechanical layout and the length of the wire harness, thus, it is no longer necessary to pull a wire harness from the rear to the front of the car. The internal wiring harness length of Model S is 3 kilometers long, while Model3 is only 1.5 kilometers. Besides, a vehicle-mounted central computer is formed. Model3 is equipped with a central computing module CCM. The computing power continues to be concentrated in a smaller number of central units, and ECUs are no longer even needed. In the future, only simple sensors, actuators, and other devices may be needed.
Generation6 is car-cloud computing, that is, computing power is concentrated in the cloud. For most OEMs, the evolution of EEA is a continuous gradual process, not a jump switch.
Why Is It an Inevitable Trend to Move from Distributed to Centralized?
The essence of development is the emergence of new things and the demise of old things. Initially, the number of electronic components in the car was limited, in which the electrical and electronic architecture was not complicated. OEMs purchased ECMs according to the technology and price advantages of different Tier1s. Only integration, testing, and verification were required, and technical details and codes were not required. For a long period of time, OEM’s work is only to continuously increase ECM and adjust the wiring harness layout according to market demand. The whole vehicle EEA is developed by Tier1 in cooperation with OEM. OEM can put forward function-oriented requirements to Tier1, and other OEMs had no right to speak in design and manufacturing.
Traditional automotive electronic architecture has been unable to keep up with the speed of electronic penetration inside the car, in which the industry is pushing the automotive EE architecture to shift from decentralized ECUs to area control. At the same time, software-defined requirements are about to emerge, and automobiles are in desperate need of a magnificent turn from mechanization to electronics. The trend of automotive electronic architecture toward the centralization of computing power and toward the cloud is becoming more obvious.
The centralized architecture reflects its unique advantages in many aspects. First, the centralized architecture can simplify wiring, reduce assembly difficulty, and decrease vehicle weight. The wiring harness has become the third or second most important part of the whole car. In 2007, the bus length of the Audi Q7 and Porsche Cayenne has exceeded 6km, and the corresponding weight exceeds 70kg. If it continues to use the distributed architecture, in the era of intelligent driving, the weight of the harness can reach 100kg.
Secondly, it can improve computing power and reduce redundancy. Data collected from multiple ECUs are placed in the same DCU or MCU for centralized processing. The dominant DCU or MCU in the domain has stronger computing power than a single ECU, and other ECUs can reduce the waste of computing resources.
In addition, the centralized architecture implements OTA which regularly receives over-the-air software updates through the Wi-Fi network, without the need for 4S shops and U disks, which can improve user experience, reduce maintenance costs, and enable cars to have an experience of constantly updating electronic products.
Finally, it can decouple software and hardware, the first step in software-defined cars. Whether it is a closed software ecosystem represented by Tesla or a semi-open ecosystem such as BYD, it attracts a large number of developers, using the power of third parties to realize its huge potential, which becomes the basis for the prosperity of software-defined cars.
The First and Second Structure of the Echelon Companies Have Laid Out One After Another
The first echelon of Generation5, Tesla directly pushed EEA to the stage of central computing and regional distribution while some of the far-sighted OEMs are still moving towards the stage of domain concentration. Model3 uses CCM to integrate two modules of ADAS and IVI. The functions of other areas are in charge of the left and right body control modules. Also, there are some enterprises working on Generation5 but having not yet launched products, including Toyota's Zonal architecture, BMW and Bosch.
Typical representatives of the second echelon of Generation3&4 are the E3 architecture of the Volkswagen MEB platform, the CC architecture with computing and communications of Huawei, the HOA architecture of Human Horizons, and DiLink and Dipilot of BYD. They have two obvious characteristics. First, the competitive landscape is undergoing a complete reshuffle, in which both traditional giants such as Volkswagen and new forces such as Human Horizons, as well as OEM and Tier 1, have pushed EEA to this stage. The second is that the contestants position themselves as suppliers of the standard platform. Compared with traditional controllers,market demand is more inclined to a complete set of electrical and electronic architecture solutions, in which the industry's cooperative atmosphere is getting stronger.
We provide more professional and intelligent market reports to complement your business decisions.