Layered Standard for Network Communication

Automotive CAN, LIN, FlexRay, CAN FD, CAN XL and Ethernet are network technologies that have been applied successfully over many years by all automotive OEMs worldwide. Virtualizing electronic control units (ECUs) and then simulating multiple such virtual ECUs requires connecting them using a virtual version of these network technologies.

This layered standard defines what input and output variables and which FMI 3.0 features are used and how to emulate a transport layer for such network traffic. At this point it should be explicitly mentioned that this layered standard not only relates to automotive buses, but can also be extended to buses from other domains in the future.

There are mainly two base use cases envisioned here:

So that this layered standard can be supported in a variety of FMU importers and other types of simulators three possible communication architectures for bus communication are specified:

This standard allows a highly accurate bus simulation using FMI 3.0 mechanisms. To profit from such accuracy on a system level to predict system behavior, all system simulation components must provide at least that level of accuracy. When focusing on single virtual ECU use cases, such as protocol validation, the accuracy requirements for the rest of the system can be relaxed.

Contrary, on system level, the accuracy of the simulation depends on the accuracy of all its components. These components can be virtual ECUs, plant models, residual bus simulators, data replay components and, of course, the bus simulation. A single low-accuracy component limits the overall system simulation accuracy. The level of detail of these runtime models determine the size of the window for data transmission events. With virtual ECUs using the zero-time execution model ^[2], the time of data transmission can only be determined to be somewhere within the given smallest granularity of the virtual ECU’s internal scheduler. More detailed models, like instruction set simulators or even System-C models of the hardware, can narrow the window for these events significantly. However, current modelling technologies, as of writing this standard, do not allow practical implementations in terms of modelling time and runtime of virtual ECUs that can be used to simulate all realistic bus simulation effects, such as collision and arbitration events.

Conventions used in this document:

In key parts of this document, non-normative examples are used to help understand the standard. To keep the standard itself brief, the FMI LS BUS Implementer’s Guide was created. It contains further technical discussions and examples on how to implement certain aspects of the standard for both FMUs and importers. Contrary to the standard, the FMI LS BUS Implementer’s Guide will be a living document, enhanced with further tips and tricks as the FMI community encounters them.

This layered standard currently only refers to the FMI for Co-Simulation (CS). At the current time, Model Exchange (ME) and Scheduled Execution (SE) are not taken into account. All explanations in this document are therefore to be understood in the context of FMI for Co-Simulation (CS).

If triggered output Clocks are used, the importer must ensure to schedule and potentially roll-back FMUs that have advanced their fmi3DoStep past such a (surprising) triggered Clock activation from another FMU. It is strongly recommended to avoid using triggered output Clocks and to instead use time-based Clocks to avoid these complications and potential performance problems. For time-based Clocks, the event times are known before a simulation step is started, and the importer can adapt the next communicationStepSize for all networked FMUs accordingly.

A time-based Clock can be periodic or aperiodic. Both allow defining Bus Communication Points with fixed or variable distances. For a quick overview, the differences between the various time-based Clock types are listed in the following table. For a detailed specification of time-based Clocks please refer to the FMI standard.

[Selecting a suitable intervalVariability for sending Clocks allows the FMU (or better the exporting tool) to balance the accuracy and performance of its network communication:

- While aperiodic Clocks allow very accurate network simulations, frequently entering Event Mode might reduce the network simulation speed.

- Using periodic Clocks and queueing (or even dropping of intermediate) data to be transmitted reduces the number of Event Mode entries and might speeds up the simulation at the cost of simulation accuracy.

- One could use (structural) parameters to define the accuracy of aperiodic Clocks, allowing control of the simulation accuracy and performance with the same FMU.

Note: The statements regarding aperiodic and periodic Clocks and their impact on performance should be understood as general tendencies rather than universally valid truths, as other aspects such as baud rates and expected bus loads must be taken into account for a more precise estimate.]

