The development of intelligent cockpit, intelligent driving and intelligent network will promote the continuous increase of new functions. At the same time, the demand for high computing power and large bandwidth data transmission will become more and more urgent, coupled with the concept of "software-defined car", which will jointly promote the upgrading and transformation of the whole vehicle EE architecture; At present, various car companies have gradually started to move from the distributed architecture with independent functions to the domain control architecture with integrated functions, and will eventually move to the centralized architecture with central computing and regional control.
One,Tesla’s "quasi-centralized architecture" leads the trend.
1. Distributed architecture VS centralized architecture
1) Under the distributed architecture, software and hardware are closely coupled, and OEM is more dependent on suppliers. In the process of cooperation, only one technical standard (such as communication information -XX signal, communication form -CAN/LIN, etc.) is provided to Tier1, and each system is provided by different suppliers, resulting in OEM’s vehicle software becoming a mixture of many independent and incompatible software systems. If the OEM wants to change or add new functions, it needs to talk with different suppliers, so it is obviously constrained by suppliers.
Secondly, with more and more ECU, the wiring harness in the car will become longer and longer, which not only increases the weight and cost of the car, but also brings great trouble to the layout and assembly of the car. Moreover, the computing power of each ECU can not be coordinated, resulting in a great waste of computing power.
2) Under the central computing+regional architecture, the computing power is gradually concentrated in the center. First, multiple ecus are merged into a domain controller, and then the domain controllers will continue to merge, eventually forming the ultimate layout of a central computing platform +N regional controllers. At this time, the number of ECU will be greatly reduced, which not only reduces the application cost of ECU and the wiring cost between controllers, but also contributes to the lightweight design of the whole vehicle.
Secondly, the sensors and actuators are connected to the nearby regional controllers, which can better realize the expansion of hardware. At the same time, the structure of the regional controller is easier to manage, and it is easy to realize the automatic assembly of the wiring harness.
2. What is Tesla’s "quasi-centralized architecture"?
In 2019, Tesla has realized the EE architecture scheme of central computing+regional controller on Model3, leading the trend. So what are the advantages of Tesla’s architecture?
The vehicle electronic and electrical architecture of Tesla Model3 is divided into four parts: CCM (Central Computing Module), BCM FH (Front Body Control Module), BCM LH (Left Body Control Module) and BCM RH (Right Body Control Module). CCM (Central Computing Module) consists of three modules: infotainment system (IVI), driver assistance system (ADAS) and communication system inside and outside the vehicle.
1）Front body control module:Responsible for the power distribution of the whole vehicle and the logical control and drive of the electrical appliances in the front compartment of the vehicle;
2）Left Body Control Module:Responsible for the power distribution, logical control and drive of the left-hand electrical appliances, including the convenience control of the left body and chassis control such as steering and braking;
3) Right body control module:Responsible for the power distribution of right-hand electrical appliances, the logical control and drive of right-hand and back electrical appliances, including the convenience control of right body, power system, air conditioning, etc.
Advantages of Tesla EE architecture:
1) The hardware part of the intelligent driving module adopts a self-developed FSD chip; For the software part, the operating system is customized based on open source Linux, and the middleware is developed by itself. The software and hardware are self-controllable, which not only helps to speed up the iterative update of vehicle functions, but also greatly reduces the development cost of the whole vehicle.
2) On the software architecture level, SOA architecture is adopted to facilitate the deployment of SOTA and the collection and analysis of cloud data.
There is no doubt that Tesla’s electronic and electrical architecture is advanced. Its central computing module -CCM integrates intelligent driving module, audio-visual entertainment module and in-vehicle networking module, and shares a liquid cooling system. Basically, the prototype of centralized architecture is realized, but it is not a centralized architecture in the strict sense. The industry calls this type "quasi-centralized architecture".
Therefore, even Tesla is still a long way from a truly centralized architecture. Considering the technical maturity and cost at that time:
1) The communication architecture is still relatively traditional, mainly based on CAN bus, and the control is still distributed on MCU, and the basic software of MCU adopts FreeRTOS.
2) The central computing module CCM is separated: only the MCU of audio-visual entertainment, the FSD of intelligent driving and the networking module inside and outside the vehicle are formally integrated on one board, but each module still runs its own operating system independently and completes its own tasks independently.
Even so, Tesla is still a practitioner of the most advanced concept of central computing+regional control architecture, which has triggered the learning and catching up of other peers in the industry.
Second, the "chaser" of the domestic Tesla EE architecture
In the era of intelligent and software-defined cars, whoever can master the dominance of EE architecture and software will occupy the commanding heights of the smart car market. Therefore, domestic mainstream vehicle companies are also actively carrying out relevant layout, and the mass production models of "quasi-centralized" architecture scheme will be launched around 2022-2023.
edit
However, the centralized architecture of OEM planning is not too unified in form. For example, the vehicle computing platform of SAIC Zero Beam adopts two HPC high-performance computing units; The scheme of GAC or Great Wall adopts three major computing platforms: central computing platform, intelligent driving domain and intelligent cockpit domain. But generally speaking, the R&D design concept is similar: the hardware adopts the architecture scheme of central computing+regional control, and the software adopts the design concept of SOA software architecture.
1. SAIC Zero Beam-Galaxy Full Stack 3.0 Scheme
Hardware platform:It consists of two HPC high-performance computing units, HPC1 and HPC2, and four ZONE controllers. Two high-performance computing units are used as the computing center of the whole vehicle to realize the functions of intelligent cockpit, intelligent driving and redundant backup of intelligent driving; Four area controllers are used to realize the related functions of different areas.
Galaxy Full Stack 3.0 Hardware Platform (Source: SAIC Zero Beam Presentation Materials)
Remarks:
1) In August, 2021, SAIC Zero Beam and Xinchi Technology reached a strategic cooperation, and based on the Zero Beam Galaxy Full Stack 3.0 architecture, they will jointly formulate the development roadmap of the chip and vehicle electronic and electrical architecture; At the same time, the two sides will jointly explore and jointly develop a narrow operating system suitable for full stack 3.0 around the chip-level underlying software operating system and virtualization platform technology;
2) In September, 2021, SAIC Zero Beam announced that it had jointly designed and developed the HPC based on "Zero Beam Galaxy Full Stack 3.0".
Software platform:Adopt SOA integrated software platform of cloud management.
1) The software platform is decoupled from the hardware chip and the operating system. Even if the chip types and operating systems of different EE architecture platforms are different, the software platform can still be translated and reused. For example, Zero Beam’s 1.0 architecture platform and 3.0 architecture platform still use the same software platform, although the underlying hardware and operating system are different.
2) In the application layer, through middleware and SOA atomic service layer, a unified and standard API interface can be provided upwards, which makes the application layer development easier and more reusable. At the same time, coupled with the software platform SDK, OEMs, suppliers, third-party developers and users can all join in the application development and realize the co-creation of application ecology.
Galaxy Full Stack 3.0 Software Platform (Source: SAIC Zero Beam Presentation Materials)
2. Gac ean-Spirit architecture
1）Hardware platform:Spirit architecture consists of digital mirror cloud, three core modules and four regional controllers (left/right/front/back). Among them,The three core computer modules include central computing unit, intelligent driving domain control module and cockpit domain control module; The central computing unit covers the new energy control module and the body control module, and is responsible for controlling the functions of vehicle running, braking and vehicle equipment.
- The CPU is equipped with NXP S32G399 gateway computing chip, which is composed of 8 A cores and 4 M cores, and has built-in LLCE+PFE acceleration engine, and the communication delay is ≤ 20μ s.;
- Cockpit control module is equipped with Qualcomm 8155/8295 chip, 7nm process, 105K DMIPS computing power, and supports 3D character image rendering, face recognition, AR-HUD and other functions.;
- The intelligent driving domain control module is equipped with Huawei Shengteng 610 high-performance chip and 7nm process, which supports the expansion of computing power of 200~400TOPS. The image processing capacity of ISP can reach 2.4GPix/s, which can cope with complex road conditions such as high speed and cities.
Spirit Architecture Hardware Platform (Source: Guangzhou Automobile Ai ‘an Presentation Materials)
2) Software platform:SOA software architecture with layered design is adopted.
- Basic intermediate layerAdopt atomic service encapsulation and standardized interface;
- Dedicated intermediate layerAdopt enhanced combination service, which can be executed independently;
- APP software layerIs an independent component decoupled from the bottom layer and can directly call the service.
The software architecture realizes service, atomization and standardization of components, decoupling of software and hardware, improving the ability and speed of OTA, and realizing plug and play of hardware-adding new application modules can realize new scenarios.
Spirit Architecture Software Platform (Source: Guangzhou Automobile Ai ‘an Presentation Materials)
3. Great Wall Motor-GEEP4.0 architecture
1) Hardware platform:GEEP4.0 architecture consists of central computing platform (CCU), intelligent cockpit module (HUT), intelligent driving module (ICU), and three regional controllers (VIU_L, VIU_R and VIU_F).
Central computing unit CCUThe main responsibility of CCU is to deal with the functions of auxiliary autopilot, power, chassis, car body, air conditioning, car body status and mode management in a centralized way. Under the high-order autopilot configuration, CCU can be used as a backup of L3 domain controller to achieve the lowest risk conditions.
3 regional controllers:Is a standardized control unit.,Divide, deploy and develop according to the body domain, and arrange them on the left, right and front respectively, which is responsible for integrating some MCU around, that is, integrating ECU, power supply, controller and input/output. At present, most of the software algorithms of the three VIUs have been moved to CCU and developed by Great Wall Software Team. VIU only keeps a small part of logic, and it is more responsible for driving I/O.
GEEP4.0 hardware platform (Source: Great Wall Motor Technology Sharing Salon)
2) Software platform
- On the application software level, integrate big data, cloud diagnosis, information security and other software systems to achieve functional integration;
- Deploy different domain software in different cores-MCU core adopts CP Autosar, and deploy different domain electronic control software in multiple MCU cores respectively; The HPC core adopts Linux OS and AP Autosar middleware;
- By deploying software in different domains in different cores, the integration between multiple domains is opened horizontally, and the communication between the underlying hardware, operating system (CP autosar, Linux OS), middleware (AP autosar), protocol stack and application software is opened vertically.
- Support FOTA, planning some comfort functions will support SOA.
GEEP4.0 software platform (Source: Great Wall Motor Technology Sharing Salon)
4. Tucki X-EEA3.0
In November 2021, Xpeng Motors released the Tucki G9 at the Guangzhou Auto Show, which is scheduled to be listed in 2022; The car adopts Tucki’s brand-new X-EEA 3.0 architecture. At present, the official customs of Tucki has not revealed too many specific technical details. The author has compiled the following information for your reference:
- Hardware architecture:Central supercomputing+regional control;
- The software platform architecture is divided into three layers.System software platform, basic software platform and intelligent application platform;
- Communication architecture:Adopt gigabit Ethernet communication;
- Data schema:Realize non-inductive OTA- The domain controllers all control the memory in partition isolation, one area is used for upgrading and the other area is used for normal operation of vehicles; Therefore, even when the vehicle is driving normally, OTA upgrade of new functions can still be carried out at the same time;
- Power architecture:The power supply of electrical equipment is controllable, and intelligent and accurate power distribution is carried out according to user scenarios, which reduces unnecessary power waste and optimizes the use of electricity.
Third, the impact of the upgrade of EE architecture
1. Reshaping the supply chain system
Under the traditional distributed architecture, the software is highly coupled with ECU. OEM has a strong dependence on Tier1, which is dominant, and the software and hardware are directly supplied to OEM by packaging. The industrial chain is relatively simple, with software product suppliers/chip suppliers (Tier2) in the upstream, component integrators (Tier1) in the midstream, and vehicle integration plants (OEMs) in the downstream.
With the upgrading and transformation of electronic and electrical architecture, the hardware is gradually standardized, the software is separated from the hardware, and the software and hardware are decoupled, making it a reality to define the automobile by software. Therefore, OEM’s ability to master software-defined cars has become more intense, and they hope to gradually regain the long-awaited "dominance" from Tier1.
To this end, enterprising OEMs began to set up software teams to improve their software research and development capabilities, but there is still a long way to go. In this context, some people have seen the strong demand of car companies for the "self-developed and controllable" cooperation mode, so a new species-Tier 1.5 has emerged, which can support the customization of OEM products upwards and integrate and integrate Tier2 resources downwards, in order to get a share of this "dominance" battle.
At the same time, in order to maintain its dominant position, the traditional Tier1 has also started to vertically integrate and build the R&D capability of the whole stack of software and hardware, transforming from a component supplier to a system solution provider, that is, upgrading from Tier1 to Tier0.5-it can not only provide OEM with software and hardware integrated products, but also provide full-process services from pre-technical research and development to post-data sharing, hoping to maintain a "close" relationship with OEM.
2. Changes in the industry competition pattern
At present, enterprises engaged in research and development of advanced EE architecture can be roughly divided into three categories: vehicle enterprises, Tier1 and technology companies. Vehicle companies have a strong motivation to master the core technology and component dominance of centralized EE architecture, because they have already seen the benefits that this dominance brings to Tesla. However, in the short term, there are still a few vehicle companies that can realize all the self-research of these technologies and components. Most vehicle manufacturers will still rely on Tier1, technology companies and other suppliers to complete it together.
The development project of the vehicle electronic and electrical architecture is complex and the technical link is long. Only the players in the industrial chain can cooperate with each other in each link, give full play to their respective advantages, and form a joint force to achieve the effect that 1+1 is greater than 2. Only in this way can we help the whole vehicle enterprises to complete the upgrading of the architecture more quickly.
For OEM, we will choose the cooperation mode that suits us according to our actual situation:
1) For head car companies with strong R&D capabilities, such as Tesla, they will choose self-research in key core areas such as chip, operating system, middleware and domain controller system integration, while outsourcing some hardware production.
Secondly, the automatic driving perception algorithm is relatively complicated. Even some head car companies will choose to jointly develop the perception algorithm with software companies with strong strength in the industry. In this process, most of them will also learn from teachers, gradually improve their perceptual algorithm ability, and finally move closer to the goal of self-research in the whole stack.
2) For car companies with relatively weak software research and development capabilities, it is necessary to distinguish what is common and what is individual. Considering its own research and development strength and cost pressure, the common part can only be strategically abandoned and handed over to the right supplier to help it complete the development; For the part of personality, you need to do your best to differentiate and create your own brand power. For example, a domain controller or a central computing platform needs Tier1 or a software company with full-stack R&D capability to help it gradually open in layers, and then do personalized and differentiated development at the application layer.
At present, the demand of the main engine factory is personalized and diversified, and most of them tend to ask suppliers for customized development according to their own needs. At the same time, OEM is also trying to improve its own software development ability; In the long run, for Tier1 and the technology companies that intend to do Tier1, it is a general trend that the development rights of some software functions of domain controllers or central computing platforms are "taken back" by OEMs. Therefore, Tier1 and technology companies are also striving to build full-stack technology research and development capabilities for software and hardware to avoid becoming "hardware foundries" for OEMs.
3. The new opportunities brought by the upward breakthrough of EE architecture
In the critical period when intelligent driving entered the second half of the competition, OEM began to upgrade its electronic and electrical architecture to cope with the development of automobile intelligence and networking. In this critical time window, whoever can help OEM to take the lead in realizing the rapid replacement and iterative upgrade of hardware modularity, as well as the portability and maximum reuse of software modules, will win the favor of the OEM and gain a foothold in the new market.
The so-called times make heroes, so which types are more likely to appear "heroes" on the "new outlet"? The author judges that there will be the following types:
1) Dali AI Chip Company-the electronic and electrical architecture is developing rapidly towards domain centralization and central domain control. For OEMs, the choice of high-performance Dali computing platform is a top priority. Therefore, the suppliers of large computing chips will usher in a growing market space. In particular, some chip companies that have recently grown up in China-open system solutions, ability to understand localized scenes, and good engineering supporting services are their current advantages.
2) Domain Controller Integrator-With the upgrading of the electronic and electrical architecture of the whole vehicle, the penetration rate of domain controllers has been promoted, and the emerging market of domain controllers will have great growth space in the future. Domain controller integrators with reliable product quality, which can also greatly save costs and shorten the development cycle for OEMs, will usher in an opportunity for development.
3) Supplier of basic software platform-For the OEM with weak software power, there is no need to re-develop the common part of the basic software platform, because it will not be perceived by consumers. Therefore, you can choose to give this part to the appropriate basic software platform supplier, which can not only reduce your development difficulty and cost, but also use your own manpower and financial resources for the key personalized development part; It is conducive to shortening the product development cycle and bringing it to market as soon as possible.
4. What are the challenges to realize the central computing+regional control architecture?
1. The bottom "chip" foundation determines the height of the upper "architecture"
High-order autonomous driving requires more and more computing power. Carrying chips with more advanced process and stronger performance has become the primary problem to be considered in architecture design, because the mass production time of the planned chips will affect the landing time of the architecture scheme.
When designing the central computing+regional architecture, the central computing platform needs to meet the needs and characteristics of all domains at the same time. Therefore, it needs more powerful chips and a combination of various operating systems. The biggest challenge is to select the available chips. However, at present, there are no mass-produced chips that can meet the requirements of several functional domains at the same time, so most OEMs still adopt the scheme of piecing together multiple chips:
1) Vehicle control system: Generally, MCU is adopted, which runs mature Classic AUTOSAR basic software, which requires high real-time performance and safety level, but its computing power and storage are limited.
2) Intelligent cockpit and intelligent driving field need high-performance and powerful SoC chips, and also need to run complex operating systems, supplemented by middleware.
Secondly, there are more and more players in the field of in-vehicle with high computing power and high performance chips, and the iteration speed of chips is getting faster and faster. If the whole technical architecture needs to be reconstructed every time the chips are replaced, it will seriously affect the development speed of new products. Therefore, the central computing platform needs to have good expansibility, not only a unified sensor and peripheral interface, but also good chip compatibility.
2. Software Capability and Software Team Building
Software capability At present, the mainstream functional domain architecture can be divided into five domains: body domain, chassis domain, power domain, intelligent cockpit domain and autopilot domain. In the process of developing to a centralized architecture, cross-domain integration is inevitable, such as integrating the body domain, chassis domain and power domain into a vehicle control domain, and the ultimate goal in the future is to integrate all functional domains into a central brain. In this development process, not only need to build a large number of software function service capabilities; At the same time, powerful software capabilities are needed to cope with the system collaboration among the underlying real-time operating system, AUTOSAR and other key software modules.
Another embodiment of software capability is that OTA, especially FOTA, requires OEM to have strong software development capability and be able to develop the control software of the underlying executive parts, so as to truly realize the function or performance of software-defined cars.
In 2018, the American Consumer Report magazine pointed out that Model3 had serious problems in emergency braking at high speed. When Model3 is driving at 60 mph, its braking distance is about 46.3 meters, which is higher than other models in the same class. To solve this problem, Model 3 upgrades the firmware by pushing it remotely. The end result is that the emergency braking distance of Model3 is shortened by about 6.1 meters through OTA.
The hardware of the Model 3 braking system is Bosch’s iBooster, but the electric control software at the bottom is developed by Tesla, so the characteristics of the brake pedal can be adjusted through OTA upgrade, that is, the braking force can be optimally distributed during the whole braking process by adjusting the braking response curve, thus shortening the braking distance.
Software team building- If OEM wants to realize the real software-defined car, that is, most functions and performances of the car are defined by itself, then its own research and development ability, especially the software research and development ability, will be a big test. Now powerful OEMs are setting up software R&D teams on a large scale, and software developers are obviously in short supply in the talent market. Even if you are willing to "seduce" with high salary and options, it is difficult to "set" the right talents. At the same time, the management and coordination of software teams are also complicated, which is where traditional OEMs need to carry out intensive learning again.
3. The problem of organizational system
Traditional OEM has a R&D team, a product system and a supply chain system that have been gradually built and improved for many years. However, there will be more things to consider and worry about when the whole vehicle EE architecture changes, such as the reusability of the original production line, the compatibility of the architecture with the huge product line, and the supply chain problems around the world.
A major feature of the centralized architecture is that the computing power is concentrated in the center. In this case, many ecus will definitely be cut off. If a large number of ECU’s are cut off in the car, it is a matter of life and death for employees who rely on these parts and related suppliers. If they can’t make internal and external adjustments, it will be difficult for the new architecture to be promoted and implemented quickly.
To some extent, the traditional OEM has become a "double-edged sword" by virtue of the advantages of supply chain and product system accumulated over the years, and it has begun to hinder them from carrying out architectural innovation. Therefore, it is impossible for them to "cut across the board" when carrying out the structural reform, completely demolish the previous scheme and switch to the new E/E architecture. They can only use the existing resources to make a gradual transition and evolution, and gradually improve their own software R&D capabilities and change their R&D organizational structure to adapt to the new R&D process.
The new forces that build cars have no concerns in this regard, and they can start from scratch. Although it doesn’t accumulate as many past resources as traditional OEM, and it doesn’t have the previous historical burden, it can make new attempts without scruple.
Therefore, from this point of view, the huge organizational system of traditional OEMs has really held them back.
References:
1. How did Neusoft Ruichi start the "future battle" in the second half of the decisive battle for intelligent driving?
https://mp.weixin.qq.com/s/2xl36RUBYqcIz3qEe3nlKw
2. Fully open the standard API interface. Great Wall Motor’s new electronic and electrical architecture creates an open service ecosystem.
https://mp.weixin.qq.com/s/jJvwOAx7wS3VSaDOjbDjeg
3. Analyze the electronic and electrical architecture of Xpeng Motors X-EEA 3.0 better than you think.
https://mp.weixin.qq.com/s/O1evq-Qx4WddEX-Tz4SYWA
4. After the popularity of functional domain architecture, regional architecture may be widely used in 2023-2025.
https://mp.weixin.qq.com/s/xvvG_cuhbGplBHN3taWOAg
5. What is the core of a software-defined car? Talk about the new generation Tesla electronic and electrical architecture
http://www.eeaconference.com/news/751649/
6. Talking about Tesla’s EEA
https://mp.weixin.qq.com/s/-cJUCXh8SviiGege8dXR7A
7. Vehicle architecture reform, domestic domain controller manufacturers welcome development opportunities (securities report)
https://new.qq.com/omn/20211102/20211102A030EP00.html
8. SAIC Zero Beam Zeng Jienan: Cloud-tube integrated central computing platform solution
https://new.qq.com/omn/20211102/20211102A030EP00.html
9. SAIC Zero Beam and Chuangshi jointly developed the Galaxy Full Stack 3.0 cabin driving integrated HPC.
https://mp.weixin.qq.com/s/nGjrX8iYhT-J1DN5loBy3A
10. Open a new era of "software-defined automobile", and analyze the new "Spirit architecture" of GAC’s safety.
https://mp.weixin.qq.com/s/7A-SBO3kp8bGoI-oW99qlg
11. Smart car architecture analysis
