With the continual growth in complexity of the Electrical / Electronic (E/E) systems in today’s vehicles, you will continue to see growth in the costs of design, support and manufacturing which can be solved by looking at a path transitioning to a Zonal E/E Architecture. Such a move does not need to be “an overnight revolution”, but can be evolved over time as new models and features are added to a brand’s range of vehicle models and as new market trends emerge.
The below blog and illustrations present a logical representation of the E/E Network inside the car and do not represent the physical layout.
Figure 1: The evolutionary transition path into Zonal E/E Architecture
The most common current architecture used in vehicles is often referred to as ‘Central Gateway Architecture’ as seen in figure 2:
Figure 2: Central Gateway Architecture - logical layout
In this architecture it is often the case that one gateway device connects to many sub networks, and each function requires its own processors. This results in over 150lbs of copper to connect everything together. In figure 3 below you can see a typical wiring harness that is required to connect all the ECUs and sensors.
Figure 3: Typical wire harness - Credit: link.springer.com
The motivation to transition into a Zonal E/E Architecture is driven by its clear benefits in hardware consolidation, modularity and re-use of hardware and software, simplification of software and hardware maintenance, certification and lowering overall costs.
In an evolutionary transition to Zonal E/E Architecture, each stage will bring immediate benefits in terms of cost reduction and product differentiation.
The first stage may be a simple inclusion of a few domain controllers and a central gateway domain controller to do the heavy lifting of vehicle control. The domain controllers will manage the various domain subnetwork and consolidate the functions of some of the ECUs, contributing to consolidation and simplification as seen in figure 4.
Figure 4: Domain Controller Architecture - logical layout
In the next step of evolution, a vehicle server will be placed to accommodate more sophisticated computing central functions, as seen in figure 5 below. The vehicle server will be a multi-role computer, effectively blurring the domains by breaking them down further into individual software modules. Over time, more of the functions can be moved from the domain controllers to the Vehicle Server further reducing physical hardware and wiring while allowing an increase in functionality. The choice of whether a function is controlled from a domain controller or central server will be influenced by the development lifecycle of the vehicle’s E/E platform and may follow different evolutionary paths. To learn more - watch our webinar on the transition to Zonal E/E Architecture.
Figure 5: Zonal Architecture - distributed - logical layout
Once a function is controlled by the Vehicle Server, it can then be easily ported to other vehicles within the brand or associated brands, as they are just software packages, and to the next model in development thus reducing development time while improving reliability and quality. Adding software based features to a model of vehicle, to create model differentiation is no longer going to be a major redevelopment exercise, but a simple software switch in a common E/E design; while adding functionality will be more easily achieved through firmware upgrades, even post production.
In the next stage of a Zonal E/E Architecture, brands may go as far as consolidating all of their software into one central vehicle server as shown in figure 6.
Figure 6: Zonal Architecture - consolidated - logical layout
In this consolidated stage, a vehicle server, or multiple vehicle servers, will host the software for all of the functions of the vehicle, and will connect to a few ECUs that will function as zonal gateways, located physically in various zones within the vehicle as shown in figure 7. The gateways may be connected in a ring or star architecture depending on the requirements for resilience and redundancy. This will significantly reduce the cost of development, hardware and wiring; while improving diagnostic and maintenance time and cost.
Figure 7: Zonal Architecture - consolidated - topology layout
This ‘consolidated zonal architecture’ is more futuristic than practical at present, however, the groundwork will already be there to achieve it as hardware dependency will be gone. GuardKnox has been working with major OEM brands and providing them with evolutionary steps towards this visionary goal.
Regardless of the evolutionary path that an OEM decides upon, each step of that evolution will provide benefits in terms of portability of function, reduction in future model development; reduction in weight due to reduced wiring and customer satisfaction through increased functionality at the controls of the driver.
Don’t forget to share this post
