As Software Defined Vehicles move from concept to industrial reality, ECU development has become a critical bottleneck. Increasing software complexity, cross-domain dependencies and fragmented toolchains often slow down what SDV strategies promise to accelerate.
Jan Rüdiger, Director Business Solutions Architect at Elektrobit Automotive Americas, has spent more than 17 years shaping embedded automotive software solutions. At Automotive Computing Conference US 2026 in Detroit, he presented Right-sized SDV Workflow for Efficient ECU Development, focusing on how integration-as-code concepts can streamline development and reduce friction across the lifecycle. After of the event, we had the opportunity to speak with him.
ADT: Where do you currently see the biggest gaps between SDV ambitions and real-world implementation?
The biggest challenges arise from platform heterogeneity. Each platform has its own mix of ECUs, SoCs, sensors, data signals, and message definitions. An AI model that runs cleanly on one vehicle may be non-deployable on another because the target ECU lacks compute headroom, cannot access the required data inputs, or uses different message naming. Even when the logic is portable, AI models often require calibration for different vehicles and may require engineering work to reconfigure for different message naming, signal parameters, or timing.
This fragmentation turns every deployment into a bespoke integration effort rather than a scalable capability. One comment I hear repeated far too often is some version of, “The vision was right, but the execution was painfully wrong.” To keep pace with the explosion of software in modern vehicles, OEMs now face the pressure to move as quickly as digitally native companies. This means software and hardware can no longer be separate tracks; they must be built side by side.
The biggest gaps are not rooted in the available technology. All that is mostly there. Rather, the biggest gap is in the way SDV projects are planned and executed. As it stands today, technology far too often still dominates the SDV discussion, while building up the right SDV capabilities remains treated as an afterthought. Team structures and project setup need to reflect the true complexity and scale of an SDV project.
Today, we still see SDV projects being started in isolated groups, or a department trying to conquer SDV without rethinking its supply chain. The automotive supply chain needs to transform into a co-development ecosystem in order to become more resilient and agile in response to these disruptions and challenges. Without a unified platform bringing hardware and software together, each drifts into its own development cycle, and real software reuse simply will not happen. And when reuse breaks, so does the ability to move new features across vehicles or keep existing ones updated with any kind of speed or consistency. The simple result is that costs will continue to increase while the benefit for the customer and the OEM stagnates or even decreases.
As E/E architectures become more centralized, how do software platforms need to evolve to remain flexible across vehicle lines and generations?
Universally, the promise of SDVs is to deliver exceptional customer experience over the complete lifetime of the vehicle. A next-generation E/E architecture is essential for any real transition to SDV because, without it, system complexity keeps rising while flexibility keeps shrinking, often made worse by avoidable vendor lock-in.
The truth is that the E/E architecture and software platform deployed by an individual OEM will make or break its success. Software platforms need to challenge complexity from day one. Not only must we be able to easily add new features over the complete lifetime of the vehicle, we also need to ensure existing features remain functional and well tested.
This will only be possible if the software platform remains open, using open standards and open-source software. Personally, I do not consider this an evolution. The automotive industry has always been strong in using open standards to accelerate development and decrease costs. I see this as a way to reinforce that approach by continuing to rely on open standards and bringing in open source wherever it makes sense.
This will not only cover the technical aspect of remaining flexible but also ensure the talent needed for future success remains available. Additionally, it will enable collaboration among large, global development teams. While this is true for software platforms, hardware platforms will need to follow the same path. Success will hinge on how well an OEM can navigate current and future customer expectations, which will ultimately show up in software and electronics across three dimensions: strategy and technology, processes, and organization.
What role do middleware and abstraction layers play in managing long-term platform complexity?
Both open-standard-based middleware and a well-defined abstraction layer form the foundation of SDV. Without these, the ability to meaningfully reuse anything is close to zero. The emphasis here is certainly on open standards. This enables independent development, testing, and updates of the basic software, middleware, and application. This not only significantly reduces complexity but also reduces costs and future-proofs the system.
It will also enable easy collaboration among different parties involved. Meanwhile, methodologies like virtualization, widely accepted as a mandatory cornerstone during system development, will only work when the respective next layer is sufficiently and openly defined. Vertical integrations based on closed-source software and single-source platforms might look like an easy fast-path solution at first, but will turn out to be a nightmare to maintain throughout the lifecycle of the vehicle and especially across different car platforms.
In a nutshell, enabling innovation through open collaboration, open standards, and open source is essential for reducing complexity now and in the future. OEMs can make real progress by sharing parts of their work within shared collaboration environments or, even better, contributing openly through organizations like Eclipse SDV. This kind of openness creates common building blocks, reduces duplicated effort, and accelerates what the entire industry can achieve together.
From your experience, which architectural decisions made early in development are hardest to correct later on?
One thing that is very hard to correct later is choosing the wrong hardware platform. Even in a software-defined vehicle, the hardware must be capable of supporting not only today’s features, but the future ones customers will expect. This must be anticipated by choosing hardware that is performant enough from the start, and by abstracting that hardware through the open standards and open-source approaches discussed earlier.
Not immediately architecture-related, but still close to this topic, is the decision for the right CI/CD/CT system, combined with a solid integration and testing concept. Only once this is in place from the start can changes be implemented easily throughout the lifetime of the vehicle platform.
Architecturally speaking, two more items are of great importance: separation, isolation, and the safety concept, as well as open standards and open source. Separating the different elements by using a hypervisor will not only greatly simplify the safety analysis and argumentation, but will also enable individual updates of the different elements.
For safety-related systems, a safety concept that enables strict separation of safety-related and QM elements is key. Containerization will ensure an easy update path for existing and future features. Basing the system on open standards and open source will lead to immense relief in workload and costs in the future. In summary, the architecture, hardware or software, is something you pay forward and needs to be understood as an investment in the future.
Which layers of the automotive software stack should be standardized, and where must OEMs retain direct control?
Putting it plainly, anything that is not immediately customer-facing should be standardized. Standardized here does not always need to mean a formal standard in its exact definition, but can also refer to participation in organizations like the Eclipse Foundation, COVESA, and others.
My hope is that OEMs will be bolder in benefitting from open source and communalizing the parts of their SDV software stack that customers never directly experience but that remain essential to the architecture. Retaining control over those elements might sound like a strategic advantage in the beginning, but their maintenance will ultimately only increase development costs.
Where do software platform ambitions most often break down in real-world implementation?
Initially, SDV was introduced as a monetization story centered around subscription revenue, recurring digital services, and mobile phones on wheels. Consumers continue expecting more digital features, autonomy, AI helpers, meaningful OTA updates, and in-vehicle productivity. However, willingness to pay subscription fees remains limited. The question we need to answer is how to deliver exponentially more software capability without exponentially increasing cost.
This is where most real-world implementations fail to deliver answers. To best understand the possible answer, we must look at the SDV Levels Framework defined by my colleague Dr. Moritz Neukirchner. Most cars today are stuck somewhere between Level 2 and Level 3, with only some venturing into Level 4. With this, they never reach the inflection point where SDV truly makes sense from a customer perspective.
Only at Level 5 do technology and maturity finally converge to create a real breakthrough in user experience. For that to happen, OEMs will need a partnership-based development model that maximizes value for both the manufacturer and the customer. This is where the aforementioned revenue model at least has a chance to peak. OEMs need to get past Level 3 to provide the functionality and experience users are expecting from their new vehicles.
Partnerships are becoming essential across the automotive computing stack. Which type of partnerships will matter most in the next three years, strategic, technological, or regulatory, and what should OEMs prioritize first?
Given the immense pressure the automotive industry is experiencing right now, movement must be deliberate and fast. Regulatory partnerships matter, but they will only move at the required speed if OEMs also rely heavily on strategic and technological partnerships. Establishing partnership-based development to reach SDV Level 5 will enable them to maximize value realization for their customers and therefore for themselves.
The automotive industry and its supply chain are under immense pressure. Ranging from changing consumer expectations to software-first approaches and software-first architectures, price competition and the focus on a manageable total cost of ownership are still rising. And above all, the costs of development continue to increase. The good news is that all the elements required to solve this are available; they just need to be applied.
