In-vehicle Networking Technology Are we ready for the future?

Example schematic of ECU placement. Every color represents a different combination of IVN-technologies in one ECU.

The hard currency of a car manufacturer are manufacturing costs, labor and components. Opportunity costs or cost caused by development effort, complexity of the E/E-architecture or alike are more difficult to access and thus less likely to be considered.

The in-vehicle network is one of those typical elements that is assessed mainly by its hardware costs, but neither by the complexity it imposes on the E/E-architecture nor by its enabling capacity to fundamentally impact how we develop cars and what type of functions we can sell. This article discusses the impact the choice of IVN-technologies has on the E/E-architecture and system costs.

Figure 1 shows a typical example of the Electronic Control Unit (ECU) and sensor placement as well as the communication connections for a realistic high-end car. In the figure, 101 ECUS are color coded. Each color represents one of 26 different combinations of networking connections that occur in this example (seven communication technologies considered). 30% of the ECUS have more than one network interface. The example contains 80 networks and easily 1km of communication cables. Even though this represents neither all units in the car nor all networking technologies used – additionally, various sensor-like units are “privately connected” and not incorporated in the figure – a single look at the picture is sufficient to grasp the complexity car manufacturers are facing with this traditional ECU- and signal-based architecture approach.

It works, no doubt! Cars with that architecture are safely cruising the streets today. Years of experience made car manufacturers grow with the requirements. This also applies to the in-vehicle network. It started with isolated communication needs for specific applications, especially diagnosis. Then new communication technologies were introduced based on requirements from the use cases. With growing needs, gateways were implemented between individual networks to allow for larger scale communication between ECUs, resulting in the domain-centric set-up we have today. But how well suited is this organically grown network to meet the requirements of the digitized future? How fast can such a system adapt, change, be improved or repaired? How fast does such a system allow for the introduction of new features and functions for the customer? How well does it integrate in a network that goes way beyond the physical body of a car?

More than just incremental improvements:

Naturally, car manufacturers are conscious of today’s E/E-architecture complexity. However, the discussions of possible improvements generally focus on the manufacturers’ hard currency: hardware costs. This often leads to incremental improvements that continue to treat the E/E-architecture as ECUs with communication technology between them. A real change requires a holistic approach. Figure 2 presents an example of an E/E-architecture that followed different design criteria.