Implementing ECUs

By default RemotiveTopology instantiates each ECU as a RemotiveBroker. The RemotiveBroker allows you to communicate as the ECU, for example using the correct IP address on a VLAN or using a CAN device. You decide what behavior the ECU should have, or replace RemotiveBroker with your own container.

Option	Use when	Runs as
Behavioral model	You want a reusable component that emulates the behavior of a real ECU	RemotiveBroker and a model container
Mock	You need an ECU that sends its cyclic signals, for a realistic bus	RemotiveBroker and a mock
Container	You already have an implementation that can be containerized	Your container instead of RemotiveBroker
External	The ECU runs as hardware or in a different runtime	Nothing, managed by you

Behavioral models

A behavioral model is a reusable component that emulates the behavior of a real ECU. It can receive and send messages. Behavioral models are typically written using the RemotiveTopology framework.

A behavioral model runs in its own container, next to the RemotiveBroker of the ECU, and communicates with the channels through that RemotiveBroker. To instantiate a behavioral model, add the model to its ECU. An ECU can have multiple models, but each model must have a unique name.

ecus:
  BCM:
    models:
      bcm:
        type: container
        container:
          build:
            dockerfile: ../models/bcm/Dockerfile
          command: python -m bcm

The container properties are described in the container schema. They mirror the service properties in Docker Compose. See the RemotiveCar example for complete behavioral models.

Mocks

A mock is a simpler alternative to a behavioral model. It automatically sends the cyclic signals of an ECU, without any other behavior. A common use case is to fill the bus with the traffic from the ECUs around a device, so you can test the device in a realistic bus environment.

A mock starts out by sending the default value of all cyclic signals where the ECU is the sender. Your test cases, or other code, can then control the values to simulate different scenarios.

By default a mock is created for all channels that the ECU is connected to:

ecus:
  FLCM:
    mock: {}

You can also specify what channels you want to mock:

ecus:
  FLCM:
    mock:
      channels:
        BodyCan:

Combining mocks and behavioral models

An ECU can have several behavioral models, sometimes combined with a mock. This is common for larger ECUs that host several applications (software components). Each application can then have its own model, while the mock sends the cyclic signals of the applications that aren't implemented yet.

For example, a BCM where the exterior light and wiper applications have their own models, while a mock sends the cyclic signals of the rest of the ECU:

ecus:
  BCM:
    models:
      exterior_light:
        type: container
        container:
          build:
            dockerfile: ../models/exterior_light/Dockerfile
          command: python -m exterior_light
      wiper:
        type: container
        container:
          build:
            dockerfile: ../models/wiper/Dockerfile
          command: python -m wiper
    mock: {}

Each model must have a unique name within the ECU. The models and the mock can all run on the same channels.

Containers

Instead of RemotiveBroker you can use a custom container. This allows you to run any code as the ECU.

A common use case is to run the device under test this way. By building a virtual version of the production code into a container, you can test it in the topology together with the other ECUs, without hardware.

For example, to use a vsomeip implementation of an ECU:

ecus:
  GWM:
    container:
      build:
        dockerfile: ../vsomeip.dockerfile
      volumes:
        - ../config:/config_mapped
      working_dir: /vsomeip/build/examples
      command: "sh -c ./notify-sample"
      environment:
        - VSOMEIP_CONFIGURATION=/config_mapped/vsomeip-udp-service-ecu-a.json
        - VSOMEIP_APPLICATION_NAME=service-sample
        - VSOMEIP_LOGLEVEL=debug

The container properties are the same as for behavioral models, see the container schema.

The difference from a behavioral model is that the container replaces RemotiveBroker. The container is connected directly to all ECU channels according to the platform. For example, on an Ethernet channel the container gets the IP address of the ECU.

The channel instance decides the name of each network interface inside the container. The default name depends on how the channel is instantiated, but you can always set it explicitly, for example with device for channels using the RemotiveBus driver. See CAN, LIN and Ethernet networks.

External ECUs

An external ECU plays a part in the instantiated topology, but runs separately and isn't controlled by the topology, for example as hardware or in a different runtime. Defining it as external makes RemotiveTopology aware of it without trying to manage it.

ecus:
  FLCM:
    external: {}

Since the instantiated ECUs decide which channels are instantiated, an external ECU also affects which channels are part of the topology.

note

Marking ECUs as external is required to be able to use TAP namespaces that reference an external ECU.

Namespaces

When working with the RemotiveTopology framework, for example in behavioral models, mocks or test cases, you refer to namespaces. A namespace represents how an ECU sees a channel and is named <ECU>-<Channel>, for example BCM-DriverCan.

To list the available namespaces, start the topology and ask the TopologyBroker, which is forwarded to port 50051 on your host:

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

ECU channel configuration

By default an ECU is connected to all channels according to the platform. You can choose a subset of channels for each ECU.

Some channel types also have optional configuration per ECU.

Ethernet

When instantiating a RemotiveBroker-based ECU connected to Ethernet you can control which sockets and SOME/IP services are instantiated. By default all sockets and services belonging to the ECU according to the platform are instantiated. These settings only affect ECUs that are instantiated using RemotiveBroker.

ecus:
  BCM:
    channels:
      BodyEth0:
        config:
          type: ethernet
          sockets:
            - BCM_socket1
            - BCM_socket2
          someip:
            provided_service_instances:
              - BCM_service1
            consumed_service_instances:
              - GWM_service2

sockets - which sockets (ports) the ECU opens.
provided_service_instances - which SOME/IP service instances the ECU provides.
consumed_service_instances - which SOME/IP service instances the ECU consumes. Only these services need to be provided by other ECUs in the instance.

VLAN trunk interface

When an Ethernet channel uses the remotivebus driver, the ECU gets both a trunk interface and a VLAN subinterface. For containers that need to handle VLAN tagging themselves and only require the trunk network interface, creation of the VLAN subinterface can be skipped:

ecus:
  BCM:
    channels:
      BodyEth:
        config:
          type: ethernet
          create_vlan_interface: false

Behavioral models​

Mocks​

Combining mocks and behavioral models​

Containers​

External ECUs​

Namespaces​

ECU channel configuration​

Ethernet​

VLAN trunk interface​