This standard considers three possible communication architectures for bus communication. It should be explicitly noted at this point that the FMUs for integration in the respective use case do not necessarily have to be different, so that the same FMU can be integrated across all three communication architectures. The interface of the FMU to the importer is always the same, but a different subset of the features is actually used. Depending on the abstraction layer (Physical Signal Abstraction or Network Abstraction) and communication architectures, the feature set of the FMI-LS-BUS can vary, so that certain features are only available in specific combinations.

Physical Signal Abstraction allows an idealized exchange of unit-based variables between FMUs. Variables representing these physical signals are clocked to reflect the bus timing aspects of the information flow. Changes to these clocked variables always reach the destination. An FMU can take on specific roles here. This role can be a Bus Simulation FMU or an importer with bus simulation support on one side, and Network FMUs (e.g., virtual ECUs) on the other side (see System Compositions). To allow importers an easy distinction between these FMU roles, for Bus Simulation FMUs the attribute isBusSimulationFMU shall be set to true in the Manifest file.

The figure below shows an example architecture of a Physical Signal Abstraction. The signals (Signal 1…​8) are modeled as clocked variables of a specific type. The corresponding signals are structurally combined using Protocol Data Units (PDUs), which in turn are assigned to frames. The PDU and frame structuring is done via terminals (PDU A, B, C and Frame X, Y). The respective variables are connected to a Bus Simulation, which emulates them according to their own needs for e.g. according to accuracy.

To define the Physical Signal Abstraction layer, signal variables are used.

A signal variable carries the physical value of a network signal normally packaged inside a PDU or frame. The unit definition of the variable must match the one defined in the network description file, if provided.

Each network signal must be listed as a Terminal Member Variable of its corresponding PDU terminal.

In case multiplexed signals are present in a frame/PDU/container PDU: All signals/PDUs are present, but only the active signal according to the multiplex switch signal contains a valid value, all inactive variables have undefined values. [These values could even be outside their specified min-max range without fault.]

All signal variables are clocked to indicate when they have been sent/received, see Section 4.3.

In order to use FMU input and output variables as transport layer for networks, Clocks are used to indicate the timing. The sending FMU uses a Clock to indicate the transmission of the corresponding frame or frames.

The Clock type (periodic or aperiodic) is defined by the sending FMU.

The Clocks of a receiving frame shall be triggered Clocks if they are to be driven by the respective Clock of the sending frame.
Alternatively, Clocks of a receiving frame can be periodic Clocks matching the relevant Clock of the sending frame, which causes them to be scheduled for the same time instances. [This may allow for more efficient simulation in the case that there exists a more or less static communications schedule, and more detailed simulation of timing variation is not needed.]

Signal variables belonging to frame BusName.FrameName must share the same causality (input or output).

Standardized network description files may optionally be shipped with each FMU to describe properties of signals and frames, such as signal units, frame composition and trigger conditions. If these network description files are shipped, they must be placed into the /extra/org.fmi-standard.fmi-ls-bus folder. DBC, LDF, Fibex and ARXML files are allowed, e.g., Powertrain.dbc. The case-sensitive root name of the network description file must be used as network identifier in the Bus Terminal type and prefix in the variable names.

Multiple files can be specified, each one defining one network used by the FMU. This standard does not support composing one network from multiple network description files, even if using internal include mechanisms, it rather enforces the rule: One network - one file.

It is recommended to use ARXML over DBC files for CAN whenever possible, because the DBC standard lacks some key frame/PDU properties that were added only later using non-standard extensions with different dialects in use.

This document does not address potential open points of these description formats, it is assumed that such ambiguities will be handled elsewhere (e.g., message timing in the DBC format). This document does not address IP protection or copyright issues. These are technical and legal issues that need attention from standardization bodies of the referenced description formats, tool vendors and end users.

This section defines terminals for Physical Signal Abstraction.

The following excerpts from files are used throughout this document as examples and should illustrate how the different concepts relate.

Physical Signal Abstraction maps several network protocols onto co-simulation variables as transport layer simulating in many ways an ideal network. Such an ideal network differs from physical networks in the following ways (and potentially others):

