Run your E/E architecture as code

Vehicle as Code - executable specification

RemotiveTopology orchestrates virtual, hybrid, and physical vehicle nodes - a stack-neutral integration layer that lets OEM and Tier 1 teams develop and validate SDV software long before silicon and test benches exist. Vehicle as Code brings you the ability to execute at vehicle level from day one, including the nodes that matter most: AD/ADAS, infotainment, and the full E/E communication.

Vehicle as Code by RemotiveLabs - define the platform, configure the instance, run your test cases - executable specification.

The harness for Software Defined Vehicles

RemotiveTopology turns your existing E/E architecture into a running environment supporting testing, prototyping and development processes from day one to SOP. Explore live communication, test software virtually, and connect real hardware - all from the same platform. Everything is described in standardized text files. This simplifies version control, eliminates tool silos, and ensures every team member works from the same source of truth. Describe the architecture. Define what to instantiate and how. Run vehicle-level test cases - from SIL on a laptop to a full HIL rig.

What is Vehicle as Code?

Infrastructure as Code transformed how software teams manage servers and cloud environments - declarative, version-controlled, reproducible. RemotiveTopology's Vehicle as Code (VaC) approach brings the same principle to the E/E architecture. It enables a modular way of describing platforms and instances. The E/E architecture, ECU configurations, and different environments live in version-controlled text files. Industry-standard formats (ARXML, DBC, LDF, FIBEX) are used to describe the vehicle. In the instance file you describe what you run and how.

Key benefits with Vehicle as Code:

  • When SIL is in code everyone sees the same environment when using the same version.
  • Existing artefacts become runnable and shareable across teams for early integration testing.
  • HIL setups are easier to debug and replicate on new rigs by removing manual steps.
  • Continuous integration catches version mismatches early.
RemotiveStudio - Vehicle as Code Instantiate and interact

Example of RemotiveTopology Vehicle-as-Code instantiating the BCM ECU as a Python Behavioral Model and then interacting via RemotiveStudio.

Describe and emulate the E/E architecture

The vehicle platform in RemotiveTopology covers all ECUs, communication channels, and signal encoding - combining existing database files (ARXML, DBC, LDF, FIBEX) using a straightforward format (YAML). This is the foundation that gives OEMs, Tier 1s, and technology providers a working Vehicle as Code setup. The format also allows you to add information missing from existing files. For example, combining ARXML with DBC and setting the baudrate on a channel:

Copy
includes:
 - ./databases/my-ecu.arxml
channels:
  DriverCan:
    type: can
    database: ./databases/driver_can.dbc
    baudrate: 500000

RemotiveLabs provides free lightweight tools including RemotiveCLI and RemotiveStudio so that every team member can view and inspect architecture files including ARXML, DBC, FIBEX. A RemotiveTopology license is only required when you want to run the topology.

ARXML tree view of actual database file

View, navigate and explore ARXML or DBC files in RemotiveStudio. This example shows the actual tree structure view of the vehicle platform derived directly from a database file.

Guide: Visualize and explore ARXML / DBC files

When the E/E architecture lives in Git alongside all other source code, it becomes the single source of truth. CI jobs catch version mismatches automatically and vehicle-level integration testing can left-shift and start early.

Running and maturing the executable vehicle

Once the architecture is described, instantiate it with a single text file. By default, all selected ECUs run as virtual mocks - giving you an immediately inspectable network environment.

You rarely need the full vehicle or E/E architecture. Start with the subsystem you are working on and describe the instance in a simple text-based file - for example, three mock ECUs:

Copy
platform:
  includes:
    - ./main.platform.yaml
ecus:
  ABS:
    mock: {}
  BCM:
    mock: {}
  GWM:
    mock: {}

Each ECU runs as a container (Docker or Podman), connected via virtual networks such as SocketCAN. To replace a mock with real production code, all you have to do is provide a Dockerfile and then replace the mock with this container:

Copy
ecus:
  BCM:
    container:
      build:
        dockerfile: ../ecus/abs/Dockerfile

Hardware nodes slot in just as easily - example below of specifying the CAN device that represents the Channel and that the GWM ECU is not part of the virtual environment.

