Skip to main content

Modularity

An important feature of RemotiveTopology is the ability to create both modular platforms and instances.

Platform examples​

In this example the platform describes a small subsystem of the vehicle:

The following sections show different ways to describe the same subsystem.

Files per channel​

When creating a platform from DBC or LDF files it can be convenient to start with separate platform files for each channel and then combining them into a subsystem.

drivercan.platform.yaml

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

bodycan.platform.yaml

schema: remotive-topology-platform:0.18
channels:
  BodyCan:
    type: can
    database: ../databases/body_can.dbc

Then combined into sybsystem.platform.yaml

schema: remotive-topology-platform:0.18
includes:
  - ../drivercan.platform.yaml
  - ../bodycan.platform.yaml

Notice that in this example ECUs are automatically derived from the DBC files. It's important that the DBC files agree on the names for all ECUs. Make sure to use DBC files that correspond to the same version of the vehicle.

One file per subsystem​

It's also possible to combine the channel platform files into a larger file and skip the channel specific files. This decision is a matter of taste and what makes sense for your architecture.

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

Files per ECU​

When using ARXML it's common to have ECU extracts which can be combined into a larger platform.

schema: remotive-topology-platform:0.18
includes:
  - ../databases/SCCM.arxml
  - ../databases/BCM.arxml
  - ../databases/DIM.arxml

Notice that in this example both channels and ECUs are automatically derived from the ECU extracts. It's important that the ECU extracts agree on naming and other information, otherwise there are validation errors. Make sure to use ECU extracts that correspond to the same version of the platform.

Also notice that it's often useful for testing and debugging purposes to provide a signal database that covers the entire channel, e.g. provide a DBC file for each CAN channel. This way you can decode all messages on a single topology-namespace.