Describing the platform

The platform describes which ECUs and services that exist and how they communicate. In RemotiveTopology you can describe your platform in a number of different ways:

• An ARXML ECU extract
• An ARXML system description (contains all ECUs)
• A DBC file describing a CAN channel and all ECUs on that channel. Notice that DBC does not include which channel it is describing!
• RemotiveTopology platform.yaml to add addional information or combining other files

Normally we recommend using your existing platform databases, such as ARXML, DBC, FIBEX etc. However, sometimes these files are not yet available or are missing some data. In those situations you can add additional platform information using platform.yaml files.

Showing a platform

The easiest way to understand what a file contains is to

$ remotive-topology show topology <file>

This will show the platform contents as platform.yaml and includes all channels and ECUs described by the file.

Combining platforms

Using ARXML

ARXML contains channels, ECUs and how the ECUs are connected to the channels. Simply add ARXML as includes:

schema: remotive-topology-platform:0.4
includes: 
 - ../databases/my-ecu-a.arxml
 - ../databases/my-ecu-b.arxml

Notice that all included files must be compatible! This means that the referenced ECUs and channels must have the same names and settings. Ensure that the files are from the same version.

Using DBC

DBC only contains ECUs and does not contain the channel name. This means that you must specify what channel should use the DBC using the database field:

schema: remotive-topology-platform:0.4
channels:
  DriverCan0:
    type: can
    database: ../databases/driver_can.dbc
    can_physical_channel_name: DriverCan0

This will automatically add the ECUs that are part of the DBC and connect these to the channel, that is:

$ remotive-topology show topology topology/simple.platform.yaml
---
channels:
  DriverCan0:
    can_physical_channel_name: DriverCan0
    database: .../databases/driver_can.dbc
    type: can
ecus:
  BCM:
    channels:
      DriverCan0:
        database: .../databases/driver_can.dbc
  SCCM:
    channels:
      DriverCan0:
        database: .../databases/driver_can.dbc
schema: remotive-topology-platform:0.4

Notice how database is also set for the ECU channels. The reason is that these ECUs will use that database to decode signals. Sometimes it is useful to only allow an ECU a partial view of the channel. To do this you can override the ECU channel database.

Using platform.yaml

A key principle in RemotiveTopology is modularity. This means that combining platform subsystems is very easy using includes:

schema: remotive-topology-platform:0.4
includes: 
 - ./lighting.platform.yaml
 - ./climate.platform.yaml
 - ./driver.platform.yaml

Channels and ECUs

Channels define how ECUs communicate with each other.

CAN channel

CAN channels are very easy to add. All RemotiveTopology need to know is that the channel exists:

channels:
  DriverCan0:
    type: can

To define that an ECU is connected to a CAN channel you simply specify that the channel exists on the ECU:

ecus:
  BCM:
    channels:
      DriverCan0:

Ethernet channel

Ethernet channels require more information such as subnet and vlan, but also about the services that are available. See below how different services are specified.

channels:
  MyEth:
    type: ethernet
    subnet: 10.1.0.0/24
    vlan: 2

• subnet is required
• vlan is optional

To define that an ECU is connected to an ethernet channel you must specify the ip address of the ECU:

ecus:
  BCM:
    channels:
      MyEth:
        config:
          type: ethernet
          host: 10.1.0.50

SOME/IP

When using SOME/IP on an ethernet channel the platform should specify:

• all service instances (service_id, instance_id, major_version)
• where the service instance is provided
• optionally where the service instance is consumed

channels:
  MyEth:
    endpoints:
      udp/10.1.0.43:12345:
        provided_service_instances:
          - MyService_instance
      udp/10.1.0.17:12345:
        consumed_service_instances:
          - MyService_instance
    someip:
      services:
        MyService_instance:
          service_id: 1234
          instance_id: 1
          version_major: 1

Notice that the SOME/IP service interfaces must be defined in the signal database in order to know what methods and events exist.

Ethernet PDUs

Ethernet PDUs allow point to point communication and are defined by using a combination of endpoint and named socket connection. The following example specifies that there exists UDP communication between 10.1.0.50:12345 and 10.1.0.51:17000.

channels:
  MyEth:
    endpoints:
      udp/10.1.0.50:12345:
        static_socket_connections:
          SomeService:
            target_host: 10.1.0.51
            target_port: 17000

Notice that the ethernet PDUs must be defined in the signal database in order to decode/encode the messages.