E/E architecture evolution, part 2, trends to watch
Continuing from previous blogs on this topic I thought I’d cover the trends seen today, consolidating functions, centralizing into fewer ECU’s each with more processing power, and the move to zonal architectures that are emerging with some OEM’s.
Functional consolidation
OEM’s have been trying to consolidate functions into fewer ECU’s for some time, as I mentioned previously, it’s easy to add an ECU per feature added to the vehicle, even if existing functions are being re-used to support the new feature, so the ECU count can rise rapidly. The move towards consolidation within each functional domain into respective domain controllers is sometimes referred to as centralization, and the tooling and process changes needed to develop domains this way can be similar. Developing each ECU as an individual component becomes very complex and inefficient, with system level changes taking time to cascade to each supplier for reintegration, system level design and development is vital to ease this.
Zonal architectures
Connecting domain controller ECU’s via a back bone, likely automotive ethernet, with each domain having it’s own network(s), leads to many overlapping routings round the vehicle. Multiple networks have been useful to suit different data types, with the mix across the vehicle including a mix of media streams, status information with deadlines, and high integrity data needing functional safety and/or cyber security protections. Automotive Ethernet, or specifically the additions to it, such as TSN (Time Sensitive Networking) and VLANs (Virtual Local Area Networks) allow multiple data types to travel across the same physical network, segregated to ensure each data type can be prioritized and handled appropriately.
I’ll come back to the technology next time, but this ability to share a high bandwidth network between multiple data types allows a reduction in the number of networks, and this reduction can save mass and cost in the vehicle harness.
Centralization
There is also centralization here, in fact, when OEM’s refer to Centralization rather than consolidation, often they are referring to powerful central compute units within a zonal architecture. It’s worth noting however, depending on approach, the functionality that can be consolidated here, rather than in zonal controllers, or further out varies. Moving functions away from sensors and actuators can add latency through each network, more so if there are Com stacks needing to gateway or forward data between networks, compared to switching data through a switch.
Low level control loops might still be best near the actuator, with the higher level control decisions centralized, leading to sensors and actuators being more traditional, more deterministic, embedded controllers, and central ECU’s having a mix of controllers and more performant processing, increasingly with heterogenous silicon and software.
Service Oriented Architecture (SOA)
Over recent years many in the Automotive industry have been exploring SOA as a method to utilize zonal and centralized E/E architectures to increase scalability, adaptability and updatability over the life cycle of the E/E architecture, but also of the vehicles. There has been investigations into pure SOA, or using a partial SOA with constraints to ensure that implementations are validated in development and deployed consistently. With careful system design it may be possible to mitigate many of the risks that a pure active SOA might pose to a safe and secure, highly reliable system, such as in Automotive, but this requires further substantial change to the way vehicles are designed and validated.
To take a step back, how is an SOA different to traditional vehicle architectures, at the basic level there is a move from Signals to Services. Traditional automotive E/E architectures have been organized around functions and their requirements of the signals they need to subscribe to, and abilities to publish signals for other functions. Each function has a static allocation to an ECU, each signal to a network, resulting in static network designs requiring care to update and change, and the new network design needs to be re-integrated into all, affected, ECU’s.
Whilst an partial SOA based E/E architecture for Automotive might be implemented to be frozen, or frozen between updates. A pure SOA relies on discrete services which declare their availability, and so consumers can select an appropriate service to obtain the needed inputs, and dynamically adapt to availability, utilizing Ethernets ability to actively route and manage data flows. The active nature of SOA, combined with the hard realtime requirements of Automotive control functions is where the complication comes to this approach, making it an active area of research.
E/E Architectures in the real world
For most OEM’s big bang changes are a rare and risky occurrence, and most steps, even towards large changes, come more iteratively. In some cases OEM’s can centralize some functions, and keep functional consolidation for others, in other cases there maybe a move to zones, but keeping much computing in the zonal controllers or function ECU’s. Considerations maybe supply chain, development capability, or more technical, such as the latency requirements from sensor, via processing to actuator.
In many cases the real E/E architectures can end up as much more of a hybrid, with functions involving large amounts of data, such as media streams in Infotainment, and high integrity, low latency data such as ADAS (Automated Driver Assistance Systems), being kept Functionally oriented. This reduces the demanding data flows across the full E/E architecture, leaving less demanding functions to exploit Zonal orientation, and reduce the wiring harness somewhat. E/E architectures which utilize mixed network technologies commonly have processing load and latency added translating data between network technologies, which can be largely mitigated with switched all ethernet networks.
Summary
The automotive industry discusses and is on a trajectory towards centralized, zonal E/E architectures, indeed some OEM’s have achieved some versions of these, many however are somewhere in the transition, often with a roadmap over a few generations of E/E architecture. There are benefits, in terms of reduced cost and mass or wiring harness and ECU count, centralization allows expansion headroom to be concentrated in relatively few ECU’s, enabling many sensor and actuator ECU’s to be cost optimized more traditionally. SOAs enable a further optimization of this layout, but with another change in the way software is developed and deployed, leading to the trend towards software factories (blog) which I’ve discussed before (on demand webinar).
More on this topic to come soon, next I’ll cover enabling technologies… but if you want to learn more now, the following reading and watching are a good place to start.