The Network Abstraction allows the implementation of virtual bus drivers within FMUs on the level of the hardware abstraction layer. Exchanging data in terms of the Layered Standard Bus Protocol via variables grouped by a dedicated Bus Terminal (see Variables), allows the implementation of bus simulations in a wide range from idealized up to detailed behavior, including e.g., timing, arbitration, error, status and other effects. During simulation, the network communication is controlled by send and receive Bus Operations. Based on these operations, FMUs implementing this layered standard have to react depending on their role as specified in this document. This role can be a Bus Simulation FMU or an importer with bus simulation support on one side, and Network FMUs (e.g., virtual ECUs) on the other side (see System Compositions). To allow importers an easy distinction between these FMU roles, for Bus Simulation FMUs the attribute isBusSimulationFMU shall be set to true in the Manifest file.

In general, the Layered Standard Bus Protocol is bus-type-specific, but there are some similarities among different bus types. Bus communication often follows a Transmit/Confirm pattern, where a Network FMU sends a Transmit operation containing the network message as payload. Depending on the System Composition, the importer forwards the Transmit operation either directly to receiving FMUs or to a dedicated bus simulation. The Bus Simulation then might delay the transfer of the Transmit operation to the receiving FMUs to simulate timing behavior, before sending a bus-specific Confirm operation back to the sending FMU.

The point in time at which FMUs will (potentially) send new network messages can be given to the importer in advance with the proper Clock type. Based on these times, the importer has to calculate the next communicationStepSize for all networked FMUs. For simulating bus communication with timing effects, the FMUs should set the Co-Simulation attribute canHandleVariableCommunicationStepSize = "true".

For simplification reasons or if a detailed bus simulation is not desired, fixed-step size FMUs can also be used with Network Abstraction. However, depending on the chosen simulation step-size, delay effects of the bus simulation have to be taken into account. Compositions with fixed-step size and variable-step size FMUs require the decoupling of the Bus Simulation logic and the Bus Simulation timing. This decoupling is realized by queuing Tx/Rx Bus Operations inside the Bus Simulation as well as queuing Tx Bus Operations inside Network FMUs. By queuing Bus Operations, System Compositions with variable-step size FMUs as well as fixed-step size FMUs can be simulated together without affecting each other.

The Layered Standard Bus Protocol allows the transmission of Bus Operations between FMUs in binary form via Clocks and clocked variables (see Variables). Depending on their role (Network or Bus Simulation), FMUs have to respond to received operations as specified by this layered standard. Operations and the reaction on receipt are bus-type-specific and therefore described in the bus-specific chapters. However, the description follows a uniform structure and consists of two parts, an overview table and a detailed description of all operations.

The overview table represents the binary format of operations and is structured as follows:

The following table shows an example of an operation definition. The name is OperationName and has the OP Code 0x01. The operation has three arguments Arg1 (2 bytes long), Arg2_Length (1 byte long), Arg2_Data (<Arg2Length> bytes long), whereby argument 2 and argument 3 form a coherent variable length argument.

Additionally, all operations are described separately in detail in the following structure:

Remarks:

A CAN frame will serve as a concrete example. Sending a CAN frame is represented by the Bus Operation: CAN Transmit. Since the FMI-LS-BUS describes the simulation of network communication above the electrical level, not all content of a CAN frame is relevant. The corresponding argument values ​​do not have to be analogous to those of the original frame representation. Argument values can be transformed, i.e., presented in a different form, for easier use. Figure 7 illustrates the mapping between the FMI-LS-BUS CAN Transmit Bus Operation and a Standard CAN Data Frame. The information that can be mapped directly is shown in green. The yellow representation describes transformed values and the information shown in red is not required/used.

This section explains how layered standard bus protocol operations are sent and received by FMUs using Clocks and clocked variables ^[5].
While Tx Clock and Rx Clock are used for scheduling and time synchronization, Tx/Rx Data Variables are used to carry Bus Operations in binary form.

Both variables (and their corresponding Clocks) must be members of its corresponding Bus Terminal.

A schematic representation of an FMU with a Bus Terminal is shown in the following figure:

For each supported bus type, the Layered Standard Bus Protocol is defined. This chapter describes the operations of the Layered Standard Bus Protocol to enable the simulation of supported bus types.