Software Defined Vehicles
Interview with Dr Moritz Neukirchner, Elektrobit
“We see a strong trend toward open-source solutions”
As budgets tighten across the automotive industry, reaching “SDV Level 5” requires smarter architectures, selective transformation, and collaboration. Dr Moritz Neukirchner of Elektrobit explains how this can be achieved.
Dr Moritz Neukirchner has spent more than a decade shaping the future of automotive software at Elektrobit, where he currently serves as Head of Architecture. Before joining Elektrobit, he worked as an engineer at IAV, combining deep technical expertise with strategic leadership in software and systems design.
At the Automotive Computing Conference 2025, Neukirchner will discuss what it truly takes to reach “SDV Level 5” in times of shrinking budgets – and how focused architectures, lean processes, and targeted collaboration can turn financial pressure into a driver of innovation. In the run-up to the conference, we spoke with him about how OEMs can advance software-defined maturity without losing efficiency or control.
ADT: Many OEMs talk about reaching “SDV Level 5”, but financial and organizational realities often slow progress. From your perspective, what are the most effective ways to advance SDV maturity under tight budgets?
Dr Neukirchner: Most importantly, it is essential to understand where the Software-Defined Vehicle creates value for the customer. What does the customer perceive as an SDV? Which features does the customer want to see delivered via software upgrades over the air? Are there specific domains where the customer expects the vehicle to improve with age rather than just get older? The next step for the OEM is to limit changes to architecture and processes to exactly those parts of the system that deliver this SDV value. For many OEMs, this will be mostly limited to the cockpit domain. For everything else, it is important to abstract any existing legacy architecture from this frequently changing component. Changes to the rest of the system – that is, the legacy E/E architecture – are only required to save costs, for example by transitioning to a zonal architecture. In this way, you can separate the “SDV value zone,” which differentiates the vehicle on the market, from the “SDV cost zone,” which implements architectural changes to save costs.
At the ACC 2025, you will outline strategies and architectures for efficient SDV development. What practical lessons has Elektrobit learned from working across different OEM ecosystems, and where do you see the biggest leverage for collaboration?
The biggest leverage is achieved by focusing on what customers really want and limiting the scope of changes to legacy architectures to those truly effective in realizing that change. We have seen several OEMs attempting to establish full upgradeability across all types of electronic control units. This required tremendous effort, had little effect on customer perception, and significantly increased project execution risk, as many parts of the overall system were changing concurrently. Another major cause of cost escalation was the handling of variants and versions. Being able to scale the cost of a platform across different vehicle price points and maintaining fewer versions of the same software platform significantly decreases the total cost of ownership. However, this is difficult to achieve when managers responsible for sourcing are in control of only one specific ECU for one specific vehicle generation – they simply cannot realize the cost benefits over time.
Given these cost and coordination challenges, how can OEMs and suppliers better align their strategies to balance individual control with the benefits of shared development?
Both points lead to the biggest opportunity for collaboration. Once the focus shifts from technology to customer benefit and from bill-of-material cost to total cost of ownership, it becomes relatively straightforward to decide where to collaborate and where to pursue exclusive control. This, however, differs between OEMs and their respective customer bases. The other aspect of collaboration is its form. Today, we see a strong trend toward open-source solutions rather than open standards or proprietary ones. The reason is the perceived greater freedom to influence development and maintain control over the supply chain. However, other forms of collaboration, such as proprietary partnerships, may deliver faster results. I believe that open-source solutions will become more common, but re-developing all available assets is neither cost-efficient nor faster.
Elektrobit is known for its deep expertise in automotive software platforms. How does your team balance innovation speed with safety, compliance, and long-term maintainability in such complex architectures?
The key is to manage versions and variants over time and to be able to replicate platform builds. You cannot treat software deliveries as one-offs when you build software products, as Elektrobit does. We have been delivering software products, including the required safety and compliance, to our customers for decades. A well-established software development and qualification setup is key to repetitive business across multiple customers. At the same time, small teams must be able to work independently on innovative features. This is characteristic of our deployment of cloud-based development tools. Utilizing small, agile “speedboats” to test new technologies quickly, in parallel with more stringent development practices, is absolutely essential to the concept of failing fast.
