Skip to main content

Concepts

Introduction​

RemotiveTopology provides a modular way of describing platforms and instances. The platform describes what is available and the instance describes a specific setup of the platform. Both platforms and instances are modular which means that a large platform can be built by combining smaller platforms. Typically, in the very early stages of development, only a small part of the platform can be instantiated. As development progresses and more integration needs to happen, the smaller instances can be combined into larger integration tests. Since the same tests and behavioral models can be reused across the development lifecyle this avoids the "integration hell" that typically happens in large projects.

Topology platform​

The platform describes which ECUs and services that exist and how they communicate. RemotiveTopology can extract platform information from standard database formats such as ARXML, DBC and Fibex. What information can be extracted depends on each format, for example:

  • ARXML contains all kinds of platform data
  • DBC contains what ECUs are avaiable on a CAN channel
  • Fibex contains what SOME/IP services exists

In RemotiveTopology a platform does not need to be a complete specification of an entire system, instead larger systems can be described by combining platform descriptions of each subsystem. This means that you can use RemotiveTopology even if you have limited information about the entire system, for example with a single DBC file or only one ECU extract.

RemotiveTopology can also be used very early in the design and development process when many details are not yet decided. Simply add the information you have and RemotiveTopology will provide sensible defaults or emulation when needed. For example if ipadresses are not yet decided, RemotiveTopology can assign both subnets and ipaddresses which enables early testing.

ECU​

In RemotiveTopology an ECU represents a computer that is running in the target system. RemotiveTopology is agnostic of how the ECU is implemented, for example if the ECU is using Autosar Classic/Adaptive or using some other architecture.

Channel​

Channels represents how ECUs are communicating, for example using CAN or Ethernet. Examples of parameters:

  • CAN baudrate
  • Ethernet subnet

Channels may have a signaldatabase that specifies how to decode the traffic used in that channel, for example a DBC file that is shared between many ECUs.

Ethernet Channel​

Ethernet requires more information that for example CAN. For an Ethernet Channel you also need to specify:

  • Available SOME/IP services and instances
  • Static socket connections for ethernet PDU communication

This information is typically available in ARXML.

ECU-Channel connection​

An ECU Channel represents the fact that the ECU is connected to the Channel. Different types of channels may have different configuration options, for example:

  • Ethernet: IP address used by the ECU

ECU Channels may have a signaldatabase that specifies how this ECU decodes the traffic on that channel, for example an ECU extract. Notice that this signaldatabase is only needed if there is no database specified on the Channel level.

Topology instance​

In RemotiveTopology the same platform can be instantiated for different purposes. For example

  • to allow development and testing of a single ECU
  • virtualize a large part of the vehicle
  • run test cases using real hardware

Notice that the same platform configuration can be used in all of the above examples. The only difference is how the platform gets instantiated which includes specifying:

  • the subset of the platform to use (what ECUs and channels)
  • settings for hardware connections or how to emulate the hardware, for example what CAN device to map to the logical CAN channels
  • behavioral models
  • what test cases to run

RemotiveTopology can perform a number of checks:

  • all referred files and paths must exist
  • all ECUs and Channels referenced in the instance must exist in the platform

RemotiveBroker​

RemotiveTopology uses RemotiveBroker to handle all communication protocols (CAN, SOME/IP etc). Each ECU will have its own RemotiveBroker with one namespace for every channel it is connected to. Namespaces are named <ECU>-<Channel>.

Behavioral model​

A behavioral model is a way to create a reusable component that emulates the behavior of a real ECU. RemotiveTopology supports different types of models:

  • Python
  • FMU
  • Synopsis Silver

Since a behavioral model emulates an ECU it is often easy to create a separate instance where the behavioral model is replaced with a real ECU. This allows the same test case to run in both instances!

Notice that it is sometimes useful to have different behavioral models in different topology instances depending on what you are trying to test. For example to test error scenarios it might be useful to have a behavioral model that generates incorrect signals.

Mock​

An ECU Mock is a simpler alternative to a Behavioral Model. A common usecase is providing a restbus that emulates an ECU so you can test a device in a realistic bus environment. A mock can also be used to verify that certain signals have been received. The mock is typically controlled by a test case that decides all outputs and optionally verifies inputs to the mock.

If the code controlling the mock gets complicated this is an indication that a Behavioral Model should be created instead.

Container​

RemotiveTopology uses Docker (or Podman) to create an environment which can run virtual components. Typically each ECU and Behavioral Model runs as containers. RemotiveTopology also support custom containers which can be used to run arbitrary components inside the topology. For example this is how test cases can be run using any language and framework that you prefer.