Introduction: As modern vehicles become increasingly complex, the number of Electronic Control Units (ECUs) in vehicles has also increased. A typical car now has as many as 70 to 80 ECUs, with around 100 million lines of code, far exceeding the complexity of an Android phone system. In the traditional automotive supply chain, different ECUs come from different suppliers, each with its own embedded software and underlying code. This distributed architecture creates significant redundancy at the vehicle level, and traditional automotive software updates are almost synchronized with the vehicle’s lifecycle, greatly impacting user experience. How can we accelerate software innovation and iteration? The concept of ‘domain’ arises as we evolve from traditional distributed architectures to centralized architectures. In the face of industry changes and technological developments, only the fittest survive. In the design of ‘domains’, major automakers and suppliers are like the Eight Immortals crossing the sea, each displaying their unique skills. Single-function controllers are no longer mainstream; the focus of the entire vehicle is more on system solutions and software integration control. Only by mastering the comprehensive ‘domain’ control concept can one truly stand firm and become the strongest contender in the upcoming market opportunities..
Development Path of Electronic and Electrical Architecture
1. Modular and Integrated Architecture Solutions In traditional vehicle electronic and electrical architecture systems, functions are typically divided into different module areas, such as powertrain, infotainment, chassis, and body. Within each module area, the design of controllers is usually based on specific functions, such as: Seat Control Unit (SCU), Tailgate Controller (PLG), etc. Information is transmitted between modules via the CAN bus, and the division of modules is generally based on the number of buses, making the bus the navigator of traditional functional modules. This is why we refer to certain specific buses as Power CAN, Body CAN, etc.
The biggest feature of such architecture solutions is clear functional division, with strict boundaries between modules. Any ‘cross-boundary’ behavior is easy to control. Due to the strong independence between modules, module developers do not have to consider interference from other modules too much.
For example, the powertrain does not have to worry about interference from signals on the body CAN, nor does it need to worry that instability in body functions will affect the performance of the power system.
However, this architecture also has significant limitations. The independent development model of functional controllers resembles a closed tribal culture; while it ensures self-sufficiency within its ecological environment, the isolation of information and limited bandwidth for signal transmission leads to an inability to share resources, resulting in a significant waste of computational resources and severe ‘specialization’ issues. For instance, in a tribe with ten villages, Village A has a specialized blacksmith, while Villages B, C, and others do not, so although Village A has a powerful armed force, the remaining nine villages lack defense capabilities. Once war breaks out, 90% of the villages will quickly fall, and even if Village A can protect itself, the entire tribe will face disaster. In this example, the ‘blacksmith’ represents many control algorithms in the body, such as thermal management algorithms and filtering algorithms in EMS, which are very capable, but other controllers, such as tire pressure control, tailgate control, and window pinch protection, cannot utilize this computational power and can only obtain a limited amount of data through CAN signals. This ultimately leads to inconsistent functional effects, making it difficult to achieve a perfect user experience.
Such examples may be acceptable in low functional safety or L2-level autonomous driving applications, but once it involves L4-level or ASIL-D level and above functional safety, the defects of modular closed architecture design will be magnified, becoming the biggest obstacle to positive functional development.
The integrated solution is merely a small-scale upgrade of the modular solution, reducing the number of single-function and redundant modules in the architecture, merging multiple functions into a single controller, such as BCM integrating PEPS, ESP integrating TPMS, etc. The greatest benefit it brings is cost savings, but it still cannot compensate for the low communication rates between modules.
2. Centralized Architecture Solutions
In the centralized architecture solution, the concept of ‘domain’ first appears. The biggest difference between ‘domain’ and ‘module integration’ is that module integration merely packages traditional modules together; its essence still relies on the original functional divisions, and the barriers between modules remain intact, with strong hardware bundling characteristics. For example, many BCMs on the market integrate PEPS functions, but if we need to integrate the PEPS system into the ESP controller, the original platform will not be compatible, requiring a large amount of work to develop a new platform.
The core idea of the ‘domain’ concept is flexibility, integrating systems and software layers while breaking free from hardware bundling constraints. Continuing from the previous example of the village blacksmith, how does ‘domain’ manifest in this context? First, the blacksmith still resides in Village A; his ‘craftsmanship’ remains a core secret, and Villages B and C remain unaware of how excellent weapons are produced. However, the communication barrier is broken by the high-bandwidth ‘Ethernet’. Even though Villages B and C do not have blacksmiths, they have internet connectivity! And they are within the ‘local area network’ signal range of Village A, allowing them to place orders via phone, text, or online shopping. For Village A, with the increase in consumers and order volume, the blacksmith’s social status quickly rises, becoming the landlord of the village, and he will have more motivation to research efficient blacksmithing.
In this upgraded example, several key terms emerge: ‘ABC villages’ correspond to ECU controllers, the ‘local area network between villages’ corresponds to in-vehicle Ethernet, FlexRay, or CAN-FD, and ‘network orders’ correspond to flexible Internet protocols (you may have already noticed that the consumers and providers in TCP/IP and SOME-IP protocols represent this concept). The ‘blacksmith’ in the example is the familiar domain controller, which is a comprehensive function provider with exclusive core algorithms. If the ‘Internet Gateway’ is the ‘village chief’ responsible for coordination and scheduling in the domain architecture, then the ‘domain controller’ is the gentleman who brings benefits to the villagers. In most domain architecture designs, what the domain controller can integrate and provide in terms of algorithms and functions to other small controllers and actuators determines the scope of the domain.
For a more practical example, the ‘Body Domain Controller (BDU)’ integrates all electronic functions of the body such as basic driving, key functions, lights, doors, windows, etc. Because the body domain controller can provide ‘body blacksmithing’ technologies, such as window pinch protection algorithms, voltage compensation, backup driving functions, small controllers can focus less on complex algorithms and more on hardware and driving. This not only significantly reduces the development volume of redundant software but also allows many controllers to be streamlined and optimized, such as traditional electric tailgate controllers, window pinch protection controllers, door controllers, etc. Small villagers no longer need to consider how to forge weapons; they start to focus more on how to cultivate martial arts. This efficient elite group forms a body domain composed of fewer units, lower costs, yet powerful functions. This standardized shared software resource architecture design concept has been fully applied not only in the body but also across various fields of the entire vehicle, becoming the well-known power domain, chassis domain, body domain, infotainment domain, and ADAS domain, etc. This is the centralized electronic and electrical architecture based on different ‘domains’.
3. Zone Architecture Solutions
As mentioned earlier, the concept of ‘domain’ is not unfamiliar to many OEMs and Tier 1 suppliers. You may also have realized that in fields such as the internet, aerospace, and shipping, ‘domain’ is not a new term. Since the centralized architecture concept of ‘domain’ is so perfect, why has it not been widely adopted in mid-range and low-end models in recent years?
The answer to this question is quite simple; the keyword is “cost”. Cutting-edge design concepts bring real contradictions. With the explosive growth of automotive electronics in recent years, the number of ECUs and the demand for their computational capabilities have surged, particularly evident in the ADAS era and the upcoming autonomous driving era, which also drives the demand for computational bandwidth. This has caused the cost of automotive electronic systems to skyrocket. In addition to the increase in the number of ECU systems, to align with the ‘functional domain’ concept based on module divisions, wiring harnesses, layout, installation, and brackets had to be redesigned, leading to astonishing mechanical structure costs.
Continuing with the example of the ‘body domain’, to establish this function-oriented electronic and electrical architecture, OEMs had to extend the wiring harness for the rear brake lights, rear position lights, tailgate locks, and even the double support rods across 80% of the white body to connect to the domain controller located at the front of the vehicle. While the electronic architecture becomes comfortable, the mechanical layout teams are left in despair. Similar issues arise in the front and rear radars of ADAS, the front and rear cooling systems of air conditioning, and the front and rear wheel steering control of chassis systems. The wiring harness system cost of a low-end vehicle is about $300, weighing about 30 kg, with a length of about 1500 meters, around 600 wires, and 1200 connection points; while a luxury vehicle’s wiring harness system costs about $550-650, weighing about 60 kg, with about 1500 wires, 5000 meters in length, and 3000 connection points. If the current electronic architecture system is maintained, the wiring harness cost for the autonomous driving era will not be less than $1000, with a weight of up to 100 kg. These astonishing figures are the reasons why most models hesitate to adopt ‘domain’ architecture.
Back to the point, to solve the high costs without losing the core concept of centralized software in ‘domain’, the leader in electric vehicles, TESLA, has redefined ‘domain’ in the Model 3. In this new concept, traditional domains such as body domain, power domain, etc., are replaced by physical spatial divisions called ‘zones’, such as central zone, left zone, and right zone.
You might say that the new domain is divided according to layout schemes, which seems a bit too ‘basic’. However, this is the core idea of zones. After so many changes in automotive electronics, it is finally beginning to move towards a simpler path. The new domain, mentioned today, is the ‘zone’ based on positional distribution that may be realized in the future. Through the interaction and integration between different zones, using the principle of proximity, it perfectly avoids the aforementioned issues but also brings epic challenges to software development. For example, body controller engineers may need to start studying radar drives and algorithms; functional safety ASIL-C and D level software development is gradually becoming standard. The control development of domains will no longer be limited to functions; hardware and software development will break traditional functional division barriers, requiring more holistic vehicle design thinking.
Conclusion
The electronic and electrical architecture based on ‘zone’ may seem simple, but it actually contains a lot of architectural knowledge. It breaks not only the barriers between functions but also the mental barriers of the entire vehicle architecture. More importantly, Tesla has already proven with their answer in Model 3 that advanced architecture and low costs can coexist. So, is ‘domain’ the end or the starting point of a new era? Are there better solutions for the entire vehicle electronic and electrical architecture?
In this context, United Electronics has set the development goals for the new generation of body domain controllers based on the existing development platform, actively adopting and introducing high-tech, continuously developing and expanding. The new generation of domain controllers will not only inherit the functions of traditional controllers but will also support more integrated special functions, achieving Ethernet and cloud information interconnection, creating a more reliable quality platform.
We welcome all angel round enterprises from the entire automotive industry chain (including the electrification industry chain) to join the group,Around enterprises (friendly connections include 700 automotive investment institutions, including top-tier organizations; a selection of quality projects will be presented to existing institutions by theme);We have communication groups for technology innovation company leaders, and dozens of groups covering the automotive industry, automotive semiconductors, key components, new energy vehicles, intelligent connected vehicles, aftermarket, automotive investment, autonomous driving, and vehicle networking, etc. Please scan the administrator’s WeChat to join the group (please indicate your company name).