Copy
channels:
  ChassisCan0:
    type: can
    driver:
      type: remotivebus
      config:
        type: can
        host_device: can0
ecus:
  GWM:
    external: {}

Create hybrid environments spanning SIL and HIL by combining ECUs running as mocks, with ECUs running as containers, with other ECUs running on hardware.

Multi-domain: run the E/E architecture with ADAS & Infotainment

An advantage of Vehicle as Code is the ability to run key nodes such as ADAS and infotainment together with the context of the full E/E architecture. This enables holistic integration testing from the start, not just near SOP.

Running nodes inside a realistic virtual vehicle network means teams can validate behavior together with cross-ECU dependencies and bus communication - surfacing issues that isolated testing would miss. Explore multi-domain executable vehicle example on GitHub.

RemotiveTopology - the Harness for SDV Software Defined Vehicles

System-level behavior becomes visible early withRemotiveTopology as the harness for virtual vehicle validation: [url_intern=/products/remotivetopology]RemotiveTopology[/url] connects domains in a single source of truth and version controlled E/E architecture.

Vehicle harness for AI

A test harness wraps a unit under test so you can observe and control its behavior. RemotiveTopology provides that harness for the full vehicle environment - making both developers and AI agents productive throughout the entire development cycle, from early SIL to beyond SOP. When the information is accessible in text files and the vehicle is executable, integrations that would take weeks can happen in an afternoon.

talk to your EE architecture - AI vehicle development

How a non-android developer built and integrated an instrument cluster in 4 hours:

  • RemotiveTopology's text-based architecture provides a legible foundation - query signals, trace ECU ownership, inspect encoding.
  • Having the vehicle executable in RemotiveTopology provides the ability to deploy, trigger, and observe behavior in a live virtual environment.

How to talk to your E/E architecture
Arm: Scalable digital twin for next-generation automotive development

RemotiveLabs and Arm combine virtualized Arm-based compute with cloud-native simulation to build, test, and validate automotive software before hardware exists.

Run Android Automotive on virtual ECUs and replay real-world drive cycles.

Integrate hardware nodes only when needed - from infotainment and ADAS to system-level CI.

Enable multi-supplier collaboration at cloud scale.

Use case: Arm digital twin
RemotiveLabs and Arm digital twin
digital.auto - 360° Continuous Lifecycle Engineering

Kaizenics, RemotiveLabs, Bosch and partners in the digital.auto community connect engineering data, agentic orchestration, and executable vehicle environments into one development loop. SDV Forge is a vendor-neutral execution framework that makes early, continuous vehicle-level integration operational for OEMs.

Start day one with an executable vehicle scaffold in RemotiveTopology.

Make vehicle-level behavior visible early - across domains, suppliers, and variants.

Download white paper: SDV Forge part 1
SDV Forge - RemotiveTopology as the executable specification
Vayavya Labs: System-level ADAS validation with the full vehicle E/E architecture in SIL

RemotiveLabs and Vayavya Labs combine Autoware, CARLA, and RemotiveTopology to run an autonomous driving stack inside a realistic virtual vehicle network - closed-loop, from week one.

Validate AD behavior together with signal timing, cross-ECU dependencies, and CAN/Ethernet/LIN communication - without HIL benches or physical prototypes.

Catch system-level issues earlier, reuse the same validation environment and stop waiting for hardware before integration work can begin.

Use case: ADAS validation Vayavya Labs
AD ADAS validation with EE architecture
End-to-end digital cockpit integration with HERE Navigation

RemotiveLabs and HERE Technologies run a full virtual cockpit - navigation, instrument cluster, and 3D cabin rendering - all integrated within RemotiveTopology, no hardware required.

Replay real CAN recordings and validate navigation, cluster behavior, and signal interactions simultaneously.

Close the gap between design, engineering, and validation from day one.

When the vehicle is in code, missing pieces move fast: an AI agent wrote the instrument cluster VHAL integration in an afternoon.

Use case: HERE digital cockpit integration
Digital cockpit virtual integration - Here navigation and instrument cluster
Related articles

Blog posts related to vehicle virtualization

Blog
Street lights city