Skip to main content

Visualizing a topology, platform and instance

· 5 min read

When a topology grows past a handful of files, it gets hard to say what's actually in it. Which ECUs does that DBC bring in? What does the instance run in the end? This post walks through a small example and shows two ways to see the answer: remotive topology show in the terminal, and the topology viewer in RemotiveStudio.

The example topology​

We start with a platform that has two CAN channels, each described by a DBC file. DBC files don't say which channel they describe, so the platform file names the channels and points each one at its database:

# 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: SCCM and BCM are on DriverCan0, and BCM, DIM, FLCM, RLCM and GWM are on BodyCan0. BCM sits on both buses.

On top of that we write an instance, which says which part of the platform to run. Here we want BCM with a Python behavioral model, and FLCM as a mock:

# 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: {}

Looking at it from the terminal​

Before opening any UI, I like to ask the CLI what it sees. Both files live in topology/, next to databases/ and ecus/. Set up a workspace at the root of the project first, so relative includes like ../databases resolve the same way from every subfolder:

cd my_project
remotive topology workspace init

Then show the platform:

remotive topology show platform topology/topology.platform.yaml

This prints the platform as platform.yaml, with everything the DBCs added filled in. Each ECU lists the channels it's connected to, and each ECU channel gets a database too, because that's the database the ECU uses to decode signals. If an ECU name isn't what you expected, 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 were applied. In our case, SCCM, DIM, RLCM and GWM are gone. BCM keeps both channels, because by default an ECU gets every channel it's connected to. FLCM's mock covers every channel FLCM is on, which here is just BodyCan0.

A few options are handy here:

  • --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 useful if you want to diff the resolved instance between two branches.

Opening it in RemotiveStudio​

YAML is precise, but a tree is quicker to read. RemotiveStudio comes with RemotiveCLI and starts from the same workspace:

remotive studio .

Open Files in the sidebar and click topology.platform.yaml. The topology viewer has three modes, chosen with the segmented control at the top:

  • Tree view shows the platform as two top-level groups, Channels and ECUs. Expand BodyCan0 to see the five ECUs on it, or expand BCM to see that it's on both buses. Click a node to open its details, such as channel type, database path and connected ECUs.
  • YAML view shows the resolved topology, with includes merged. It's read-only, and roughly what remotive topology show platform prints.
  • Signal view is a searchable table of every frame in the topology's CAN and LIN databases. Click a frame to see its signals, with units, min and max values, receivers and named values.

Now open main.instance.yaml. The instance tree has the same channels and ECUs, cut down to what the instance runs, and adds instance-level entries such as the bcm behavioral model. Comparing the two trees side by side is the fastest way I know to check that an instance contains what I meant it to.

Studio opens DBC, ARXML, LDF and Fibex files directly too, by converting them to .platform.yaml first. Clicking an ECU extract is a quick way to see what's in it before you include it anywhere.

Tips for larger platforms​

Real platforms are rarely one file. They're usually a top-level platform.yaml that includes 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:

  • Show each subsystem on its own first. If lighting.platform.yaml looks right by itself, you've narrowed down where a problem in the combined platform can be.
  • Use the tree view's search bar instead of expanding everything. "Collapse all" helps when you've lost track.
  • Studio doesn't pick up edits to topology files until you reload the browser tab. The CLI always reads the files fresh, so it's the better choice while you're editing.
  • If a command complains about a missing ECU, run show platform on the file that should define it. It's often a spelling difference between two databases.

Where to go next​

About the author

Filip Åhfelt

Works on RemotiveStudio, mostly on how topologies and signals are visualized. Likes making a complicated network fit on one screen.