Advances in Automobile Engineering
Open Access

Organisational Implications of Shifts in In-Vehicle IT Architecture for Incumbent Car Manufacturers

Fabian Hoeft^{* *}Correspondence: Fabian Hoeft, Department of Automobile Engineering, University of York, Heslington, England, United Kingdom, Tel: 4915786143951, Email:

Author info »

Introduction

Developments in vehicle connectivity, autonomous driving, mobility sharing and drivetrain electrification challenge incumbent car manufacturers in various ways. One challenge is the hardware and software vehicle redesign to exploit the potential of all four trends. Particularly vehicle connectivity and autonomous driving require profound changes to the in-vehicle IT architecture.

To date, mass-market vehicles work with approximately 80 to 100 decentralised Electronic Control Units (ECUs) to control all electronic and mechatronic systems of the vehicle. These ECUs are being developed by 80 to 100 decentralised teams. Each team is accustomed to contributing to and being responsible for its specific hardware, mechanics, and software area. This organisational system works for the development of these ECUs because it is managed in a cascade waterfall fashion, centrally and top-down [1].

Description

ECU challenges of incumbent car manufacturers

Car manufacturers now shift from many decentralised to one or very few centralised ECUs. Main reasons include that centralised ECUs are required for the more demanding autonomous driving operations and over the air vehicle updates to deliver additional functionality for consumers continuously. Vehicle updates may include changes to the driving behaviour of the car, improved energy efficiency or further individualised entertainment services [2].

Incumbent car manufacturers find it challenging to transition to a centralised IT architecture for three main reasons. First, their current decentralised organisational structures, including roles, responsibilities, and processes, are not designed to develop centralised ECUs. Second, car manufacturers still lack skills and capabilities to heave the software from a decentralised in a centralised solution. The technical development includes a vehicle operating system and the software layer above it to enable the use of own and externally developed applications. Third, car manufacturers supplier relationships currently do not fit the centralised IT architecture. Suppliers are used to licensing software code or selling entire modules to car manufacturers. However, they are not providing access to their software code because it is an essential element of their unique value proposition. Car manufacturers are slowly dismantling the legacy supplier structures by trying to master ECU software; a challenge since it interferes with organisational structures and business models grown over decades [3].

Centralised ECUs of incumbent car manufacturers and new entrants

The idea of centralising ECUs was explored some years ago. Both new entrants, like Tesla, and incumbents, like Audi, recognised the potential of central ECUs. While Tesla developed its system fit for purpose from scratch, incumbents tried to transition from legacy systems. Audi was one of the pioneers at the time and introduced the “Central driver assistance controller” in the Audi A8. They aimed to bundle driver assistance systems in terms of IT architecture to improve system functionality and robustness. For safety reasons, they decided to separate safety relevant and non-safety relevant systems [4].

Volkswagen is a more recent example of a car manufacturer that tried to centralise ECUs further. In their first fully electric mass market electric vehicle, the ID.3, the manufacturer struggled with managing the new IT architecture, leading to delivery delays and thousands of vehicles with buggy software. Volkswagen has a hodgepodge of different and complex technological solutions in the ID.3 and had to cut back on basic functionality to ensure the operability of the vehicles. Tesla has a lead in in-vehicle IT architecture. They developed their vehicles using central ECUs from the early days and did not rely on suppliers, like Continental or Bosch. Tesla not only developed an IT architecture that best fits their vehicles, but they also developed the internal IT capabilities to evolve their systems further as new requirements emerge. Tesla’s IT architecture enabled over-the-air updates from early days and remains a competitive advantage.

Incumbent car manufacturers realised the necessity to move to centralised ECUs and increase the internal value added in terms of software. However, their IT architecture transition is a complex evolvement given the wide range of platforms, product lines, models and legacy software solutions. Although incumbents have, compared to Tesla, entirely different sales volumes to allocate fixed costs, they might lag behind in terms of IT architecture for at least some time [5].

Management of centralised in-vehicle IT architecture

Two concepts might support incumbent car manufacturers in particular, but new entrants alike, in managing the transition and/or complexity of centralised ECUs. First, car manufacturer’s organisational structures have to mirror or at least align with their product architecture. Although incumbent OEMs are centralising their in-vehicle IT architecture, they have not yet transitioned their organisational structure accordingly. Conway introduced the idea that organisations design systems that reflect their communication structures. This observation, later called Conway's law, implies that a decentralized. Organisational structure of 80 to 100 teams might not be ideal for developing centralised ECUs effectively and efficiently.

Second, IT architecture challenges may be approached best by adopting systems engineering, i.e. the early sitting down and thinking through systems, sub-systems and dependencies. Since cars are complex mechatronic systems, a systematic breaking down of components might create transparency and improve dependency management. The complexity of cars today is already so high that humans can no longer logically grasp it but rely on software tools in the development. If car manufacturers try to improve IT architecture without systems engineering, they risk embarking on a trial-and-error development process with an uncertain outcome.

Conclusion

Particularly to exploit the potential of advances in vehicle connectivity and autonomous driving, car manufacturers are adopting centralised in-vehicle IT architectures. New entrants, such as Tesla, developed centralised ECUs by adopting a greenfield approach from the beginning. Incumbent car manufacturers, however, are transitioning their legacy systems from decentralised in-vehicle ECUs to a centralised IT architecture logic. Incumbents encounter challenges in the form of mismatching organisational structures, talent gaps and unsuitable supplier relationships. Tesla might be leading the invehicle IT architecture domain for at least some time. Incumbents may catch up by mirroring product and organisational architecture, and by adopting a systems engineering approach to architecture development.

References

1. Audi. Audi A8-Central driver assistance controller. Audi Technology Portal, 2017.
2. Conway ME. How do committees invent. Datamation. 1968;14(4):28-31.

   [Google Scholar]

3. Volkswagen AG. VW vows to go it alone on software despite mishaps. Financial Times, 2020.
4. Llopis-Albert C, Rubio F, Valero F. Impact of digital transformation on the automotive industry. Technol Forecast Soc Change. 2021;162:120343.

   [Crossref] [Google Scholar] [PubMed]  

5. van Veldhoven Z, Vanthienen J. Digital transformation as an interaction-driven perspective between business, society, and technology. Electron Mark. 2022;32(2):629-644.

   [Crossref] [Google Scholar] [PubMed]