RemotiveBroker Configuration
The RemotiveBroker configuration is defined in a JSON schema, which specifies the structure and requirements of the configuration file interfaces.json
. This file configures all interfaces that the broker will operate on, allowing for a flexible setup of the following interfaces:
- CAN
- CAN-FD
- UDP (CAN-via-UDP)
- LIN
- FlexRay
- virtual
- scripted
The complete schema can be found here.
The interfaces are the most central and critical part of the RemotiveBroker configuration, defining how the broker interacts with various communication protocols and devices. Each interface type specifies a unique way to handle signals and data, making it possible to configure a wide range of communication scenarios.
Interface configuration (namespaces)
In the RemotiveBroker configuration, interfaces are configured as namespaces. A namespace typically represents a logical name for a bus, for example a can bus or a SOME/IP network. In order to decode the messages, the namespace must be configured with a signal database that contains all frames relevant for that bus. A namespace can also represent a partial view of the bus from a single ECU perspective, i.e. it would contain only the frames sent and received by a particular ECU. This means that a namespace is paired with the limited ECU extract relevant only for the specified ECU.
Each namespace is defined as an element within an array called chains
. This array holds the configurations for all the namespaces (interfaces) that the broker will manage.
The following properties are required for all types of namespaces (interfaces):
namespace
: This property assigns a unique name to this namespace. This name must be referenced when interacting with signals on this namespace.type
: Specifies the type of interface, such asscripted
,virtual
,can
,canfd
,udp
,lin
, orflexray
. Each type has very different behavior and may require additional configuration parameters.database
: Indicates the path to the signal database file. The type of database file (e.g., .dbc, .arxml, .ldf, .xml) varies depending on the interface type. This file contains the signal definitions which are used to encode/decode all signals.
For a detailed view of the chains
see JSON schema for RemotiveBroker configuration. This resource provides comprehensive information about all the properties, definitions, and structure required to configure your RemotiveBroker interfaces.
** When naming a namespace, use names that reflect the logical structure, for example what the bus is used for. Avoid physical device names as these depend on how the RemotiveBroker is connected and may change as different setups are done. By using logical names all code and configuration remain stable over time.
Protocol interface
The types can
, canfd
, udp
, lin
and flexray
are protocol interfaces. They enable you to communicate with the underlying protocol through the broker.
Scripted interface
A scripted
interface offers the ability to dynamically compute and manage signals using custom scripts. Scripted signals allows the RemotiveBroker to provide signals using VSS or signals intended for Android. A scripted signal is generated on-the-fly according to the logic defined in a script, often based on signals available in other namespaces.
Virtual interface
A virtual
interface serves as a backbone communication channel on the broker, enabling message exchanges between different clients connected to the broker. For example the virtual interface can be used to control the behavior of ECU mocks.
Reflectors
Reflectors in the RemotiveBroker configuration are used to set up traffic "bouncing" mechanisms between different namespaces. Each reflector configuration specifies a source and a destination namespace, enabling the automatic forwarding of signals from the source to the destination. This feature is particularly useful for replicating signals across multiple interfaces or systems, ensuring consistent data flow and synchronization. Additionally, reflectors can include a list of frames to exclude from this bouncing process, allowing for precise control over which signals are reflected. This flexibility makes reflectors a powerful tool for managing complex network configurations and ensuring seamless communication within the RemotiveBroker setup.
Distributed Broker Mode
The distributed broker mode in RemotiveBroker enables multiple broker instances to operate in a coordinated manner across a network. This setup is particularly useful for large-scale systems where different segments of a network need to communicate seamlessly. The configuration for the distributed broker mode includes specific properties that define the node's identity node_name
.
Configuring the broker for your project
The Configuration Page in RemotiveBrokerApp provides two main functionalities to help you set up and manage your configurations efficiently
- Configuration Wizard (Only support for CAN/CANFD)
- Upload a configuration folder
The configuration page looks like this:
Configuration Wizard (Only support for CAN/CANFD)
Steps to Use the Configuration Wizard:
- Navigate to the Configuration Page
- Select the "Configuration Wizard" option
- Follow the on-screen instructions to specify your settings
- Review and confirm your configuration
- Reconfigure the broker or download the created file
Configuration folder
A configuration folder is a folder which contains an interfaces.json
and other configuration files such as signal databases. All paths in the interfaces.json
file shall be relative to the interfaces.json
file.
Given this structure
my-configuration/
├── databases/
│ ├── can.dbc
│ └── can.arxml
└── interfaces.json
then the interfaces.json
could look like this
{
"chains": [
{
"namespace": "my_can0",
"type": "can",
"database": "databases/can.dbc",
"device_name": "can0"
},
{
"namespace": "my_can1",
"type": "can",
"can_physical_channel_name": "/foo/bar",
"database": "databases/can.arxml",
"device_name": "can1"
}
]
}
Steps to Upload a Configuration Folder
- Navigate to the Configuration Page
- Click on the "Configuration" tab in the top banner
- Select the "Browse" button to open a file dialog
- Locate and select your configuration folder
- Confirm the upload to apply your custom settings
Once uploaded, the RemotiveBroker will verify that the configuration is valid. If not, please verify that your interfaces.json
and the relative database paths are correct.
Examples
CAN example
Any SocketCAN-compatible USB dongle can be added when physical interfaces are required. Amongst others,
FlexRay example
Write is currently not supported out of the box and requires customizations.
LIN example
Connect a secondary USB to ETH adapter to the host. Here you can connect a single LIN transceiver box alternatively a switch with a number of LIN transceivers. Each LIN transceiver is identified and configured according to its unique device_identifier.
Scripted example
A scripted namespace remaps signals from other namespaces, which can involve simple renaming or more complex transformations. Here is an example of what an interface.json might look like: