Your Vehicle Keeps Evolving. Does Your Understanding Keep Up?

Your next software release is ready. The features work, the regression suite is green, and every team has signed off. So here is the question nobody puts on the release checklist: is the complete vehicle more stable than it was before this release, or less?

A green release checklist doesn’t answer it. Each team can show that its component meets its requirements. The release process can show that every change was reviewed. Neither shows how the integrated system behaves after days of operation, thousands of interactions, and dozens of small changes landing in components that were never run together for that long.

This is the paradox at the heart of the software-defined vehicle. Faster release cycles, more independently updatable components, features delivered after the car has left the factory: each makes that question harder to answer. Delivery capability is scaling. The ability to understand what delivery does to the vehicle does not scale with it automatically.

A background service leaks a little memory every time it reconnects. It keeps working, and every functional test passes. Hours later, memory pressure forces the system to kill an unrelated application, such as the navigation or the media player. The bug goes to the team that owns the application that died. That team was never the cause. Their application was the casualty.

It’s a simplified version of a pattern we see repeatedly in integrated systems: symptom and cause separated by process boundaries, software layers, team boundaries and hours of runtime. Functional test automation was built to verify that software does what it should. That is essential, and it is a different job from establishing whether a system is degrading over time. A memory graph tells you something is getting worse. It doesn’t tell you which process, which interaction, or why the application that crashed wasn’t the one that leaked. Meanwhile, the wrong team spends weeks investigating the wrong component.

Long-term stability is not a new concern. What is new is how fast the thing under test keeps changing. Automotive is rightly proud of its test fleets. But a fleet that accumulates millions of kilometers while new builds are flashed every week has tested a lot of driving and very little aging. The fleet has been running for six months, yet no individual build has run for more than seven consecutive days. Slow degradation such as leaks, growing queues and accumulating state never gets the time it needs to surface. Parking overnight doesn’t necessarily reset the clock either, because many modern infotainment systems spend far more time suspended than truly shut down.

After start of production, the problem changes shape. Owners postpone updates, decline them, or park out of coverage. Downloads get interrupted. Within a year, the manufacturer is no longer responsible for one evolving software system but for an expanding population of software configurations, each with its own update history and its own behavior.

Nobody can run an endurance campaign on every one of them, and nobody should try. Fleet telemetry is indispensable here: it shows real-world behavior, which configurations are affected and where things are starting to drift, and it often provides the first clues to the cause. What it cannot do is run a controlled, repeatable experiment on a build before customers receive it. So the useful question is not fleet data versus the lab. It is whether the two are connected: does field evidence decide which configurations get aged and analyzed, and does that analysis finish in time to change the next release?

For some manufacturers, the investigation can’t even start. They are effectively held hostage by their Tier 1 suppliers. The OEM carries the responsibility for the vehicle, the warranty cost and the customer’s patience. The supplier holds the debug interfaces, the system logs, and the authority to say what they mean. An engineering investigation turns into a chain of support tickets, change requests, commercial negotiations and arguments about whose component is to blame, while the vehicle still has the problem. The OEM owns the problem; the supplier controls the evidence. For a company that calls its product software-defined, that is an awkward position, and for many OEMs it is today’s reality rather than a legacy story.

Other manufacturers have broken out. They own large parts of their software stack, control their diagnostics, and collect telemetry at a scale no Tier 1 ever offered them. Good. They have removed the obstacle. They have not removed the problem.

Access is not understanding. In-house teams still own different layers, use different tools, ship on different schedules and optimize for different targets. A component can behave exactly as its developers intended and still be what degrades the system next to it. Terabytes of data are not an answer, and they are certainly not an answer that arrives in time.

So the test for an advanced OEM is blunt. When long-term stability gets worse, how long does it take you to establish why? Days? Weeks? Longer than your release cycle? Some hard problems will always take time. But if the release pipeline consistently outruns your ability to detect and explain degradation, your software is evolving faster than the evidence you need to manage it.

The industry has good ways to describe how software-defined a vehicle is: how far hardware and software are decoupled, how much can be updated over the air, whether new capabilities can arrive after delivery. Those criteria measure how easily a vehicle can change. None of them measures whether the manufacturer understands what the change did. That deserves its own line on the scorecard: Can the manufacturer show, release after release, whether the complete vehicle’s long-term stability and performance got better or worse, and explain why fast enough to act on it?

This is not a call to analyze everything in-house or to test every software combination. It is a call to keep the evidence continuous as the software changes: knowing which earlier results still hold, which need to be redone, and where new risk has appeared. And it means retaining enough access, authority and engineering capability to investigate the product you are accountable for. For the hostage OEM, the first step is getting that access back. For the advanced OEM, the harder task is making sure system-level understanding scales with the release pipeline it has spent years building.

Customers don’t experience your validated components, your supplier contracts or your green dashboards. They experience one vehicle, including every interaction nobody tested for long enough. The industry has become very good at measuring how much of a car can be changed through software. It should be just as demanding about how much of that car the manufacturer can actually explain.

References and further reading
Neukirchner, M. (2024). Software-defined Vehicles – A Classification Approach. ATZ Electronics Worldwide.
Bezerra, M. (2025). Defining a Standardized SDV Maturity Framework. Omdia, commissioned by HERE Technologies.