ARXML

This document describes how ARXML fields are mapped to RemotiveLabs concepts such as RemotiveTopology platform and how messages (e.g. frames)are encoded and decoded.

ARXML is a huge standard that covers several different aspects of automotive development. RemotiveTopology ARXML support only covers what's necessary to encode/decode messages and what's necessary to implement virtual ECUs as Behavioral Models or Mocks. Typically this is in the form of ECU extracts, but RemotiveTopology also supports System Extracts.

RemotiveTopology intentionally simplifies the names used in ARXML, e.g. instead of using hierarchical paths (like "A/B/C") to reference specific elements, RemotiveTopology simply use the SHORT-NAME ("C") with an implied context. The goal is to make the names more human friendly and easier to reason about.

Platform

CAN

Channel name: CAN-CLUSTER

LIN

Channel name: LIN-CLUSTER

Ethernet

Channel name: ETHERNET-PHYSICAL-CHANNEL

note

Not using ETHERNET-CLUSTER since there might be several VLANs on the same network, see below.

VLAN

Different VLANs share the same ETHERNET-CLUSTER which is available as cluster_name property on the channel. When Docker adds a VLAN network to a container, RemotiveBus creates, or reuses, a bridge network interface named by host_bridge_device, exposes that bridge to the container, and creates a VLAN interface on top of it. The data flows like this:

Notice that it's possible to override the host_bridge_device. When the cluster name is too long and can't be used as a device name, you must specify this manually.

Encode/decode

The following sections go into detail about how RemotiveTopology frame and signal names map to ARXML. This isn't intended for most users, but only if you need a detailed in depth understanding of the mapping to ARXML. If you are familiar with ARXML you also know that these diagrams skip some wrapper elements.

note

If you require a different mapping, feel free to contact support@remotivelabs.com.

Shared signals

CAN, LIN, and Ethernet PDUs share the same signal mapping.

CAN

LIN

Ethernet

Ethernet PDUs

SOME/IP

SOME/IP services are read from the PROVIDED-SERVICE-INSTANCE elements of each ETHERNET-PHYSICAL-CHANNEL. Each service instance maps to a set of frames, one per event, and two per method (request and response). Frames are named <service>.<Type>.<operation>, where Type is Event, Request or Response.

A SOME/IP frame is identified by service id, method id, instance id and message type, not by a single numeric id. The method id comes from the lower 16 bits of HEADER-ID.

Service

Events

Event groups aren't exposed in the RemotiveLabs APIs. Instead, this is handled automatically by mapping the event to the first event group it's part of.

• Frame name: <service>.Event.<event>
• Signal name: <service>.Event.<event>.<parameter>
• PORT-PROTOTYPE is either an R-PORT-PROTOTYPE (REQUIRED-INTERFACE-TREF) or a P-PORT-PROTOTYPE (PROVIDED-INTERFACE-TREF).
• A TRANSFER-PROPERTY of TRIGGERED-ON-CHANGE or TRIGGERED-ON-CHANGE-WITHOUT-REPETITION means the current value is sent to a client when it subscribes.
• If the same event is in more than one event group, it becomes one frame that belongs to all of those event groups. Support for this is limited.

Methods

Methods come from the routing groups that the PROVIDED-SERVICE-INSTANCE references directly. Only PDU-TRIGGERING elements whose I-PDU-PORT has COMMUNICATION-DIRECTION set to IN are used.

Each method maps to two frames:

Frame	Parameters	Meta signals
<service>.Request.<method>	Arguments with DIRECTION=IN	Meta.SessionID, Meta.ClientID, Meta.MessageType
<service>.Response.<method>	Arguments with DIRECTION=OUT	Meta.SessionID, Meta.ClientID, Meta.ReturnCode

• Signal name: <service>.Request.<method>.<parameter>, <service>.Response.<method>.<parameter>
• Meta signal name: <service>.Request.<method>.Meta.SessionID etc.
• Meta.ReturnCode has named values for the standard SOME/IP return codes, such as E_OK and E_NOT_OK. Errors from POSSIBLE-ERROR-REFS are added to these and override standard codes that have the same value.

A TRIGGER-TO-SIGNAL-MAPPING can also be used instead of a CLIENT-SERVER-TO-SIGNAL-MAPPING. Then the method name is the SHORT-NAME of the TRIGGER and the method has no parameters.

Data types

Parameter types are resolved from the TYPE-TREF of the VARIABLE-DATA-PROTOTYPE or ARGUMENT-DATA-PROTOTYPE. Nested types make nested signal names.

Application data type	Signal name	Notes
APPLICATION-PRIMITIVE-DATA-TYPE	<parameter>	Size and encoding come from the BASE-TYPE of the IMPLEMENTATION-DATA-TYPE mapped in the DATA-TYPE-MAPPING-SET. A COMPU-METHOD with text values gives the signal named values.
APPLICATION-RECORD-DATA-TYPE	<parameter>.<element>	One signal per APPLICATION-RECORD-ELEMENT, using its SHORT-NAME.
APPLICATION-ARRAY-DATA-TYPE	<parameter>[0], <parameter>[1], and so on	One signal per element, up to MAX-NUMBER-OF-ELEMENTS.

For example, a record parameter Position with elements Lat and Long in the event VehiclePosition of the service Navigation gives the signals Navigation.Event.VehiclePosition.Position.Lat and Navigation.Event.VehiclePosition.Position.Long.

The DATA-TYPE-MAPPING-SET is found through the software component that the port belongs to. If the file only has one DATA-TYPE-MAPPING-SET, that one is always used.