Instantiating topology

To run a topology you need to create an instance file (.instance.yaml) that describes what parts of the platform you want to run in your virtual environment. The instance also specifies how each ECU is implemented, how channels connect to hardware, what tests to run and so on.

Relative paths in instance and platform files are always relative to the file that contains the path, not to the directory where you run commands.

tip

To understand how a topology is instantiated you can use

remotive topology show instance <filename>

This shows only the parts of the platform that are instantiated and any defaults that have been applied.

See full topology schema for details. Also make sure to setup your editor to use schema validation, see installation instructions.

Choosing what to run

Given a platform, mytopology.platform.yaml:

schema: remotive-topology-platform:0.18
channels:
  DriverCan:
    type: can
    database: ../databases/driver_can.dbc

  BodyCan:
    type: can
    database: ../databases/body_can.dbc

The channels are defined in the platform file, while the ECUs and how they're connected come from the DBC files, see Using DBC. This gives the following platform:

In mytopology.instance.yaml you specify both what platform to use and which ECUs to instantiate:

schema: remotive-topology-instance:0.18

platform:
  includes:
    - ./mytopology.platform.yaml

ecus:
  BCM:

By default all channels that are connected to the instantiated ECUs are instantiated. This means the resulting topology is:

Only the ECUs listed in the instance are instantiated. All the other ECUs in the platform are left out.

Choosing channels

You can optionally specify a subset of channels for an ECU. For example, this only includes a single channel:

schema: remotive-topology-instance:0.18

platform:
  includes:
    - ./mytopology.platform.yaml

ecus:
  BCM:
    channels:
      DriverCan:

This results in the following topology:

This is rarely needed, but can be useful when testing an exceptional scenario, for example how BCM behaves when one of its buses isn't available.

Next steps

Goal	Read
Give an ECU behavior, mock it, run a custom container or mark it as hardware	Implementing ECUs
Use SocketCAN, connect to CAN hardware or run CAN on macOS	CAN networks
Set a LIN schedule table or connect to LIN hardware	LIN networks
Use VLANs, bridge to a physical network interface or set IP addresses on Ethernet	Ethernet networks
Passively observe Ethernet traffic in tests	Test access points (TAP)
Run tests or other tools inside the topology	Test and tool containers
Set RemotiveBroker version, license, Docker images or registry	Instance settings
Build and run the topology	Running a topology
Inspect the topology visually	RemotiveStudio