Skip to main content

A basic restbus, watched from a dashboard

· 5 min read

An ECU on its own rarely behaves the way it does in the car. It expects to hear its neighbors: periodic frames that say the ignition is on, the speed is zero, the doors are closed. This post sets up a basic restbus that sends those frames for you, and a RemotiveStudio dashboard where you can see them and change values while everything runs.

What a restbus is for​

A restbus simulates "the rest of the bus": every frame your device under test expects from ECUs that aren't there. Most of these frames are cyclic, so the simulation has to keep sending them at the right cycle time, or the device starts logging timeouts and falling back to safe states.

In RemotiveTopology this usually starts with an ECU mock. A mock is the simpler alternative to a behavioral model: it doesn't decide anything on its own, it just provides a restbus that emulates the ECU, and something else (often a test case, today it's us) decides what it sends. If the code that controls a mock gets complicated, that's a sign it should become a behavioral model instead.

Setting up the restbus​

Start from a platform with a CAN channel, and instantiate the ECU you want to stand in for with a mock. The instance docs use a body controller on two CAN buses; mocking it on just one of them looks like this:

schema: 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. Then generate the topology and start it in interactive mode, so it keeps running while you work, as described in Running 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 of a channel is a namespace named <ECU>-<Channel>, so here it's BCM-DriverCan0. If you're unsure, list them:

remotive broker signals namespaces --url http://localhost:50051

Now tell the broker which frames to send. The remotive broker restbus commands follow a simple workflow: add, start, update, and stop or reset. Pick a frame from your signal database (the signal view in 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 it out to use the database value. add --start registers and starts in one go.

Building the dashboard​

Start RemotiveStudio on the workspace that holds your topology files, as in Getting started:

remotive studio .

The dashboard needs a running topology to connect to; without one it shows "RemotiveTopology unavailable". Create a dashboard from the Topology sidebar panel, then use Add Panel to add panels. For a restbus, three are useful:

  • Frame distribution shows which frames arrive and how often, so you can see at a glance that the restbus is running and at roughly the cycle time you asked for.
  • Trace shows each frame as it arrives, with its raw bytes, and the signal values when you expand a row.
  • Time series plots the signals you select, which is where you'll see your changes.

Use the signal selection button to pick signals for the time series panel. A new dashboard is a draft until you click Save As; it's then stored as a .dashboard.json file in your workspace, so you can commit it next to the topology and open it again from the Files sidebar.

Changing values while it runs​

With frames flowing, change what the restbus sends. update sets the values it emits from now on; give several comma-separated values and the restbus loops over them. For 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 series panel follows along as soon as the new values go out, and the trace panel shows what changed in the raw bytes. To pause, run stop; the configuration stays, so start picks up where you left off. remove --frame drops a single frame, and reset clears everything for a namespace.

Here the dashboard is the place you watch, and the terminal next to it is where you turn the knobs. The same restbus can be controlled from code, too: the RemotiveTopology framework is a Python library for writing test cases and behavioral models against the same namespaces, which is where to go once a sequence of update commands starts to feel like a script.

About the author

Ola Nilsson

Builds the RemotiveLabs developer experience, from the docs and this blog to the tools around them. Usually found turning a support question into a guide, a guide into an example, and an example into a test that runs in CI. Has opinions about keyboard shortcuts.