- Semiconductor BusinessHOME
- Products and Services of Macnica,Inc.
-
technical information
-
Events and Seminars
- Handling Manufacturer
- Support
- Inquiry
- Click here to purchase products
- Semiconductor business e-mail magazine registration
Narrow down by specifying conditions
現在2149件がヒットしています。check
Automotive E/E architecture is evolving from a distributed model to a domain model and then to a zone model. This article explains the basic structure of zone architecture and how it differs from conventional methods in an easy-to-understand manner, even for beginners, and also introduces the design concepts required in the SDV era.
Introduction | How have electronic systems in cars changed over time?
In recent years, cars have evolved from "driving machines" to "driving computers."
These advances are supported by the vehicle's internal electronic and electrical systems, known as the Electrical/Electronic Architecture (E/E architecture). However, this E/E architecture is currently at a major turning point. To understand why, let's first look at the evolutionary history of the architecture to date.
Differences between distributed, domain, and zone architectures
To date, automotive E/E architecture has evolved in three major stages, but it will not suddenly shift to a zone-based architecture one day. It has evolved in stages while addressing the technological challenges and increasing sophistication of vehicle functions, and with the emergence of vehicle manufacturers that are concretely realizing mass production of SDVs, the shift to a zone-based architecture is finally in sight. To understand this trend, let's first look at the differences between "distributed," "domain," and "zone-based" architectures, and the benefits and challenges of each.
|
Distributed ArchitectureKucha ECUs are arranged for each function |
DomesticIn-type architecture Similar functions are controlled by one ECU |
Zoned Architecture Divide into physical zones and control them collectively |
|
|
example |
・Power window ECU ・Engine control ECU ➣ 1 function = 1 ECU concept |
・Powertrain domain Body domain ・ ADAS domain |
・Front / Back ・Right side / Left side ➣ Physical area (zone) concept |
|
merit |
・Each function can be developed independently ・ Defects are less likely to spread to others |
・The number of ECUs can be reduced to some extent - Integration of control |
- Lightweight due to reduced wiring ・More efficient software management |
|
Task |
・The number of ECUs tends to increase ・Complex wiring - Increased vehicle weight |
- Still a "function-centric" design - Increasing complexity of inter-domain collaboration ・ Difficulty of software integration |
Dependence on a central computer - Enhanced security design -Increasing difficulty of power supply and thermal design |
image
Distributed Architecture
Domain-based architecture
Zoned Architecture
Comparison Summary
| item | decentralized | Domain Type | Zone type |
| design criteria | Functional Unit | Functional Group | Physical Area |
| Number of ECUs | many | Slight reduction | Further reductions possible |
| wiring | complexity | improvement | Significant reduction possible |
| Software Management | dispersion | Domain-based | centralization |
When comparing the distributed, domain, and zone types, we can see that automotive E/E architecture has evolved from a "function-centric" architecture to an "integrated/concentrated" architecture.
・ Distributed: Simple structure with each function being independent
Domain type: A structure that groups functions and promotes integration
Zone type: A configuration redesigned based on physical layout
In other words, the direction of evolution has consistently been "how to organize increasingly complex vehicles," but what is unique about zone architecture is that it has significantly shifted the way of organizing from "function" to "physical area." So, what impact will this shift in design philosophy have on vehicle development? In the next chapter, we will look at the background to the attention that zone architecture is receiving.
Why is zone architecture attracting attention?
First of all, why did the Zone Architecture method come about? The idea behind it is the concept of SDV (Software Defined Vehicle).
An SDV is a vehicle whose functions are defined by software and evolve through updates. Taking a smartphone as an example, as long as the hardware functions are in place, the latest applications and operating system (OS) can be downloaded and updated to keep the smartphone up to date with its functions, even if it is an older model. Vehicles are like smartphones; they can be updated to the latest functions and bugs can be fixed over the network, allowing for the addition and updating of functions for safety, comfort, entertainment, and more. As a result, vehicles are evolving beyond mere means of transportation, and their design philosophy is shifting from hardware-centric to software-centric design.
Furthermore, SDVs are premised on frequent software updates, flexible function additions, and centralized use of vehicle data, but conventional distributed and domain architectures have faced challenges such as the large number of software updates required, the need to manage each ECU individually, and decentralized security measures. Zone architecture addresses this by centrally aggregating data, simplifying wiring and enabling centralized software management, which has led to increased compatibility with SDVs, including security measures, and is gaining attention in recent years.
Zone architecture configuration and issues
Zone architecture places a zone controller (ECU) in each area of the vehicle and connects them to a high-performance computer in the central area. Although there are benefits such as weight reduction due to reduced wiring and more efficient software management, there are also practical challenges as the design concept changes significantly. Here we will briefly introduce the challenges and how Macnica can help with them.
Centralization leads to single point of failure risk
In a zone architecture, many functions are concentrated in a central high-performance computing (HPC). As a result, issues arise such as the possibility that a single ECU failure may affect the entire vehicle, the complexity of fail-safe design, and the rise in ASIL requirement levels.
・ ASIL-D compatible microcontroller
Lockstep configuration
・Redundant network design
・Safety monitoring function
Automotive microcontrollers with high safety performance such as the above are important.
The AURIX™ series of automotive microcontrollers from Infineon, available at Macnica, are equipped with multi-cores (lockstep cores), hardware safety mechanisms, and built-in HSMs, making them highly functional microcontrollers suitable for zone controllers and safety control applications, so be sure to check them out.
Increasing difficulty in network design due to the shift to in-vehicle Ethernet
The zone architecture transitions from a CAN-centric configuration to an automotive Ethernet-centric backbone configuration. This brings with it challenges such as communication bandwidth design, ensuring real-time performance (TSN), network redundancy design, and EMI/EMC countermeasures. While Ethernet is fast, it is also a "difficult" infrastructure to design. Infineon acquired the automotive Ethernet business from Marvell Technology in 2025, and its lineup of automotive Ethernet switches and PHYs will contribute to the construction of a high-speed, highly reliable communications infrastructure in a zone configuration.
Centralization of security risks
As networks become more centralized and Ethernet-based, the risk of cyber attacks also increases. The main risks include intrusion via OTA*, eavesdropping and tampering with backbone communications, and the increasing complexity of key management. Zone architecture requires a security design that takes the entire network into account. Technically,
Secure Boot
・Key management infrastructure
・Communication encryption
・Vulnerability management
It is necessary to consider cybersecurity measures such as these, and ETAS, which is handled by Macnica, can help with cybersecurity challenges using a variety of approaches.
*OTA (Over-the-Air): A technology for updating software on smartphones, in-vehicle systems, and IoT devices via wireless communication.
Summary: E/E architecture is still evolving
From distributed to domain and then zone architectures, automotive E/E architectures have evolved in line with the increasing sophistication of vehicle functions. Looking at this evolutionary trend, one consistent issue is how to organize and integrate ever-increasing functions and complexity.
The distributed architecture emphasizes the independence of each function, the domain architecture groups functions and promotes integration, and the zone architecture redesigns the structure itself based on physical placement.However, the zone architecture is not a "final form."
- Enhanced safety design through centralization
・Network design based on in-vehicle Ethernet
・ Strengthening cybersecurity response
- Responding to software scale expansion
At the same time, new challenges such as the following are also emerging. In other words, E/E architecture is currently in a state of "evolution."
Going forward, rather than thinking about hardware design, software design, and security design separately, it will become more important to optimize the entire vehicle as a single system, and zone architecture is just the first step.
In the next article,
・The role of in-vehicle Ethernet
・Specific image of security design
- Relationship with safety design (ASIL)
I would like to delve deeper into this issue from this perspective!
Inquiry / Quotation
If you have any questions or would like a quote regarding this article, please contact us using the form below.