Western OEMs and Tier-1s are Failing the SDV Test

Why does that matter?
What can we do about it?

The Future is Software Defined

The Software-Defined Vehicle (SDV) is not an optional future; it is a clear, present, and superior reality. Compared to the antiquated specialized Electronic Control Unit (ECU) architecture, SDVs offer dramatically more flexible designs. They can morph across multiple models, use simpler hardware, and leverage a much more capable central HPC (High Performance Compute). They allow vastly faster design cycles, with some Chinese SDVs approaching single-year cycles. They use Over-The-Air (OTA) software updates to deliver better experiences to customers and lower liability to OEMs. The business drivers are incredibly compelling.

Even companies that fail and then back off on SDV designs concede they are the future. The Western automotive industry is nonetheless frustratingly stuck dabbling with partial, weak, or even failed SDV designs. They back off because it’s hard, not because they believe in the supremacy of ECU designs. And that threatens the entire industry.

RTI has a unique perspective. There are today over 2 million cars running RTI software on the road. Almost all are EVs using SDV designs. We sell into all major automotive geographies. So, we have immense experience with OEMs and programs across the world, including Western and Chinese OEMs.

Our take? We see the EV-natives succeed over and over. And we watch traditional OEMs fail over and over. From all this, we have a simple message:

Wake up
Why are SDVs so hard?

There are many reasons the transition to a software-defined architecture is hard, but most explanations miss a core issue.

One common explanation is that SDVs are tightly coupled to EVs, and despite many advantages, EV adoption is poor. Electrified platforms do make it easier to rethink vehicle architecture – they remove legacy constraints and create an opportunity to redesign compute, networking, and packaging from first principles. In that sense, EV programs often become the natural starting point for SDV designs.

But this relationship is incidental, not causal.

The industry’s difficulty with SDVs is not fundamentally about electrification. It is not primarily about battery cost, charging infrastructure, or adoption curves. Those factors influence product timing and investment decisions. However, they do not explain why organizations set out to build SDVs, but then struggle to design, integrate, and deliver modern software-centric architectures.

Similarly, some claim that OEMs lack sufficient software talent or culture. There is some truth to that, and there have been visible failures. But most major OEMs now have large, well-funded software organizations staffed with capable engineers. There are holes in organization structures, but these slow, rather than prevent, delivery. Software capability alone does not explain the persistent difficulty in delivering cohesive SDV designs.

Cost is an issue; a fresh-design EV can cost three times the incremental gas vehicle alternative. But this too is a fleeting factor. EVs are much simpler designs, so long-term they have a fundamental advantage. Ignoring the long-term cost advantage of EVs for short-term cost saving is a classic primrose path for western OEMs. Falling behind an inevitable trend is a losing strategy. But the OEMs know that, which is why there are so many SDV programs. It doesn’t explain why they fail.

So what is actually going wrong?

An overlooked deeper issue is a breakdown of the supply-chain model. The industry is attempting to apply a hardware-supply model to a software-delivery problem.

The traditional automotive supply chain is an engineering marvel optimized entirely for mechanical components. OEMs specify subsystem functionality with sophisticated requirements for function, physical form factor, power use, and environmental factors. Crucially, the accompanying software interface specifications are deliberately simple – often just a few bits on a CANbus or its logical equivalent. This model makes it easy to get multiple suppliers (Tier-1s) to bid on and produce parts based on a simple, commoditized interface. The result, as everyone knows, is that modern cars have 100m lines of code, almost none of it written by the OEM. All that code comes embedded inside supplied parts. Usually, they are so deeply embedded that updates require service or a recall.

I once asked a Tier-1 VP what their software strategy was. The answer: “We put it into hardware." This sounds funny, but it’s all too true. There is essentially no software supply chain. Without a software supply chain, most EV-native OEMs vertically integrate, largely cutting out the Tier-1s. So SDVs are hard for traditional OEMs because they can’t use their suppliers. Vertical integration isn’t an option for most Western OEMs, so this blocks progress. It also means that SDVs are an existential threat to Tier-1s.

The non-existent software supply chain is an insurmountable barrier that we nonetheless must surmount

Why is automotive software so hard to supply?

