Modular vehicle software development across SIL and HIL
Vehicle software development and testing is often a complex task. RemotiveTopology simplifies this process by providing a structured way to describe the system (the topology) while allowing seamless integration of virtual and physical nodes. It supports everything from early-stage component development to large-scale Hardware-in-the-Loop (HIL) testing. Making vehicle simulation smooth!
Break silos by decoupling software development from hardware
RemotiveTopology was built to break down the barriers between software and hardware SDV development, by virtualizing the entire communication layer. Mix mocks, models, and real ECUs in one setup — so teams can develop, test, and deliver software independently of hardware timelines.
Go from virtual nodes to HIL boxes and advanced simulations. It just works—thanks to containerization and a consistent communication backbone. The video shows a hybrid rig including NI hardware. It's all containerized and based on the same production communication.
Start testing your vehicle platform earlier – without the need to wait!
RemotiveTopology makes it possible to test ECUs as well as doing integration testing of core computers – before you have all involved ECUs in place. Don’t sit around waiting for hardware, for access to HIL rigs or for other teams to complete their ECU software. Start testing your software straight away, on your own laptop or in a CI/CD pipeline of your choice.
$ remotive topology generate -f lighting.instance.yaml build
$ docker compose up -f build/lighting/docker-compose.yaml upCode samples - get stuff done from day 1
Install RemotiveTopology
RemotiveTopology is part of RemotiveCLI, see documentation for details.
curl -fsSL https://files.remotivelabs.com/remotivelabs-cli/install.sh | bashStart with low-fidelity mocks
In RemotiveTopology, an ECU can be represented by a mock, a logic-free node designed to send static values across the network. The mock's configuration is managed externally, e.g. through a test case or using a Jupyter notebook.
# 1. Set turnstalk to left as sent from steering ECU on CAN
await self._client.restbus.update_signals(
(
"SCCM-DriverCan0",
[
RestbusSignalConfig.set(name="TurnStalk.TurnSignal", value="LEFT"),
],
)
)
# 2. validate that left turn lights are blinking using front light ECU
sub = await broker_client.subscribe(("FLCM-BodyCan0",
[
"TurnLightControl.LeftTurnLightRequest",
"TurnLightControl.RightTurnLightRequest"
]
))
)
await await_at_most(seconds=2).until(
partial(take_values, sub),
equal_to({
"TurnLightControl.LeftTurnLightRequest": 1,
"TurnLightControl.RightTurnLightRequest": 0
}),
)
Describe the platform
In order to work with RemotiveTopology you need to describe the platform you want to use. The first steps when describing the platform is collecting all the information you already have. This can include signaldatabases such as DBC or complete ARXML files. You can also add missing information using a simple YAML format.
DBC files does not contain that much topological data, but at least you can see what ECUs are available:
$ remotive topology show topology lighting_and_steering/databases/body_can.dbc
---
channels: {}
ecus:
ADAS: ...
BCM: ...
DIM: ...
FLCM: ...
GWM: ...
RLCM: ...Infrastructure as code
Using RemotiveTopology you describe your virtual test environment as code which ensures consistent and repeatable behavior. The virtual environment can also be combined with real hardware.
1# ECUs to instantiate
2ecus:
3 # a mock for SCCM
4 SCCM:
5 mock: {}
6
7 # a python model for BCM
8 BCM:
9 models:
10 bcm:
11 type: container
12 container:
13 build:
14 dockerfile: ../Dockerfile
15 volumes:
16 - ../ecus/bcm:/app/bcm
17 working_dir: /app
18 command: python -m bcm
19
20 # no behavior needed for FLCM
21 FLCM:
22 channels:
23 BodyCan0:Frequently Asked Questions
RemotiveTopology lets developers test against a vehicle's electrical/electronic (E/E) architecture before physical hardware exists.
RemotiveLabs' vehicle virtualization tool, RemotiveTopology, describes and runs an entire vehicle as code, both virtually and connected to hardware. Instead of static architecture documents, engineers define the vehicle's E/E architecture, ECUs, buses, and signal databases as an executable, version-controlled specification. This single source of truth runs identically on a developer's laptop, in a CI/CD pipeline, or on a HIL rig, and you can share it directly with suppliers so everyone works from one shared version.
Because the simulation environment mixes mocks, behavioral models, virtual ECUs, and real hardware in one topology, teams test and iterate without waiting for final hardware or production code.
RemotiveTopology's interface is open and stack-neutral, built on gRPC and standard protocols. You can bring any AI agent, whatever vendor or framework it runs on, and connect it directly, with no proprietary wrapper in between.
That agent then queries, tests, and acts on the topology just as readily as a human engineer does. A topology behaves consistently everywhere. Teams, individual roles, and agents alike validate and iterate on a shared executable specification long before hardware exists, then mature it across environments.
Learn more about RemotiveTopology's core concepts in the documentation.
Traditional automotive software development ties integration testing to hardware availability. Errors surface late, at the HIL (hardware-in-the-loop) or vehicle stage, when they are most expensive to fix.
RemotiveTopology left-shifts that work. The platform offers a single-source-of-truth that lets engineers mock external dependencies and validate interfaces in a virtual environment from day one. That test setup then carries forward through every stage of the toolchain: from early testing to SIL (software-in-the-loop), HIL (hardware-in-the-loop), and VIL (vehicle-in-the-loop).
The simulation environment runs continuous, end-to-end integration tests at every stage. Teams and suppliers catch interface and integration issues early as a result, improving software quality before it reaches the vehicle.
A topology description works as your virtual harness. It captures one machine-readable definition of every ECU, network (CAN, SOME/IP, Ethernet), and signal database (DBC, ARXML) that makes up the vehicle's E/E architecture.
Because the definition lives in code, not a diagram, you version it, share it across teams, and keep it in sync as the architecture evolves. This executable source of truth replaces scattered spreadsheets and static wiring documentation.
That virtual harness then carries into every later stage, including a HIL bench wired to real hardware. Learn more on SIL to HIL.
Start on day 1: no need to wait for FMUs or AUTOSAR SW components the way other virtual environments do.
Run a topology in minutes: go from a fresh checkout to a running virtual vehicle without provisioning hardware.
Real network protocols: connect directly to physical hardware and standard tooling, with no proprietary black box.
Open and stack-neutral: gRPC and standard interfaces integrate with CI, simulation tools, and hardware of choice.
Containerized architecture: interoperates with other simulation tools instead of locking you into one vendor's suite.
Lower cost, faster time to market: fewer physical prototypes and fewer expensive late-stage surprises, using standard hardware instead of proprietary, lock-in solutions.
RemotiveTopology speaks real network protocols, the same CAN, LIN, SOME/IP, and Ethernet buses used to connect ECUs in a production vehicle. Any hardware of choice, from a single ECU to a full HIL rig, connects directly, with no proprietary lock-in.
The platform itself runs on commodity hardware, standard Linux machines rather than specialized boxes. It integrates directly with your existing setups and tooling, so you extend what you already have instead of replacing it.
Swapping a virtual ECU for real hardware, or running a mixed setup, is just a configuration change. A bus adapter from partners like Kvaser or National Instruments bridges the physical bus to its matching virtual one, so the physical ECU sees identical frames, encoding, and addressing to a real vehicle network. See how this works with Kvaser hardware.
RemotiveTopology offers several ways to get started, from a free trial to a fully supported pilot:
- Evaluation trial: free for 30 days, so you explore the platform on your own first
- Single Deployment: €4,000/year for one user on a single physical or virtual Linux machine, without CI/CD
- Cloud Deployment: from €2,500 per user/year for teams running CI/CD pipelines, with volume and fixed-fee discounts for larger deployments
-Get-stuff-done package: €45,000 for three months of unlimited usage, bundling software licenses, developer training, a custom virtual setup, and a demo bridging that setup to real hardware and CI
Follow the installation instructions to start your trial, or see full pricing and contact us for the right plan.
- Tools to deploy and run a topology in a containerized environment
- A framework for writing behavioral models in Python
- A testing framework with network probes and programmable mocks
- Integration with simulation tools such as FMUs and Synopsys Silver
- A file format to define a topology (e.g., specifying ECUs, connections, and behavioral models)
RemotiveTopology uses RemotiveBroker instances as the backbone of the platform. These brokers handle the reading and writing of vehicle data. The software nodes operate within Docker containers, ensuring communication over virtual or physical buses such as CAN, LIN, and Ethernet (including SOME/IP), mimicking real ECU operations. The communication uses actual automotive protocols, making it easy to replace mocks with real components.
RemotiveBroker supports various interfaces including CAN, CAN-FD, UDP (Ethernet PDUs), LIN, FlexRay, and SOME/IP see RemotiveBroker documentation.
RemotiveTopology can be integrated with hardware through partners such as National Instruments (NI). NI provides a hardware platform that can connect to the virtual environment through a gRPC interface. This allows for hybrid test scenarios where virtual ECUs interact with physical sensors, actuators, or ECUs. Read more about the NI integration.
RemotiveTopology supports parsing of signal databases such as DBC, FIBEX, and ARXML, as well as platform or system extract files. RemotiveTopology extracts all necessary information and allows you combine any signal databases your have, see RemotiveTopology documentation.
RemotiveTopology includes a framework to write behavioral models in Python. These models allow developers to define the behavior of the ECU in order to test specific scenarios. RemotiveTopology also supports FMU (Functional Mock-up Unit) to define the behavior of an ECU. See documentation about Behavioral Models.
RemotiveTopology allow developers to used any test framework. RemotiveTopology documentation includes examples for both Pytest and Behave (using Gherkin), see RemotiveTopology Usage.
The RemotiveTopology Framework allows a developer to easily create behavioral models and control their behavior. The framework uses the RemotiveBroker to handle all automotive communication protocols. It includes a restbus which enables continuous sending of messages according to cycle time. Read documentation for RemotiveTopology Framework.
RemotiveTopology integrates with CI/CD pipelines like Jenkins, GitHub Actions, and Zuul. The platform can run tests in these pipelines, and provide reports of the test results through e.g. pytest. By integrating with CI, the same tests used on a developer’s laptop can be used in CI.
Yes, RemotiveTopology integrates with advanced simulation tools such as Synopsys Silver. Synopsys models can mimic hardware behavior with high fidelity and run the actual software intended for ECUs. This allows the inclusion of detailed simulations in a RemotiveTopology setup. RemotiveTopology also supports the use of FMUs (Functional Mock-Up Units) to define the behavior of the ECU.
Developers can interact with a RemotiveTopology setup programmatically through its API, or using tools like Jupyter Notebook, which offers a graphical user interface to interact with virtual ECUs and execute test cases. This user-friendly approach allows the developers to manipulate the state of the system from an UI. RemotiveTopology also supports use of standard tools like Wireshark or candump to inspect network traffic.
RemotiveTopology facilitates a smooth transition between different testing environments, including Software-in-the-Loop (SIL) and Hardware-in-the-Loop (HIL). By allowing for reusable test cases from virtual to physical setups, it ensures that the functionality of the software remains consistent, regardless of whether it is running in a fully virtualized environment, on a simulated platform or on physical hardware. It bridges the gap between these environments by enabling hybrid setups where virtual and real components interact. Standard communication interfaces such as CAN and SOME/IP used from the start also enables this reuse throughout the different phases of development. The tool integrates with NI hardware so a smooth transition is possible.
RemotiveTopology is designed to be open and easily integrated with other tools and environments including CI/CD pipelines, simulation tools, and hardware solutions. It uses standard protocols such as gRPC for communication, thus reducing the lock-in with proprietary systems. It can be integrated into CI systems such as Zuul and Jenkins. It is also integrated with simulation tools such as Synopsys Silver, which is used for high-fidelity modeling. Hardware I/O is integrated with e.g. NI (Emerson) hardware.
RemotiveTopology pricing overview
Enable yourself or your team to get-going right away
and test your application from day one.
Evaluation
Intended Use: If you want to try out RemotiveTopology and #getstuffdone. Available to organizations of any size that are interested in an exploratory trial.
Details: Follow install instructions and get started. Create your topology based on your own use case and what you want to test.
Single Deployment
Intended Use: For individual users operating on a single physical or virtual Linux machine. Perfect for small enterprises without CI/CD needs or for establishing initial configurations within larger organizations embarking on their #getstuffdone transition.
Details: Grants one user full access and the capability to run RemotiveTopology on the licensed machine.
Cloud Deployment
Intended Use: For teams and organizations using cloud platforms, internal CI/CD pipelines, or shared development servers. Ideal for collaborative environments where multiple users need concurrent access for activities like code commits and triggering CI pipelines.
Details: Discounted rates are available for larger deployments. Licensing can also be arranged at a fixed fee for an entire team, department, or company, based on organizational needs.
Want to kick-start your RemotiveTopology experience?
With our Get-stuff-done pilot package, we introduce a collaborative way-of-working; start using RemotiveTopology during a three (3) month period that includes:
- All necessary software licences
- Education and training for your developers
- Services to jointly create a working virtual setup in your environment that demonstrates the key concepts (ECU mocking plus bridging virtual and physical CAN buses) that can be used as a base for further development
- Demonstration how to connect the virtual setup to physical hardware and/or CI pipeline
A typical setup within the three (3) month period:
- Select one (1) ECU to be tested and run this in a virtual environment
- Setup the necessary ECU mocks (typically 5-10 ECUs) communicating over actual automotive protocols (CAN, SOME/IP etc)
- Create a number of test cases to verify the ECU under test
- Create a Jupyter Notebook, which enables interaction with the ECUs using a graphical user interface
- Run on a Docker enabled Linux PC or cloud environment
Get-stuff-done package
A collaborative way-of-working
3 months unlimited usage
Articles related to RemotiveTopology
.png)
.jpg)
.jpg)
Join the automotive rebels that #getstuffdone with RemotiveLabs!
