A good recording of a drive is often the most useful test data you will ever have. With\nRemotiveTopology you can play that recording back onto virtual buses and watch it in\nRemotiveStudio, with the camera videos in sync. This post covers how to set that up and\nwhat we use it for day to day.
\nPlayback, also called open loop simulation, sends recorded vehicle data back onto the\nchannels of a running topology as if the vehicle were there. Three things make that useful:
\nEverything starts with a recording session: a YAML file with the session's start and end\ntime, the recording files, any video files, and a mapping from the recording equipment's\ndevice names to the platform's channels. RemotiveTopology reads CAN dumps and CSV in long\nformat (timestamp, signal name, signal value). This example is taken from the docs:
\nschema: remotive-recording-session:0.2
name: Roundabout left turn
start_time: 1753865338s
end_time: 1753865361s
files:
- location: ./candata.log
type: recording
- location: front.mp4
name: front
type: video
start_time: 1753865335s
mapping:
includes:
- ../equipment.mapping.yaml
Some things to watch for:
\ncan0 on the logger into DriverCan in your platform. If\nthe device names already match the channel names, you don't need one. If you keep the\nmapping in its own file, several recordings made with the same equipment can share it.name (front, rear and so on). Dashboards pick videos by that name, so\none dashboard works for every session from the same car. Set the video's start_time\ntoo: the camera rarely starts at the same moment as the logger. Use MP4 with H.264 and\nAAC, since RemotiveStudio runs in a browser.You don't have to write the file by hand: remotive topology recording-session create -f candump.log generates a session from one or more recording files, and recording-session recalculate updates its start and end time after you change file offsets. See\nRecording concepts\nfor the details.
Playback needs a running topology instance whose platform has every channel the mapping\nuses. The instance can have more channels than that, so a recording of only one bus works\ntoo. To get a simple instance with default settings and no behavioral models, generate it\nfrom the session, then build and run it:
\nremotive topology recording-session instantiate roundabout.recordingsession.yaml playback.instance.yaml
remotive topology generate -f playback.instance.yaml build
docker compose -f build/<instance>/docker-compose.yml --profile ui up
You don't need a new instance for every recording. If you recorded several drives with the\nsame platform, you can use one instance to play all of them. The\nUsage page\nalso shows how to add your own signals that aren't on the vehicle platform, such as emulated\nGPS, through a CSV file and an extra channel.
\nStart RemotiveStudio in your workspace with remotive studio . and open a dashboard. The\nAdd Panel picker has two groups. Use Open recording from the recordings group\nto load the session for playback, then add a Video panel for each camera. The\nvideo stays in sync with the signal timeline. Next to them, add the chart panels you need: a\nTime series for the signals you care about, a Trace for raw frames, a Map if the\nrecording has latitude and longitude, or a Frame distribution to see which frames\nare sent most often.
One tip from experience: use only one dashboard tab. RemotiveStudio warns if it sees more\nthan one dashboard running, and you may find that playback controls stop responding or\nvideos don't play. The Add a panel\npage lists every panel type.
\nThe same controls are in RemotiveCLI, which is handy from a script or when you only want\nto jump to the interesting moment. Offsets can be given in minutes, seconds, milliseconds\nor microseconds:
\nexport REMOTIVE_RECORDING_SESSION_PATH=<recording session>
remotive broker playback open \"$REMOTIVE_RECORDING_SESSION_PATH\"
remotive broker playback play \"$REMOTIVE_RECORDING_SESSION_PATH\" --offset 10s
remotive broker playback pause \"$REMOTIVE_RECORDING_SESSION_PATH\"
remotive broker playback seek \"$REMOTIVE_RECORDING_SESSION_PATH\" --offset 15000ms
remotive broker playback repeat \"$REMOTIVE_RECORDING_SESSION_PATH\" --start-offset 10s --end-offset 20s
remotive broker playback status --stream
repeat loops a part of the recording, which is useful while you change a behavioral\nmodel and want the same few seconds over and over. Run it with --clear to stop the loop.\nEvery command takes --url if your broker isn't on http://localhost:50051. All\noptions are in the\nRemotiveCLI manual.
For regression tests, playback can also be controlled from code, for example from a test\ncase running in its own container in the topology, and the topology can be shut down when the tests\nare done (see Running).\nTo try all of this without a recording of your own, the\nexamples\ninclude a Tesla Model 3 drive with two CAN buses and four camera videos.
", "url": "https://developer.remotivelabs.com/blog/2026/09/15/playing-back-recordings", "title": "Playing back recordings", "summary": "Replaying a recorded drive in RemotiveStudio and RemotiveCLI, and why that helps with debugging, development and regression tests.", "date_modified": "2026-09-15T00:00:00.000Z", "author": { "name": "Ola Nilsson" }, "tags": [] }, { "id": "https://developer.remotivelabs.com/blog/2026/09/03/sniffing", "content_html": "Plug into a CAN bus and you get a wall of hex: IDs, lengths and data bytes scrolling past faster\nthan you can read them. This post walks through how I capture that traffic on Linux, keep it in\na file, and turn it into named signals with a DBC using RemotiveTopology and RemotiveStudio.
\nSniffing means listening to a bus without taking part in it. You see every frame that ECUs send,\nwith timestamps, which is exactly what you want when you're asking questions like \"does the BCM\nactually send the turn signal frame when I flip the stalk?\" or \"how often does this frame show up?\"
\nWhat you don't get from the wire is meaning. A CAN frame is an ID and up to 8 bytes (64 for CAN\nFD). Which bits are vehicle speed, and how to scale them, lives in a signal database such as a\nDBC. So sniffing is really two jobs: capture the raw frames, then decode them.
\nEverything below assumes Linux, because it relies on SocketCAN. Once your CAN adapter shows up as\na network interface, standard tooling such as candump from can-utils works against it. The\nRemotiveTopology docs\nrecommend giving the interface a name that matches your architecture rather than can0:
sudo ip link set can0 name drivercan0
That small habit pays off later, when you have three adapters plugged in and need to remember\nwhich one is on the driver CAN.
\nIf the traffic you want to look at comes from containers, for example behavioral models in a\ntopology, RemotiveBus can expose\nit on the host. A vcan network with a host_device creates a virtual CAN interface on the host,\nso you can sniff simulated traffic with the same tools you use on a real vehicle:
type: vcan
device: mybus
host_device: myhostbus # Name of the virtual CAN interface to create on the host
To go the other way and let containers use a physical bus, use type: can with host_device\npointing at the adapter. Note that Docker appends a 0 to the device name inside the container.
With the interface up, start with a live look:
\ncandump drivercan0
Once you've confirmed frames are flowing, log them to a file instead. candump -l writes a\ncandump-<date>.log file in the current directory, in the \"CAN dump\" format that both\nRemotiveTopology and RemotiveCloud read. Drive the scenario you care about, then stop it with\nCtrl+C.
Before you do anything else with the log, check it with RemotiveCLI. If a colleague needs the\ncapture in another format, the same tool converts between .log, .asc and .blf:
remotive tools can validate candump-2026-09-03_101500.log --print-to-terminal
remotive tools can convert candump-2026-09-03_101500.log drive.blf
Both commands are described in the\nRemotiveCLI reference.
\nNow for the decoding. In RemotiveTopology, the signal database belongs to a channel in your\nplatform. A DBC doesn't say which bus it describes, so you name the channel yourself\n(platform docs):
\nschema: remotive-topology-platform:0.15
channels:
DriverCan:
type: can
database: ../databases/driver_can.dbc
Next, wrap the log in a recording session, and add a\nrecording mapping\nthat connects the interface name in the log to the platform channel:
\nremotive topology recording-session create -f candump-2026-09-03_101500.log drive.recordingsession.yaml
schema: remotive-recording-mapping:0.1
devices:
drivercan0: DriverCan
If you named the interface the same as the channel, you can skip the mapping: a default mapping\nfrom same-name devices is created automatically. Then create an instance for playback, generate\nit and start it with the UI profile, as described in\nrecordings usage:
\nremotive topology recording-session instantiate drive.recordingsession.yaml drive.instance.yaml
remotive topology generate -f drive.instance.yaml build
docker compose -f build/<instance>/docker-compose.yml --profile ui up
In RemotiveStudio, the\nSignal view lists every\nframe and signal in the DBC, with unit, factor/offset and named values, which is handy for\nfinding the signal you're after. Then build a dashboard with a few\npanels, with an Open\nrecording panel to play back the log:
\ncandump: timestamp, frame ID, frame name and raw bytes,\nwith signal values when you expand a row.If you'd rather not set up a platform, you can upload the log to\nRemotiveCloud, either by drag and\ndrop or with remotive cloud recordings upload. It matches the recording against the signal\ndatabases in your project and suggests the best fit. And for Ethernet traffic between containers,\nincluding SOME/IP, Edgeshark and Wireshark\nlet you inspect each connection in a running topology.
Whichever route you take, the idea is the same: capture first, keep the raw log, and let the\nsignal database do the decoding. The log stays useful long after the drive is over.
", "url": "https://developer.remotivelabs.com/blog/2026/09/03/sniffing", "title": "Sniffing CAN traffic and making sense of it", "summary": "Capture raw CAN traffic with candump, then decode it with a DBC in RemotiveTopology and RemotiveStudio.", "date_modified": "2026-09-03T00:00:00.000Z", "author": { "name": "Ola Nilsson" }, "tags": [] }, { "id": "https://developer.remotivelabs.com/blog/2026/08/20/topologies-in-ci", "content_html": "A topology that only runs on your laptop is a good start, but the real payoff comes when\nevery pull request spins it up, runs the tests and throws it away again. This post walks\nthrough doing that in GitHub Actions: generate the topology, start it with a test container,\nlet pytest talk to the RemotiveBroker, and fail the build when a test fails.
\nRemotiveTopology lets you add your own containers to an instance, next to the ECUs. The\nnice part for CI is that a test runner can be one of them: it starts inside the topology,\non the same networks as everything else, and reaches the TopologyBroker by name. Put it\nbehind a profile so it\nonly runs when you ask for it:
\ncontainers:
tester:
profiles: [tester]
build:
dockerfile: ../../../python-runner.dockerfile
volumes:
- ../tests:/app
working_dir: /app
command: \"pytest --broker_url=http://topology-broker.com:50051 -s -vv\"
The Dockerfile only needs Python and your test dependencies: pytest, pytest-asyncio and the\nremotivelabs-topology package. Profiles map straight to docker compose profiles, so the\ntester stays out of the way when you start the topology without --profile tester to poke\nat it by hand.
One thing to check before moving to a hosted runner: CAN channels default to RemotiveBus,\nwhich needs to be installed on the host. If you don't need SocketCAN in CI, switch the\ninstance to UDP emulation, which works anywhere without extra setup:
\nsettings:
can:
default_driver: udp
Tests use the RemotiveTopology framework,\nthe Python library you also write behavioral models with. A small conftest.py turns the\n--broker_url option from the container command into a BrokerClient fixture. The default\npoints at localhost:50051, which is where the broker is forwarded when you run the topology\ninteractively, so the same tests run from your editor too:
# tests/conftest.py
import pytest_asyncio
from remotivelabs.broker import BrokerClient
def pytest_addoption(parser):
parser.addoption(\"--broker_url\", default=\"http://localhost:50051\")
@pytest_asyncio.fixture
async def broker_client(request):
async with BrokerClient(url=request.config.getoption(\"--broker_url\")) as client:
yield client
A test then subscribes to frames in a namespace (named <ECU>-<Channel>) and waits for the\nsignal values it expects. This one is adapted from the\ntesting examples in the API docs:
# tests/test_hazard_lights.py
from remotivelabs.broker import BrokerClient
from remotivelabs.topology.testing.frames import capture_frames
async def test_hazard_light_sequence(broker_client: BrokerClient) -> None:
async with capture_frames(
(broker_client, \"HazardLightControlUnit-DriverCan0\"),
frames=[\"HazardLightButton\"],
) as cap:
await cap.wait_for_signal_values(
\"HazardLightButton\",
\"HazardLightButton.HazardLightButton\",
values=[0, 1, 0],
timeout=5.0,
)
The tests are async, so set asyncio_mode = auto in your pytest configuration (or mark\nthem with @pytest.mark.asyncio). If you're unsure which namespaces exist, start the\ntopology and run remotive broker signals namespaces --url http://localhost:50051.
Running a topology checks your organization's RemotiveTopology subscription, and a CI job\nshouldn't do that with someone's personal login. Create a\nservice account with the\nRemotiveTopology Executor role instead:
\nremotive cloud service-accounts create ci-runner --role org/topologyRunner --project <project id>
remotive cloud service-accounts tokens create --service-account ci-runner --project <project id>
remotive cloud auth print-access-token --account <email for service account>
remotive cloud organizations list
Store the token as a repository secret, REMOTIVE_CLOUD_AUTH_TOKEN, and the organization\nuid as REMOTIVE_CLOUD_ORGANIZATION. If you run with a RemotiveBroker license file, keep it\nout of the repository: store it as a secret too and point REMOTIVEBROKER_LICENSE at it.
With that in place, the job is four steps: install the\nRemotiveCLI, generate the\ntopology, start it with the tester profile, and clean up.
\n# .github/workflows/topology-tests.yml
name: Topology tests
on: [pull_request]
jobs:
topology-tests:
runs-on: ubuntu-latest
env:
REMOTIVE_CLOUD_AUTH_TOKEN: ${{ secrets.REMOTIVE_CLOUD_AUTH_TOKEN }}
REMOTIVE_CLOUD_ORGANIZATION: ${{ secrets.REMOTIVE_CLOUD_ORGANIZATION }}
steps:
- uses: actions/checkout@v4
- name: Install RemotiveCLI
run: pipx install remotivelabs-cli
- name: Generate topology
run: remotive topology generate -n mytopology -f topology/mytopology.instance.yaml build
- name: Run tests
run: >
docker compose -f build/mytopology/docker-compose.yml --profile tester
up --abort-on-container-exit --exit-code-from tester
- name: Clean up
if: always()
run: docker compose -f build/mytopology/docker-compose.yml --profile tester down
--abort-on-container-exit is what makes this work in CI: when pytest finishes, the tester\ncontainer exits and docker compose stops the rest of the topology. Adding\n--exit-code-from tester, a plain docker compose option, makes the step's exit code pytest's,\nso a failing test fails the job. The down step runs even after a failure, so the runner is\nleft clean.
Generate runs on every job, and that's on purpose: the generated files are completely\noverwritten each time, and any change to the platform or instance files needs a new\ngenerate anyway. Don't commit build/.
Most failures are easier to read in the container logs than in the pytest output alone. Add\na step with if: failure() that runs docker compose -f build/mytopology/docker-compose.yml logs\nbefore the clean-up, and you get the behavioral models' and brokers' side of the story too.\nThe Docker tips page has\nmore commands for following logs per service.
To reproduce locally, run the same generate, then start the topology without the tester\nprofile, as described in\nRunning a topology, and\nrun pytest from your editor against localhost:50051. Same tests, same topology, just with a\ndebugger attached.
An ECU on its own rarely behaves the way it does in the car. It expects to hear its\nneighbors: periodic frames that say the ignition is on, the speed is zero, the doors are\nclosed. This post sets up a basic restbus that sends those frames for you, and a\nRemotiveStudio dashboard where you can see them and change values while everything runs.
\nA restbus simulates \"the rest of the bus\": every frame your device under test expects\nfrom ECUs that aren't there. Most of these frames are cyclic, so the simulation has to\nkeep sending them at the right cycle time, or the device starts logging timeouts and\nfalling back to safe states.
\nIn RemotiveTopology this usually starts with an\nECU mock. A mock is the\nsimpler alternative to a behavioral model: it doesn't decide anything on its own, it\njust provides a restbus that emulates the ECU, and something else (often a test case,\ntoday it's us) decides what it sends. If the code that controls a mock gets complicated,\nthat's a sign it should become a behavioral model instead.
\nStart from a platform with a CAN channel, and instantiate the ECU you want to stand in\nfor with a mock. The\ninstance docs use\na body controller on two CAN buses; mocking it on just one of them looks like this:
\nschema: remotive-topology-instance:0.15
platform:
includes:
- ./topology.platform.yaml
ecus:
BCM:
mock:
channels:
DriverCan0:
Leave out channels (mock: {}) to mock the ECU on every channel it is connected to.\nThen generate the topology and start it in interactive mode, so it keeps running while\nyou work, as described in\nRunning a topology:
remotive topology generate -f mytopology.instance.yaml build
docker compose -f build/mytopology/docker-compose.yml up
The broker inside the topology is forwarded to http://localhost:50051. Each ECU's view\nof a channel is a namespace named <ECU>-<Channel>, so here it's BCM-DriverCan0. If\nyou're unsure, list them:
remotive broker signals namespaces --url http://localhost:50051
Now tell the broker which frames to send. The\nremotive broker restbus\ncommands follow a simple workflow: add, start, update, and stop or reset. Pick a frame\nfrom your signal database (the\nsignal view\nin RemotiveStudio is a quick way to browse them); BodyStatus below is a stand-in name:
remotive broker restbus add --frame BCM-DriverCan0:BodyStatus --cycle-time 100
remotive broker restbus start --namespace BCM-DriverCan0
--cycle-time is in milliseconds and overrides the cycle time from the database; leave\nit out to use the database value. add --start registers and starts in one go.
Start RemotiveStudio on the workspace that holds your topology files, as in\nGetting started:
\nremotive studio .
The dashboard needs a\nrunning topology to connect to; without one it shows \"RemotiveTopology unavailable\".\nCreate a dashboard\nfrom the Topology sidebar panel, then use Add Panel to\nadd panels.\nFor a restbus, three are useful:
\nUse the signal selection button to pick signals for the time series panel. A new\ndashboard is a draft until you click Save As; it's then stored as a\n.dashboard.json file in your workspace, so you can commit it next to the topology and\nopen it again from the Files sidebar.
With frames flowing, change what the restbus sends. update sets the values it emits\nfrom now on; give several comma-separated values and the restbus loops over them.\nFor example, a door signal that reads open on every fourth value:
remotive broker restbus update --signal BCM-DriverCan0:DoorOpen:0,0,0,1
Use --initial for values that should be sent once before the loop starts. The time\nseries panel follows along as soon as the new values go out, and the trace panel shows\nwhat changed in the raw bytes. To pause, run stop; the configuration stays, so start\npicks up where you left off. remove --frame drops a single frame, and reset clears\neverything for a namespace.
Here the dashboard is the place you watch, and the terminal next to it is where you\nturn the knobs. The same restbus can be controlled from code, too: the\nRemotiveTopology framework\nis a Python library for writing test cases and behavioral models against the same\nnamespaces, which is where to go once a sequence of update commands starts to feel\nlike a script.
If someone on your team already models a system in a simulation tool, you probably don't want\nto rewrite that model by hand as an ECU. With the fmu module in the RemotiveTopology Python\nframework you can load the exported FMU, connect it to the signals on your virtual buses, and\nrun it as a behavioral model next to everything else in the topology.
Also needed in the docs: once this post is written, add (or link to) a matching how-to page under docs/remotive-topology.
A Functional Mock-up Unit is a packaged simulation model, following the FMI standard, that\nmany modeling tools can export. It's a zip file with a model description (the inputs,\noutputs and default experiment settings) and the compiled model.
\nIn RemotiveTopology, an FMU is one of the supported kinds of\nbehavioral model, next to\nplain Python and Synopsys Silver. A behavioral model emulates the behavior of a real ECU, so\nan FMU is a good fit when the behavior you need already exists as a physics or control\nmodel: vehicle dynamics, a battery, a thermal system, or the classic bouncing ball. Instead\nof hard-coding values in a mock, the model reacts to what's on the bus and produces\nrealistic outputs.
\nYou need a working RemotiveTopology setup, as described in\nInstall: Docker (or Podman),\nRemotiveCLI with an active subscription, and Python 3.10 or later for behavioral models.
\nThe FMU support lives in the remotivelabs-topology package behind an extra, since it pulls\nin fmpy and numpy:
pip install remotivelabs-topology[fmu]
Then the FMU itself. The framework drives the model one step at a time, so it needs to be:
\ndefaultExperiment in its model description (that's where the step size is read from).If the FMU doesn't support co-simulation or lacks a default experiment, loading it fails\nwith an error straight away, which is a nice early warning.
\nThe entry point is FMUSimulation. Give it a path, and it reads the model description,\ninstantiates the FMU and resets it to its initial state:
from pathlib import Path
from remotivelabs.topology.fmu import FMUSimulation
fmu = FMUSimulation(Path(\"speed_model.fmu\"))
fmu.print() # dump model information and variables
print(fmu.step_size)
print(fmu.input_var_names)
print(fmu.output_var_names)
print() is the first thing I run on any new FMU: it shows the variable names you'll need\nin the next step. The step size comes from the default experiment, but you can override it\nwith FMUSimulation(path, step_size=0.01).
Each call to await fmu.step() advances the simulation by one step, applies the current\ninputs and returns the outputs. You can also set an input directly with\nfmu.set_input_value(\"name\", value); it sticks for all future steps, and an unknown name\nraises a ValueError.
The FMUBehavioralModel class connects an FMUSimulation to the topology. Inputs are\ndescribed with an InputMapping, a nested dictionary from namespace, to frame, to signal,\nto FMU input name. Namespaces are named <ECU>-<Channel>, as described in\nInstantiating a topology.
In this example (the ECU, frame and variable names are made up), the FMU gets its\naccelerator_pedal input from a signal on ChassisCan0:
from remotivelabs.topology.fmu import InputMapping
input_mapping: InputMapping = {
\"SpeedModel-ChassisCan0\": {
\"PedalStatus\": {
\"AcceleratorPedalPosition\": \"accelerator_pedal\",
},
},
}
Whenever a matching frame arrives, the model writes the signal value to the FMU input.\nValues outside the signal's min and max from the signal database are ignored, so a bad\nframe doesn't push the model into nonsense.
\nOutputs go the other way. FMUSimulation takes an on_output callback that runs after\nevery step with a dictionary of output values. A simple way to put them on the bus is to\nlet a restbus send the ECU's frames and update their signals from the callback:
from remotivelabs.topology.namespaces import filters
from remotivelabs.topology.namespaces.can import CanNamespace, RestbusConfig
chassis_can = CanNamespace(
\"SpeedModel-ChassisCan0\",
broker_client,
restbus_configs=[RestbusConfig([filters.SenderFilter(ecu_name=\"SpeedModel\")])],
)
async def on_output(outputs):
await chassis_can.restbus.update_signals((\"VehicleSpeed\", outputs[\"vehicle_speed\"]))
Putting it together, the model script looks much like any other behavioral model.\nrun_forever() starts a ticker at the FMU's step size, steps the simulation on every tick\nand handles inputs and control requests at the same time:
import asyncio
from pathlib import Path
from remotivelabs.broker import BrokerClient
from remotivelabs.topology.cli.behavioral_model import BehavioralModelArgs
from remotivelabs.topology.fmu import FMUBehavioralModel, FMUSimulation
from remotivelabs.topology.namespaces import filters
from remotivelabs.topology.namespaces.can import CanNamespace, RestbusConfig
async def main(args: BehavioralModelArgs):
async with BrokerClient(url=args.url, auth=args.auth) as broker_client:
chassis_can = CanNamespace(
\"SpeedModel-ChassisCan0\",
broker_client,
restbus_configs=[RestbusConfig([filters.SenderFilter(ecu_name=\"SpeedModel\")])],
)
async def on_output(outputs):
await chassis_can.restbus.update_signals((\"VehicleSpeed\", outputs[\"vehicle_speed\"]))
fmu = FMUSimulation(Path(\"speed_model.fmu\"), on_output=on_output)
async with FMUBehavioralModel(
\"SpeedModel\",
fmu=fmu,
input_mapping={
\"SpeedModel-ChassisCan0\": {
\"PedalStatus\": {\"AcceleratorPedalPosition\": \"accelerator_pedal\"},
},
},
broker_client=broker_client,
namespaces=[chassis_can],
) as bm:
await bm.run_forever()
if __name__ == \"__main__\":
asyncio.run(main(BehavioralModelArgs.parse()))
A bonus you get for free: when the model receives a reboot request, it resets the FMU to its\ninitial state along with the restbuses, so a test can start every case from a known state.
\nIn the instance file, the model is added to its ECU like any Python behavioral model:
\necus:
SpeedModel:
models:
speed_model:
type: python
include: ../ecus
main: speed_model
The container that runs Python models needs the fmu extra installed, so add it to the\nimage or Dockerfile you configure under settings.docker.python. Then generate and start the\ntopology as usual:
remotive topology generate -f mytopology.instance.yaml build
docker compose -f build/mytopology/docker-compose.yml up
If the signals don't show up, check the namespace names first:
\nremotive broker signals namespaces --url http://localhost:50051
fmu module.A gear lever signal that reads 3 doesn't tell you much. Your signal database usually\nknows that 3 means DRIVE, and RemotiveStudio and the Python libraries can use that\nknowledge. This post shows where named values live and how to work with them in both.
Many signals don't carry a measurement. They carry a state: a door is open or closed, a\ngear is in park or drive, a lamp is off, on or failing. On the bus these states are plain\nintegers, and the signal database maps each integer to a name. In a DBC file this is the\nvalue table for the signal; ARXML and LDF have their own ways of describing the same thing.\nThink of it as an enum attached to a signal.
\nRemotiveLabs calls these mappings named values. They come straight from the signal\ndatabases your topology references (DBC, ARXML, LDF, Fibex, see the\nsupported file formats), so\nyou don't define them anywhere else. If the database has them, you can use them.
\nThe quickest way to see what a database defines is the\nSignal view in\nRemotiveStudio:
\n.instance.yaml, .platform.yaml, or\na database file directly.The first time you open the Signal view, RemotiveStudio indexes the signal databases, so\ngive it a moment on large ARXML files. Today the Signal view covers CAN and LIN signals.
\nThis is also a good way to check a database before you write code against it. If you\nexpect GearPosition to have named values and the Signal view shows none, the database\nyou're using doesn't have them, and no code will fix that.
The RemotiveBroker Python API\nexposes the mapping on every SignalInfo in two directions: named_values maps raw\nintegers to names, and value_names maps names back to integers. Here is a small script,\nadapted from the API docs, that prints both for one signal. The DriverCan namespace and\nthe GearData.GearPosition signal are examples; use your own.
import asyncio
from remotivelabs.broker import BrokerClient
async def main() -> None:
async with BrokerClient(url=\"http://127.0.0.1:50051\") as broker_client:
info = await broker_client.get_signal_info(\"GearData.GearPosition\", \"DriverCan\")
if info is None:
raise SystemExit(\"Signal not found in DriverCan\")
print(info.named_values) # raw value -> name, e.g. {0: \"PARK\", 3: \"DRIVE\"}
print(info.value_names) # name -> raw value, e.g. {\"PARK\": 0, \"DRIVE\": 3}
if __name__ == \"__main__\":
asyncio.run(main())
If you're not sure which namespaces exist on a running topology, list them first:
\nremotive broker signals namespaces --url http://localhost:50051
When you subscribe, you can have the client decode values for you. Pass\ndecode_named_values=True to subscribe_frames, and integer values that have a mapping\narrive as their names in frame.signals:
stream = await broker_client.subscribe_frames(
(\"DriverCan\", [\"GearData\"]),
decode_named_values=True,
)
async for frame in stream:
print(frame.signals) # {\"GearData.GearPosition\": \"DRIVE\", ...}
To write a state, look up the raw value with value_names and publish that integer:
from remotivelabs.broker import WriteSignal
await broker_client.publish(
(\"DriverCan\", [WriteSignal(name=\"GearData.GearPosition\", value=info.value_names[\"PARK\"])]),
)
The same lookup works when you set restbus signals with RestbusSignalConfig.set(...).\nIf you write behavioral models or tests with the\nRemotiveTopology framework,\nyou're using the same broker client underneath, so SignalInfo.named_values and\nvalue_names are available there too.
decode_named_values=True, a signal that used to be an\nint becomes a str. Code that compares with == 3 or does arithmetic on the value\nsilently stops matching. Pick one style per script and stick to it.int,\nso handle both types, or look values up yourself with info.named_values.get(value, value).subscribe_frames doesn't decode unless you ask, and\nthe frame handlers in the RemotiveTopology framework take a decode_named_values\nargument that is also off by default. If you see numbers where you expected names,\ncheck this first.value_names instead of hard-coding the integers.info.value_names[\"Park\"] raises a KeyError when the database says\nPARK. Copy names from the Signal view rather than from memory.Named values are a small feature, but they make logs, dashboards and test assertions much\neasier to read. For more on the APIs, see\nAPIs and client libraries.
", "url": "https://developer.remotivelabs.com/blog/2026/06/24/named-values-studio-python", "title": "Named values in RemotiveStudio and Python", "summary": "What named values are, where to find them in RemotiveStudio, and how to read and write them from Python.", "date_modified": "2026-06-24T00:00:00.000Z", "author": { "name": "Ola Nilsson" }, "tags": [] }, { "id": "https://developer.remotivelabs.com/blog/2026/06/10/topology-visualization", "content_html": "When a topology grows past a handful of files, it gets hard to say what's actually in it.\nWhich ECUs does that DBC bring in? What does the instance run in the end? This post walks\nthrough a small example and shows two ways to see the answer: remotive topology show in\nthe terminal, and the topology viewer in RemotiveStudio.
We start with a platform that has two CAN channels, each described by a DBC file. DBC files\ndon't say which channel they describe, so the platform file names the channels and points\neach one at its database:
\n# topology.platform.yaml
schema: remotive-topology-platform:0.15
channels:
DriverCan0:
type: can
database: ../databases/driver_can.dbc
BodyCan0:
type: can
database: ../databases/body_can.dbc
That's the whole file, but it describes more than it seems to. The ECUs come from the DBCs:\nSCCM and BCM are on DriverCan0, and BCM, DIM, FLCM, RLCM and GWM are on BodyCan0. BCM\nsits on both buses.
On top of that we write an instance, which says which part of the platform to run. Here we\nwant BCM with a Python behavioral model, and FLCM as a mock:
\n# main.instance.yaml
schema: remotive-topology-instance:0.15
platform:
includes:
- ./topology.platform.yaml
ecus:
BCM:
models:
bcm:
type: python
include: ../ecus
main: bcm
FLCM:
mock: {}
Before opening any UI, I like to ask the CLI what it sees. Both files live in topology/,\nnext to databases/ and ecus/. Set up a workspace at the root of the project first, so\nrelative includes like ../databases resolve the same way from every subfolder:
cd my_project
remotive topology workspace init
Then show the platform:
\nremotive topology show platform topology/topology.platform.yaml
This prints the platform as platform.yaml, with everything the DBCs added filled in.\nEach ECU lists the channels it's connected to, and each ECU channel gets a database too,\nbecause that's the database the ECU uses to decode signals. If an ECU name isn't what you\nexpected, this is where you find out, before you write an instance that refers to it.
For the instance, use show instance:
remotive topology show instance topology/main.instance.yaml
This shows only the parts of the platform that are instantiated, plus any defaults that\nwere applied. In our case, SCCM, DIM, RLCM and GWM are gone. BCM keeps both channels,\nbecause by default an ECU gets every channel it's connected to. FLCM's mock covers every\nchannel FLCM is on, which here is just BodyCan0.
A few options are handy here:
\n--full-platform shows the full platform, not just the instance-specific parts.--check checks the topology.--json switches the output from YAML to JSON, and -o writes it to a file, which is\nuseful if you want to diff the resolved instance between two branches.YAML is precise, but a tree is quicker to read. RemotiveStudio comes with RemotiveCLI and\nstarts from the same workspace:
\nremotive studio .
Open Files in the sidebar and click topology.platform.yaml. The topology viewer has\nthree modes, chosen with the segmented control at the top:
BodyCan0 to see the five ECUs on it, or expand BCM to see that it's on both\nbuses. Click a node to open its details, such as channel type, database path and\nconnected ECUs.remotive topology show platform prints.Now open main.instance.yaml. The instance tree has the same channels and ECUs, cut down\nto what the instance runs, and adds instance-level entries such as the bcm behavioral\nmodel. Comparing the two trees side by side is the fastest way I know to check that an\ninstance contains what I meant it to.
Studio opens DBC, ARXML, LDF and Fibex files directly too, by converting them to\n.platform.yaml first. Clicking an ECU extract is a quick way to see what's in it\nbefore you include it anywhere.
Real platforms are rarely one file. They're usually a top-level platform.yaml that\nincludes subsystems:
schema: remotive-topology-platform:0.15
includes:
- ./lighting.platform.yaml
- ./climate.platform.yaml
- ./driver.platform.yaml
Some things that help when there are many of them:
\nlighting.platform.yaml looks right by itself,\nyou've narrowed down where a problem in the combined platform can be.show platform on the file that should\ndefine it. It's often a spelling difference between two databases.platform.yaml includes.remotive topology show reference.This is where the RemotiveLabs team writes short, technical articles: worked examples,\npatterns we use ourselves, and the things that didn't fit in the\ndocumentation.
\nPosts are hands-on and to the point. Expect topics like connecting simulation models to a\ntopology, working with signals from Python, and building dashboards in RemotiveStudio.
\nWhen a post covers something you'll come back to, we link to the matching page in the\ndocs, which is where the reference material lives.
\nMost posts include code you can copy and run:
\nremotive --help
If you build something with RemotiveLabs and want to share it, reach out on\nGitHub.
", "url": "https://developer.remotivelabs.com/blog/2026/05/27/welcome", "title": "Welcome to the RemotiveLabs developer blog", "summary": "Short, technical articles from the people building RemotiveLabs.", "date_modified": "2026-05-27T00:00:00.000Z", "author": { "name": "Ola Nilsson" }, "tags": [] } ] }