Of course, building a software supply chain is not just technical, it is also a business problem. OEMs and Tier-1s need to move beyond real-time operating systems (RTOS) and develop better partnerships with the many embedded software vendors with footprints in other industries, ranging from narrow components like battery management to system-wide data infrastructure. And we need to work together on a new business model for software supply. But there’s also a technical blocker: interface complexity.

Software interfaces are vastly more complex than hardware interfaces. Software that must run in the physical world is even harder to specify. For example, an ECU interface specification for a smart cruise controller setting over CANbus is pretty simple. But that doesn’t work as software gets sophisticated; specing a full video feed or a LIDAR cloud scan stream for an intelligent ADAS is a very different proposition. Software data structures can be megabytes and require strict delivery control. None of the hardware-oriented interface approaches can enable a software supply for physical systems.

Bottom line, a usable physical software interface communication system must specify What, When, and Who:

• What is content
• When is timing, reliability, and other delivery-control parameters
• Who is finding the right devices and systems to share with

Most software specifies only the what. Databases, programming languages, cloud APIs all simply share data in a known schema. That works in enterprise software. But “what” is not enough in the physical world. For instance, a feedback loop may require sensor updates 100 times a second to work; what’s in that sensor data is still important, but when that data is shared also matters. Finally, there’s far too much data in the real world to send everything to everyone. Who you share with is often important.

Without a robust interface definition of all three – What, When, and Who – you simply cannot have a functioning software supply chain for automotive systems.

Now, the astute observer may note that I’m the CEO of a company with software based on the DDS^® (Data Distribution Service) standard. DDS coincidentally supports all three: what (topics with data schemas across language types), when (quality of service parameters), and who (discovery, partitions, join/leave). Most advanced SDV designs use DDS. There are other approaches, of course. But in any case, SDVs must have some way to specify these interfaces. It’s a critical secret sauce.

All that said, misunderstanding the complexity of physical software interfaces limits the automotive industry. RTI also sells into many other industries, ranging from medical robotics to defense. These industries are well-practiced in distributed, complex software written by many companies. And in many areas, the DDS standard is the dominant approach. So, perhaps arrogantly, we think this is the Achilles’ heel of the Western automotive industry:

The industry critically needs a better software-specification approach

What can we do about it?

SDV OEMs have only two choices: a) vertically integrate and thereby control the interfaces, or b) enable a software supply chain through clear interfaces. For most traditional OEMs, vertical integration requires fundamental restructuring; it simply isn’t practical near term. That makes enabling a software supply chain critical.

For Tier-1s, this is a moment of existential crisis. Tier-1s are strategically lost if they cling to the broken model of smart ECUs with simple hardware-spec interfaces. The future is one where the bulk of the intelligence and value moves off the physical part and into the central compute unit. OEMs will own that central HPC, and Tier-1s need to adapt to that reality.

To be clear, imho, the actionable strategy for Tier-1s is to stop selling “smart parts” and start selling parts coupled with software. Realize that your part’s software may not run in an ECU at all, but instead run in a central HPC that you didn’t supply.

Likewise, traditional OEMs need to develop a clear software-supply-chain process. The actionable strategy for OEMs is to publish software stack specifications on the central HPC. And to enable a software opportunity for suppliers, both Tier-1s and vendors, by adopting proven “what, when, who” interface standards with data models and QoS specs for every part.

Together, OEMs and their suppliers must build the software supply chain. Realistically, this is a huge transition. The cost and pain of a new architecture is a huge barrier for incremental gas-engine designs. It is more easily justified along with truly new electrified designs. But software is increasingly important; if you can’t integrate complex software, you will lose against competitors who can, notably China.

Make no mistake. As an industry, Western OEMs face many disruptions and challenges: autonomy, electrification, and low-cost Chinese competition to name a few. But the transition to SDVs underlies all of these. This is a test, and the traditional OEMs are failing.

We need to wake up and pass the SDV test

About the author: 

Stan is CEO of Real-Time Innovations (RTI), the data streaming company for intelligent distributed systems. RTI’s Connext software is the critical nervous system for over 2,000 designs across Aerospace and Defense, MedTech, Automotive, and Robotics. RTI Runs a Smarter World^™.

Stan has a PhD in EE/CS from Stanford with a focus in autonomous systems.