The vehicle becomes a software project

[nfobox]

About this article

This post is an English translation of a guest article by our CEO and co-founder Per Sigurdson. Springer Professional first published it in German on 27 October 2026 as Vehicle-as-Code: Das Fahrzeug wird zum Softwareprojekt, in its Automobil + Motoren section. The original is free to read.

Springer Professional is Springer Nature’s digital library for engineers and business professionals. Its publisher, Springer Fachmedien Wiesbaden, also publishes ATZ (Automobiltechnische Zeitschrift), which automotive engineers have relied on since 1898. Germany is one of our most important markets, and we’re proud to share these ideas with its engineering community.

[/nfobox]

English translation of the original article in German:

‍Vehicle-as-Code: the vehicle becomes a software project

When the entire E/E architecture exists as executable code, teams can test vehicle software before the hardware exists. That changes who has access to the complete vehicle during development.

Software-defined vehicles call for ways of working that have been standard in IT for years: version-controlled code, automated testing and continuous integration. In automotive development, however, these methods hit a structural limit. Many processes are hardware-centric, toolchains are often closed, and integration of the overall system happens late. This is exactly where the Vehicle-as-Code approach comes in.

What Vehicle-as-Code means

Vehicle-as-Code describes the entire vehicle system, including ECUs, networks and interfaces, as machine-readable, version-controlled code. This lets you treat the vehicle like a software project. Teams can track changes, compare variants and test the system automatically, without waiting for physical prototypes.

The starting point is description formats the industry already uses, such as the ARXML or DBC files of the E/E architecture. From these comes an executable model that reproduces the network communication of the production vehicle, including the encoding and addressing of data packets. Until now, virtualization in the automotive industry has focused mainly on the cockpit and infotainment. Vehicle-as-Code extends the scope to the complete E/E architecture and enables cross-system testing in early development phases.

Why hardware becomes the bottleneck

In many development organizations, numerous teams share a few expensive hardware test rigs. Tests have to be scheduled and prioritized, and errors at the interfaces between departments or suppliers often appear only when the components physically come together. The later such an error shows up, the more costly it is to fix.

A virtual complete vehicle moves this integration work forward. As soon as a first architecture description exists, teams can test against the same current state, in parallel instead of one after another. Test rigs don’t become obsolete. Virtual models can be coupled with real hardware, and physical testing remains essential for final validation. But it becomes the last step instead of the first integration point.

Democratizing software development

In this context, democratization mainly means access. When the complete vehicle exists as code, integration tests are no longer tied to test rig capacity or prototypes. Every team, supplier and technology partner can work from the same data, on a laptop, in the cloud or in a CI pipeline. This requires open standard formats and portable models that aren’t locked to a single toolchain or hardware supplier.

RemotiveTopology shows how this approach works in practice. RemotiveLabs’ vehicle virtualization platform represents the entire E/E architecture as code and runs the same network communication as the production vehicle. Google Cloud has now integrated the platform into Horizon, its development environment that makes it easier for OEMs and suppliers to develop software for Android Automotive OS. This extends Horizon beyond the cockpit and central compute units to the complete vehicle. As Florian Haubner, Industry Architect Lead at Google Cloud, explains, developers and AI agents can now test the entire vehicle virtually, long before the first physical builds.

The role of AI agents

Vehicle-as-Code also lays the groundwork for using AI agents efficiently in vehicle development. AI agents need two things: a complete, machine-readable representation of the system, and a virtual environment where they can develop, coordinate and test collaboratively. A consistently code-based vehicle architecture provides both.

AI tools can then be used in vehicle development much as in other software projects, for example to create test cases, check interfaces or assess how a change affects the whole system. What matters is that the agents work on an executable model whose results can be verified immediately, not on documentation.

What OEMs should clarify now

The approach doesn’t run itself. A virtual vehicle is only as good as the architecture description it’s based on. There are also organizational questions: who maintains the model, how suppliers are involved, and how virtual test results feed into existing release processes.

OEMs that answer these questions early regain control over their own software environment. They can run integration tests much earlier and apply methods like continuous integration and automated testing consistently. In the long term, an open, executable complete vehicle model could become an industry standard. It would make the vehicle accessible to everyone involved, instead of tying it to test rig capacity and late prototypes.

‍

‍