Layered Standard for Network Communication

This layered standard on top of FMI 3.0, defines how to describe and simulate network signals as input and output variables of an FMU.

[Note: Although the document refers to version 3.0 of the FMI standard, everything described in this document also applies to all subsequent minor versions. For further information on compatibility, see section Versioning and Layered Standards in the FMI 3.0 specification.]

This document is licensed under the Attribution-ShareAlike 4.0 International license. The code is released under the 2-Clause BSD License. The licenses text can be found in the LICENSE.txt file that accompanies this distribution.

1. Introduction

1.1. Intent of This Document

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 world wide. 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:

Physical signal abstraction ("high cut") to simply transport physical signal values between virtual ECUs.
The network properties are largely idealized: infinite bandwidth, zero-delay etc. Signals, groups of signals and their properties (e.g., units) are usually derived from (existing and validated) standard network topology description formats (such as DBC, LDF, Fibex and ARXML).
Network abstraction ("low cut") to realize virtualized bus driver implementations ^[1].
This transport layer emulation allows anything from idealized to more detailed network simulations, including bandwidth restrictions, message arbitration and delays. It forwards the network payloads using binary variables. The "low cut" abstraction layer is meant to allow virtualized bus driver implementations, including feedback from the physical drivers about transmission status or network node states. Since the network abstraction layer is protocol-independent, it can also be used for the simulation of non-automotive control units, e.g., from the field of industrial automation.

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:

Direct Communication: Limited to exactly two FMUs, a common FMU importer that not require any special features for simulating buses, apart from supporting FMI variables, Clocks and terminals can be use to emulate bus communication.
Composition with dedicated Bus Simulation FMU: A separate Bus Simulation FMU is used to simulate the specific bus behavior. Other FMUs that want to emulate bus communication provide and relate network information via this Bus Simulation FMU. This communication architecture can be operated by a common FMU importer and allows complex and detailed bus simulations.
Importer with Integrated Bus Simulation: Works analogously to the Composition with dedicated Bus Simulation FMU architecture, whereby the Bus Simulation FMU is directly integrated into an importer or other simulator.

1.2. System Simulation Effects

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. Focusing on single-virtual-ECUs use cases, such as protocol validation, accuracy requirements for the "rest-bus" 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, rest-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 run-time models determine the size of the window for send-message events. With virtual ECUs using the zero-time execution model ^[2], the time of send-message events 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 (as of writing this standard) modelling technologies do not allow practical (modelling time and run time) implementations of virtual ECUs that can be used to simulate all realistic bus simulation effects (e.g. collision/arbitration events).

1.3. How to Read This Document

Conventions used in this document:

Non-normative text is given in square brackets in italic font: [Especially examples are defined in this style.]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (regardless of formatting and capitalization).

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.

1.4. Remarks

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).

2. Layered Standard Manifest File

This layered standard defines requires the use of a layered standard manifest file and Table 1 shows the content of fmi-ls-manifest.xml.

Table 1. Attribute Details.
Attribute	Namespace	Value	Description
`fmi-ls-name`	`http://fmi-standard.org/fmi-ls-manifest`	`org.fmi-standard.fmi-ls-bus`	Name of the layered standard in reverse domain name notation.
`fmi-ls-version`	`http://fmi-standard.org/fmi-ls-manifest`	`1.0.0-beta.1`	Version of the layered standard. This layered standard uses semantic versioning, as defined in [PW13].
`fmi-ls-description`	`http://fmi-standard.org/fmi-ls-manifest`	`Layered Standard for the simulation of bus communication on a signal or network abstraction based level.`	String with a brief description of the layered standard that is suitable for display to users.
`isBusSimulationFMU`		`true` or `false`	Defines whether the respective FMU is a Bus Simulation FMU or not. The importer may use this information at the time of importing the FMU, depending on which System Compositions the FMUs are integrated into. If `true`, this FMU represents a Bus Simulation FMU. Default: `false`.

An example of a manifest file for this layered standard is shown below:

<?xml version="1.0" encoding="UTF-8"?>
<fmiLayeredStandardManifest
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="../../schema/fmi3LayeredStandardBusManifest.xsd"
    xmlns:fmi-ls="http://fmi-standard.org/fmi-ls-manifest"
    fmi-ls:fmi-ls-name="org.fmi-standard.fmi-ls-bus"
    fmi-ls:fmi-ls-version="1.0.0-beta.1"
    fmi-ls:fmi-ls-description="Layered Standard for the simulation of bus communication on a signal or network abstraction based level."
    isBusSimulationFMU="false"/>

The manifest file shall be stored inside the FMU at the following path: /extra/org.fmi-standard.fmi-ls-bus/fmi-ls-manifest.xml.

3. Common Concepts

Physical signal abstraction ("high cut") and network abstraction ("low cut") layers represent different levels for the exchange of bus messages. Physical signal abstraction focuses primarily on the exchange of signal values, while network abstraction provides a complete way of implementing a virtual bus driver. Depending on the exporting tool, one of the abstraction layers is more "natural" to the FMU, while the other might have to be emulated with additional internal effort or an adapter (FMU) could be used. Importers on the other hand rarely require both abstraction layers for system level compositions, because the engineering tasks define the required level of abstraction for the network communication. FMUs may choose to only support one abstraction layer providing only the corresponding variables. However, for versatility, having FMUs capable of communicating on both abstraction layers is more convenient for users.

[FMUs providing both abstraction layers can deduce from the fmi3Set() and fmi3Get() calls they receive, which abstraction layer the importer is using.]

Since network communication is not continuous but time discrete, FMI 3.0 Clocks are used to indicate when signals and/or frames are sent or received. All signal and frame variables are clocked variables.

FMI 3.0 terminal definitions in the terminalsAndIcons.xml are used to group related variables and present a comfortable opportunity to connect different FMUs between each other. Terminal definitions are used differently within the "high cut" and the "low cut":

Figure 1. Relations between Bus-, Frame- and PDU Terminals.

Variables are referenced in terminals and the memberName attribute indicates how a variable is meant to be used. For the "high cut", variables represent signals and their Clocks. For the "low cut", variables represent transmitted and received bus traffic (memberName = Tx_Data/Rx_Data) and their respective Clocks (memberName = Tx_Clock/Rx_Clock). The causality of Rx_Data variables must be input, whereas the causality of Tx_Data variables must be output. Rx_Clock variables must be triggered input Clocks and are meant to be connected by the importer to the corresponding Tx_Clock variables. A periodic Clock indicates that the FMU can send signals or frames only periodically on a given time raster, while a changing or countdown Clock indicates that the FMU can send signals at varying time steps.

Using Tx_Clocks of different types allows simulations with different timing accuracy and performance. Some Clock types allow the FMU to specify the next send event efficiently and accurately. Hence, the importer will trigger these Clocks according to the Clock specifications as accurately as it can.

[The alternative of using nextEventTime would force epsilon matching of event times.]

For any periodic (fixed-time) sending of messages, multiple message sends fall into one fmi3DoStep. While "high cut" signal variables will miss all but the last value sent, "low cut" frame variables will buffer all payloads inside their value.

If triggered output Clocks are used, the importer must take care 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.

If an FMU represents network nodes that are both sender and receiver of a signal, the receiver role will be removed from the FMU interface to allow the signals to have a unique role as output and the reading of such outputs must be handled internally to the FMU.

[Rationale: The FMI standard requires a variable to be either input or output.]

While the values and semantic of the Clock variables are clear, the binary frame variables are opaque to the importer but have internal structure to implement the transport mechanism of the specific network technology. Frame variables do not just transport the network-specific payload, but also carry protocol-specific status information. Status information allows, for example, the MCAL emulation of a virtual ECU to report back to the COM-stack about success or errors of a send request.

3.1. System Compositions

Overall, 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.

3.1.1. Direct Communication

The first option is to use a common FMU importer. Within this configuration, the FMU importer does not require any special features for simulating buses, apart from supporting FMI variables, Clocks and terminals. The figure below illustrates the direct communication of two FMUs:

Figure 2. Direct communication of two FMUs.

Direct bus communication is limited to exactly two FMUs. The simulation of bus communication between more than two FMUs is not possible in such a naive way. The bus simulation is also only idealized, so that the simulation of bus transmission times or arbitration, for example, is not supported. Such an ideal network differs from physical networks in the following ways (and potentially others):

Network frame arbitration: frames are sent on the wire according to network-specific priority rules.
Here all frames are transmitted at the same time without delay.
Network congestion/bandwidth: too many network frames sent for the bandwidth of the network.
Here the network has infinite capacity.
Protocol functions of higher levels: e.g. CAN request for retransmit is a specific protocol function.
Here such specialties must be handled by a higher layer inside the FMU.
Incoming buffer overflow: when an ECU receives more frames than its buffer can hold.
Here the FMU will receive all frames, regardless of buffer size and would need to handle those limitations internally.

3.1.2. Composition with dedicated Bus Simulation FMU

If more realistic network properties are required, a bus simulation component must be added.

One option is to connect FMUs to a dedicated Bus Simulation FMU. The Bus Simulation FMU is used to simulate the bus behavior and differs depending on the bus type (e.g., for CAN, LIN, Ethernet or FlexRay). For example, it is used to simulate the transmission time or the failure of bus messages. A Bus Simulation FMU must provide enough Bus Terminals for all FMUs that are interconnected via a bus. The implementation of a Bus Simulation FMU can be dynamic or static, potentially generated by a tool. Because the Bus Simulation FMU can provide the described functionality, all FMUs that want to transmit bus messages send their messages to the Bus Simulation FMU. The Bus Simulation FMU can then acknowledge, delay or even reject messages and forwards messages to recipients accordingly. Some features may depend on the abstraction layer that is used. Also in this case, the FMU importer does not require any special features for bus simulation, apart from supporting FMI variables, Clocks and terminals. The figure below shows two FMUs which are connected to a specific Bus Simulation FMU. The total of three FMUs are executed on a common FMI 3.0 importer.

Figure 3. Bus simulation by using a dedicated Bus Simulation FMU.

This type of communication allows the simulation of all bus features, such as arbitration or the simulation of timing. The supported bus features cannot be specified explicitly in the case shown, but refers to a specific implementation of a Bus Simulation FMU and are depending on the requirements of the bus simulation. This communication architecture enables complex bus simulations to be implemented on lightweight FMU importers. An n:m bus communication of several FMUs is also permitted. Depending on the needs, it may be necessary to dynamically provision the Bus Simulation FMU so that it provides the appropriate number of inputs and outputs to allow all FMUs to be connected.

3.1.3. Importer with Integrated Bus Simulation

In the third variant of the communication architecture, the bus simulation is built directly into the respective importer. The supported bus features are analogous to the Composition with dedicated Bus Simulation FMU use case. The corresponding limitations regarding the behavior of the bus simulation are importer-specific. The following figure illustrates two FMUs, which are integrated by an importer that directly supports this standard and needs no further Bus Simulation FMU.

Figure 4. Bus simulation by using an importer with internal bus simulation support.

The usage of this architecture type allows the integration of this layered standard into an already existing simulator, which implements network communication with proprietary interfaces. In this case, it may also be possible to integrate other, for example manufacturer-specific, formats into a bus simulation.

3.2. Provided C-API

Besides the textual specification for FMUs with bus support, this layered standard also provides a C header files to simplify the creation of FMUs with bus support. The following header files are provided:

fmi3LsBus.h provides general macros, types and structures of common Bus Operations. These header file applies to all supported bus types of the layered standard.
fmi3LsBusCan.h provides macros, types and structures of Bus Operations explicit for CAN, CAN FD and CAN XL. Primarily, structures are included here that allow the Bus Operations specified by the layered standard to be easily created and used.
fmi3LsBusUtil.h provides common utility macros and structures for all supported bus types.
fmi3LsBusUtilCan.h provides CAN, CAN FD and CAN XL explicit utility macros.

4. Physical Signal Abstraction ("high cut")

This chapter describes the physical signal abstraction or "high cut" in detail.

4.1. Overview

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.

The figure below shows an example architecture of a high-cut. The signals (Signal 1…8) are modeled as clocked FMU 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 FMU variables are connected to a Bus Simulation, which emulates them according to their own needs for e.g., in accuracy.

Figure 5. High-cut example architecture.

4.2. Variables

This section explains the different variable types used to carry network traffic through FMI input and output variables.

4.2.1. Signal Variables

To define the signal abstraction layer (or "high cut"), signal variables are defined.

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 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 [those values could even be outside their specified min-max range without fault].

Generally, signal variables are optional, but they must either be all missing or all present to clearly indicate support for the signal abstraction layer.

All signal variables are clocked to exactly indicate when they have been sent, see Section 4.2.2.

4.2.2. Clock Variables

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

The output Clock type, periodic or aperiodic, is defined by the sending FMU. This 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 will reduce the network simulation speed.
Using periodic Clocks reduces the number of Event Modes required and speeds up the simulation at the cost of simulation accuracy, because timing must be forced into a fixed grid and some intermediate values might not be transmitted.
One could use (structural) parameters to define the accuracy of aperiodic Clocks, allowing control of the simulation accuracy and performance with the same FMU.
The input Clocks shall be triggered Clocks.

The importer will then connect and merge output Clock activations, even those of different Clock types, and forwards them to the input Clocks, as required by the network semantics.

Signal variables belonging to frame BusName.FrameName are triggered by the Clock BusName.FrameName_Clock and all these variables and their corresponding Clock must share the same causality (input or output).

4.3. Network Description Files

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.

4.4. Terminal Definitions

This section defines terminals for physical signal abstraction or "high cut".

4.4.1. Bus Terminal

Each network connected to the FMU must be described in icons/terminalsAndIcons.xml as a <Terminal> element of <fmiTerminalsAndIcons><Terminals> that wraps all frame terminals. The attribute name of the <Terminal> must match the root name of its network description file if it exists [e.g., Powertrain, if the file is /extra/org.fmi-standard.fmi-ls-bus/Powertrain.dbc]. In any case, the attribute name of the <Terminal> must be consistent with the BusName component of all its corresponding signal, frame and Clock variables.

Attribute definitions

terminalKind must be set to org.fmi-ls-bus.network-terminal.
matchingRule must be set to bus.
name is the network name, e.g., Powertrain, see example and constraints above.

Element definitions

There must be no <TerminalStreamMemberVariable> element.
There must be one <Terminal> element per network frame described in the network description file, if their signal and Clock variables are present in the modelDescription.xml.

Annotation element

If a network description file is shipped with the specified FMU, there must be an <Annotation> element defining which node or nodes (as comma-separated list without spaces) of the network description file are wrapped inside the FMU. If the combination of nodes specified for this FMU turns a frame and its signals into both input and output because sending and receiving nodes are specified, only the sending (output) role will be defined in the FMU interface. Receiving such frames must then be handled internally to the FMU. If no network description file is shipped with the specified FMU the <Annotation> shall not exist.

4.4.2. Frame Terminal

Each frame listed in the network description file must be an element of its corresponding Bus Terminal.

Attribute definitions

terminalKind must be set to org.fmi-ls-bus.frame-terminal.
matchingRule must be set to bus.
name must match the frame name as defined in the network description file in /extra/org.fmi-standard.fmi-ls-bus.

Element definitions

There must be no <TerminalStreamMemberVariable> element.
There must be one PDU terminal element per PDU of this frame.
There must be one <TerminalMemberVariable> for the Clock this frame is connected to. The memberName of this variable must be "Clock".

The Terminal Member Variable must have the same causality as all variables referenced in the PDU Terminals included here.

4.4.3. PDU Terminal

Each PDU listed in the network description file must be an element of its corresponding frame terminal.

Attribute definitions

terminalKind must be set to org.fmi-ls-bus.pdu-terminal.
matchingRule must be set to bus.
name must match a PDU name of the network description file in /extra/org.fmi-standard.fmi-ls-bus, if given. For network types not natively referencing a "PDU", like CAN, a synthetic PDU with the same name as its frame is inserted.

Element definitions

There must be no <TerminalStreamMemberVariable> element.
There must be no <Terminal> element.
There must be one <TerminalMemberVariable> per signal of this PDU.

All TerminalMemberVariables must have the same causality of either input or output.

4.4.4. Terminal Member Variable for Signals

PDU terminals list all the contained signals as <TerminalMemberVariable>.

Attribute definitions

variableName refers to the input or output variable name of the FMU and to enforce uniqueness is built as follows: BusName.FrameName.PDUName.SignalName, e.g., Powertrain.tcuSensors.tcuSensors.vCar. These variables represent the signal abstraction layer ("high cut").
memberName is the SignalName as given in the network description file, e.g., vCar, if given. This is redundant information but simplifies signal name extraction.
variableKind is signal.

4.4.5. Example

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

The following partial DBC file lists merely the CAN message (frame) structure. Signal trigger conditions are not included because they have no bearing on this standard.

Example Powertrain.dbc file.

...
BO_ 256 tcuSensors: 4 TCU
 SG_ vCar :          0|16@1- (32,0)  [-500|500] "km/h" ECU
 SG_ oilTemp :      16|9@1-  (2,50)  [-50|150]  "Degree C" ECU

BO_ 257 tcuState: 2 TCU
 SG_ state :         0|2@1+  (1,0)   [ 0|2] "-" ECU
 SG_ gear :          2|4@1-  (1,0)   [-2|6] "-" ECU
 SG_ targetGear :    6|4@1-  (1,0)   [-2|6] "-" ECU

BO_ 512 ecuState: 4 ECU
 SG_ accelPedal :    0|8@1+ (2,0)   [0|100]   "%" TCU
 SG_ k15 :           8|1@1+ (1,0)   [0|1]     "-" TCU
 SG_ oilTemp :       9|9@1- (2,50)  [-50|150] "Degree C" TCU
 SG_ radiatorTemp : 18|9@1- (2,50)  [-50|150] "Degree C" TCU
...

The modelDescription.xml excerpt listed below shows which variables would exist for the Powertrain.dbc shown above.

Example modelDescription.xml for ECU node.

<?xml version="1.0" encoding="UTF-8"?>
<fmiModelDescription fmiVersion="3.0" modelName="Network4FMI"
    instantiationToken="Network4FMI">
  <ModelVariables>
    <Clock name="Powertrain.tcuSensors_Clock" valueReference="1007"
        causality="input" variability="discrete" intervalVariability="triggered"/>
    <Float64 name="Powertrain.tcuSensors.tcuSensors.vCar" valueReference="1005"
        causality="input" variability="discrete" start="0" clocks="1007"/>
    <Float64 name="Powertrain.tcuSensors.tcuSensors.oilTemp" valueReference="1006"
        causality="input" variability="discrete" start="20" clocks="1007"/>

    <Clock name="Powertrain.tcuState_Clock" valueReference="1011"
        causality="input" variability="discrete" intervalVariability="triggered"/>
    <Float64 name="Powertrain.tcuState.tcuState.state" valueReference="1008"
        causality="input" variability="discrete" start="0" clocks="1011"/>
    <Float64 name="Powertrain.tcuState.tcuState.gear" valueReference="1009"
        causality="input" variability="discrete" start="0" clocks="1011"/>
    <Float64 name="Powertrain.tcuState.tcuState.targetGear" valueReference="1010"
        causality="input" variability="discrete" start="0" clocks="1011"/>

    <Clock name="Powertrain.ecuState_Clock" valueReference="1016"
        causality="output" variability="discrete" intervalVariability="triggered"/>
    <Float64 name="Powertrain.ecuState.ecuState.accelPedal" valueReference="1012"
        causality="output" variability="discrete" start="0" clocks="1016"/>
    <Float64 name="Powertrain.ecuState.ecuState.k15" valueReference="1013"
        causality="output" variability="discrete" start="0" clocks="1016"/>
    <Float64 name="Powertrain.ecuState.ecuState.oilTemp" valueReference="1014"
        causality="output" variability="discrete" start="0" clocks="1016"/>
    <Float64 name="Powertrain.ecuState.ecuState.radiatorTemp" valueReference="1015"
        causality="output" variability="discrete" start="0" clocks="1016"/>
  </ModelVariables>
  <ModelStructure>
  </ModelStructure>
</fmiModelDescription>

The following file shows the <Terminal> definition representing the network and frame structure defined with Powertrain.dbc above.

Example terminalsAndIcons.xml file.

<?xml version="1.0" encoding="UTF-8"?>
<fmiTerminalsAndIcons fmiVersion="3.0">
  <Terminals>
    <Terminal terminalKind="org.fmi-ls-bus.network-terminal" name="Powertrain" matchingRule="bus"
        description="Powertrain CAN bus defined with dbc file">
      <Terminal terminalKind="org.fmi-ls-bus.frame-terminal" name="tcuSensors" matchingRule="bus">
        <TerminalMemberVariable variableKind="signal"
          variableName="Powertrain.tcuSensors_Clock" memberName="Clock" />
        <Terminal terminalKind="org.fmi-ls-bus.pdu-terminal" name="tcuSensors" matchingRule="bus">
          <TerminalMemberVariable variableKind="signal"
            variableName="Powertrain.tcuSensors.tcuSensors.vCar" memberName="vCar" />
          <TerminalMemberVariable variableKind="signal"
            variableName="Powertrain.tcuSensors.tcuSensors.oilTemp" memberName="oilTemp" />
        </Terminal>
      </Terminal>
      <Terminal terminalKind="org.fmi-ls-bus.frame-terminal" name="tcuState" matchingRule="bus">
        <TerminalMemberVariable variableKind="signal"
          variableName="Powertrain.tcuState_Clock" memberName="Clock" />
        <Terminal terminalKind="org.fmi-ls-bus.pdu-terminal" name="tcuState" matchingRule="bus">
          <TerminalMemberVariable variableKind="signal"
            variableName="Powertrain.tcuState.tcuState.state" memberName="state" />
          <TerminalMemberVariable variableKind="signal"
            variableName="Powertrain.tcuState.tcuState.gear" memberName="gear" />
          <TerminalMemberVariable variableKind="signal"
            variableName="Powertrain.tcuState.tcuState.targetGear" memberName="targetGear" />
        </Terminal>
      </Terminal>
      <Terminal terminalKind="org.fmi-ls-bus.frame-terminal" name="ecuState" matchingRule="bus">
        <TerminalMemberVariable variableKind="signal"
          variableName="Powertrain.ecuState_Clock" memberName="Clock" />
        <Terminal terminalKind="org.fmi-ls-bus.pdu-terminal" name="ecuState" matchingRule="bus">
          <TerminalMemberVariable variableKind="signal"
            variableName="Powertrain.ecuState.ecuState.accelPedal" memberName="accelPedal" />
          <TerminalMemberVariable variableKind="signal"
            variableName="Powertrain.ecuState.ecuState.k15" memberName="k15" />
          <TerminalMemberVariable variableKind="signal"
            variableName="Powertrain.ecuState.ecuState.oilTemp" memberName="oilTemp" />
          <TerminalMemberVariable variableKind="signal"
            variableName="Powertrain.ecuState.ecuState.radiatorTemp" memberName="radiatorTemp" />
        </Terminal>
      </Terminal>
      <Annotations>
        <Annotation type="ECU" />
      </Annotations>
    </Terminal>
  </Terminals>
</fmiTerminalsAndIcons>

4.5. Limitations

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):

Network frame arbitration: frames are sent on the wire according to network-specific priority rules.
Here all frames are transmitted at the same time without delay.
Network congestion/bandwidth: too many network frames sent for the bandwidth of the network.
Here the network has infinite capacity.
If network properties are required, a bus simulation component must be added or included with the importer.
Protocol functions of higher levels: i.e. CAN request for retransmit is a specific protocol function.
Here such specialties must be handled by the first layer inside the FMU.
Incoming buffer overflow: when an ECU receives more frames than its buffer can hold.
Here the FMU will receive all frames, regardless of buffer size and would need to handle those limitations internally.
Network protocols allow frames to be sent from more than one node.
Here this is also possible, with output variables for frames (and their signals) that are sent by more than one FMU. This requires the importer to handle the case when multiple source FMUs are sending the same frame. Importers must know how to handle this, just like they must know how to handle flow variables according to Kirchhoff’s law.

5. Network Abstraction ("low cut")

This chapter describes the network abstraction or "low cut" in detail.

5.1. Overview

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.

Figure 6. Transmission overview.

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".

Figure 7. Example for network simulation with timing behavior.

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.

5.2. Layered Standard Bus Protocol

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 the 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:

OP Code: The operation code defines the unique value of the operation. It consists of four bytes in length.
Length: A four byte total data length (OP Code + Length + Arguments) field following the OP Code. For operation with variable size arguments, the total length can vary in value at runtime.
Arguments: The arguments of the respective operation. The number of arguments is defined for each operation within this standard. For arguments with a variable length, an argument pair composed of length and data is used.

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.

Table 2. Definition of an operation within the Layered Standard Bus Protocol.
Operation Type	Operation Content
Operation Type	OP Code	Length	Specific Content
OperationName	0x01	10 + <Arg2_Length>	1 byte Arg1	1 byte Arg2_Length	<Arg2_Length> byte Arg2_Data

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

Table 3. Operation example within the Layered Standard Bus Protocol.
Content	Argument	Length	Description
Name	Name of the operation (e.g., OperationName)
Description	Contains a description of the specified operation.
OP Code [hex]	OP code of the operation (e.g., 0x01)
	OP Code	4 byte	Contains the OP Code of the specified operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: `Length = 10 + <Arg2_Length>`.
	Arg1	1 byte	The first argument of the operation.
	Arg2_Length	1 byte	Contains the length of the Arg2_Data argument in bytes.
	Arg2_Data	n byte	The second argument of the operation.
Behavior	Describes the behavior of a Network FMU and the Bus Simulation in the context of this operation. e.g., The specified operation shall be produced by a Network FMU and consumed by the Bus Simulation.

Remarks:

Numbers shall be transmitted with little-endian byte order.
Since the standard allows to concatenate multiple operations (see Tx/Rx Data Variables), the Length field is introduced to allow the implementation of a generic parser for received operations.

5.2.1. Format Error

The Format Error operation is independent from the bus type and shall be used when encountering a syntax or content error of received operations.

Table 4. Detailed description of the Format Error operation.
Content	Argument	Length	Description
Name	Format Error
Description	Represents a generic format operation error, which can be initiated by every operation. This error shall be used when generally encountering a problem with the syntax or content of an operation.
OP Code [hex]	0x01
	OP Code	4 byte	Contains the OP Code of the specified operation. For this operation, the OP Code always has the value 0x01 within all bus types.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: `Length = 10 + Length of Data argument in bytes`.
	Data Length	2 byte	Specifies the length of the Data argument in bytes.
	Data	n byte	Stores the complete binary data of the operation that caused the specified `Format Error`.
Behavior	The specified operation shall be produced and consumed by Network FMUs and the Bus Simulation.

5.2.2. Basic Type Definitions

The following basic types are defined for this standard, which apply to all supported buses. These basic types are used in the bus-specific parts within the operation definitions as operation arguments.

The following values for the boolean basic type are defined:

Table 5. Overview of the available boolean values.
Boolean	Value	Description
FALSE	0x00	Describes the boolean value: False.
TRUE	0x01	Describes the boolean value: True.

5.3. Variables

This section explains how layered standard bus protocol operations are sent and received by FMUs using FMI 3.0 Clock and clocked variables ^[3]. While the former (see Tx Clock Variables and Rx Clock Variables) are used for scheduling and time synchronization, the latter (see Tx/Rx Data Variables) are used to carry the layered standard bus protocol operations in binary form. To summarize, four variables with the following characteristics and relations are used:

The Rx_Data variable is clocked by the Rx_Clock variable, both with causality set to input.
The Tx_Data variable is clocked by the Tx_Clock variable. The causality for the Tx_Data variable shall be output, but for the Tx_Clock variable it depends on the selected Clock type (see Tx Clock Variables).

Both variable pairs must be listed as member of its corresponding Bus Terminal.

5.3.1. Tx Clock Variables

As described in the FMI 3.0 specification, Clock variables are used to synchronize events between importer and across FMUs. Since Clock variables are strictly related to the Event Mode, networked FMUs shall set the Co-Simulation attribute hasEventMode = "true" in the model description file.

The point in time where Bus Operations are transferred from the Tx_Data to the Rx_Data variables is defined by the Tx_Clock variable. This point is also referred to as the Bus Communication Point. A Bus Communication Point and a regular communication point can take place at the same time, but should be considered as independent by the importer. In contrast to a regular communication point where input/output variables used in step mode are exchanged, only the clocked Tx/Rx data variables needs to be considered by the importer.

For defining the point in time of a Bus Communication Point, time-based or triggered Clocks can be used for the Tx_Clock variable. Hence the Clock type can influence the bus simulation significantly - the differences should be taken into account.

5.3.1.1. Time-based Tx Clock Variables

A time-based Tx_Clock variable allows networked FMUs to announce a Bus Communication Point for the next simulation step in advance.

Figure 8. Example Bus Communication Points announced by aperiodic time-based Tx_Clock variables.

The announced Tx time however does not mean that a Bus Operation really has to be transferred, but that the connected networked FMUs should enter the Event Mode at that time. An importer has to determine proper communication step sizes to synchronize networked FMUs at the announced Tx time.

[Note: While simulation it can happen that no Tx_Data has to be transferred to the Rx_Data variable at the announced Tx time. In this case the returned 'valueSize' of the Tx_Data variable is 0.]

Although the causality of a time-based Tx_Clock variable and a triggered Rx_Clock variable are each input, it is allowed to connect both, since a time-based Clock variable of an FMU is considered only to be a request to the importer to provide an attendant Clock source.

Figure 9. Consideration of time-base Tx_Clock connections.

Because of the common Clock source however, both Clock variables (Rx/Tx) might get active at the same time. To make sure that the Rx_Data variables is set properly, an importer has to activate the Rx_Clock variable under consideration of Tx_Data and Rx_Data dependency.

[Note: For clarity always a direct connection line between the Tx_Clock and Rx_Clock variables is shown in figures of this document.]

A time-based Clock can be periodic or aperiodic. Both allows to define Bus Communication Points independently from the regular communication points with fixed or variable distances. The difference between the two Clock types is listed in the following table.

Table 6. Time-based Clock properties.
Clock properties	intervalVariability	Description
`periodic`	`constant`	The Bus Communication Point interval is defined in the `modelDescription.xml`.
`periodic`	`fixed`	The Bus Communication Point interval is defined in the `modelDescription.xml` or must be provided in `Initialization Mode`.
`periodic`	`tunable`	The Bus Communication Point interval is defined in the `modelDescription.xml` or must be provided in `Initialization Mode` and can be changed in `Event Mode`.
`aperiodic`	`changing`	The Bus Communication Point interval must be provided in `Initialization Mode` and can be changed in `Event Mode` if this Clock ticked.
`aperiodic`	`countdown`	The Bus Communication Point interval must be provided in `Initialization Mode` and can be changed in every `Event Mode`.

Network FMUs using a time-based Tx_Clock variable should set the Co-Simulation attribute canHandleVariableCommunicationStepSize = "true" in the model description file, since fmi3DoStep is typically called with variable communicationStepSize.

5.3.1.2. Triggered Tx Clock Variables

A triggered Clock basically allows to signal events when returning from fmi3DoStep either by using an Early Return or when the requested communication point at \(t_{i+1}\) was reached. Since signaling Tx_Clock events with an early return at \(t < t_{i+1}\) would require to set connected networked FMUs back in time to reach Bus Communication Points synchronously, a triggered Tx_Clock variable must only be set when returning from fmi3DoStep with the earlyReturn argument set to fmi3False. In consequence, Bus Communication Points and regular communication points coincide and take place at the same time. The time of a Bus Communication Point can therefore not be defined independently, but is given by the importer. Pending Tx data shall be signaled by returning from fmi3DoStep with the eventHandlingNeeded arguments set to fmi3True.

Figure 10. Triggered Tx_Clock/Rx_Clock connection.

5.3.2. Rx Clock Variables

The input Clocks (Rx_Clock) shall be triggered Clocks.

5.3.3. Tx/Rx Data Variables

The Tx/Rx variables are of type fmi3Binary and contain multiple Bus Operations, as sent or receive by the FMU. If no Bus Operations shall be sent by a specified Network FMU at a given Bus Communication Point, the size of the corresponding binary Tx_Data variable shall be set to zero. The senders can choose how many Bus Operations are buffered and/or for how long operations are buffered before activating an output Clock to trigger the actual sending of these operations. This allows senders to trade accuracy for speed: buffering more and interrupting the simulation less will lead to faster simulations, but less accurate timing of the network communication.

5.3.4. Selecting the type of Tx Clock

Selecting suitable Tx variables 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 will reduce the network simulation speed.
Using periodic Clocks and queueing the operations to be transmitted reduces the number of Event Mode entries and 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.

5.3.5. MIME Types

Within FMI, every binary FMI variable has a mimeType, which indicates the type of data passed as a binary. This type indicates which specific bus type is involved. It ensures that only bus types of the same type can be interconnected, since FMI only allows the connection of two MIME types of the same binary variables. The following table lists the MIME types to use for the Tx/Rx data variables within a Bus Terminal:

Table 7. Overview of the available MIME types for the supported several bus types.
MIME type	Description
application/org.fmi-standard.fmi-ls-bus.can; version="1.0.0-beta.1"	Binary variables simulating a CAN network including CAN, CAN FD and CAN XL
application/org.fmi-standard.fmi-ls-bus.lin; version="1.0.0-alpha.1"	Binary variables simulating a LIN network
application/org.fmi-standard.fmi-ls-bus.flexray; version="1.0.0-alpha.1"	Binary variables simulating a FlexRay network
application/org.fmi-standard.fmi-ls-bus.ethernet; version="1.0.0-alpha.1"	Binary variables simulating an Ethernet network

As in the table, above the version of a specified bus type is integrated within the MIME type. The MIME type and the associated versioning ensure that only compatible bus types can be connected to each other. The version number marks the set of available operations for a specified bus type. The versioning follows the rules of semantic versioning, as defined in [PW13].

5.4. Terminal Definitions

This section defines terminals for network abstraction or "low cut".

5.4.1. Bus Terminal

Each network connected to the FMU must be described in icons/terminalsAndIcons.xml as a <Terminal> element of <fmiTerminalsAndIcons><Terminals>. The attribute name of the <Terminal> must match the name of the specified network [e.g., the name of the CAN channel: Powertrain] within a "low cut". If the specified FMU is connected to more than one network, there shall be exactly one <Terminal> for each network.

Attribute definitions

terminalKind must be set to org.fmi-ls-bus.network-terminal.
matchingRule must be set to org.fmi-ls-bus.transceiver.
name is the network name, e.g., Powertrain, see example and constraints.

Element definitions

Every Bus Terminal contains exactly four variables each in the role of: Tx_Data, Tx_Clock, Rx_Data or Rx_Clock.
Variables in the role of Rx_Data, Tx_Data, Rx_Clock and Tx_Clock are exposed in the modelDescription.xml and must be listed as <TerminalMemberVariable> elements, whereby variableName can be freely chosen.
<TerminalMemberVariable>.memberName defines the role of the variable within the <Terminal> and shall be set to Tx_Data, Tx_Clock, Rx_Data or Rx_Clock.
Multiple use of the same variable within different Bus Terminals is not allowed.
There must be no <TerminalStreamMemberVariable> element.

The matchingRule of type org.fmi-ls-bus.transceiver is specified as: Tx_{Data|Clock} variables shall be connected to Rx_{Data|Clock} variables and vice versa, whereby the variable type shall be equal.

The following figure shows a FMU with four variables Tx_Data, Tx_Clock, Rx_Data, Rx_Clock that are aggregated to a <Terminal> named Bus Terminal:

Figure 11. Frame variables and terminals.

5.4.2. Example

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

Example modelDescription.xml for ECU node.

<?xml version="1.0" encoding="UTF-8"?>
<fmiModelDescription fmiVersion="3.0" modelName="Network4FMI"
    instantiationToken="Network4FMI">
  <ModelVariables>
    <Clock name="Powertrain.Rx_Clock" valueReference="1002"
        causality="input" variability="discrete" intervalVariability="triggered"/>
    <Binary name="Powertrain.Rx_Data" valueReference="1001" causality="input"
        mimeType="application/org.fmi-standard.fmi-ls-bus.can; version=&quot;1.0.0-beta.1&quot;" variability="discrete" clocks="1002"/>
    <Clock name="Powertrain.Tx_Clock" valueReference="1004"
        causality="input" variability="discrete" intervalVariability="changing"/>
    <Binary name="Powertrain.Tx_Data" valueReference="1003" causality="output"
        mimeType="application/org.fmi-standard.fmi-ls-bus.can; version=&quot;1.0.0-beta.1&quot;" variability="discrete" clocks="1004"/>
  </ModelVariables>
  <ModelStructure>
  </ModelStructure>
</fmiModelDescription>

The following file shows the <Terminal> related definition:

Example terminalsAndIcons.xml file.

<?xml version="1.0" encoding="UTF-8"?>
<fmiTerminalsAndIcons fmiVersion="3.0">
  <Terminals>
    <Terminal terminalKind="org.fmi-ls-bus.network-terminal" name="Powertrain" matchingRule="org.fmi-ls-bus.transceiver"
        description="Powertrain CAN Bus Terminal definition">
      <TerminalMemberVariable variableKind="signal"
        variableName="Powertrain.Rx_Clock" memberName="Rx_Clock" />
      <TerminalMemberVariable variableKind="signal"
        variableName="Powertrain.Rx_Data" memberName="Rx_Data" />
      <TerminalMemberVariable variableKind="signal"
        variableName="Powertrain.Tx_Clock" memberName="Tx_Clock" />
      <TerminalMemberVariable variableKind="signal"
        variableName="Powertrain.Tx_Data" memberName="Tx_Data" />
      </Terminal>
    </Terminal>
  </Terminals>
</fmiTerminalsAndIcons>

5.5. Bus-Specific Details

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.

5.5.1. CAN, CAN FD, CAN XL

This chapter describes the Layered Standard Bus Protocol for CAN, CAN FD and CAN XL. The various CAN standards CAN, CAN FD and CAN XL are considered together, because they are very similar and can also be combined in certain scenarios.

5.5.1.1. Overview

To simulate CAN, CAN FD and CAN XL buses, CAN-specific operations are specified based on the Layered Standard Bus Protocol. Overall, the following groups of operations exists:

Transmit: This group of operations is used to simulate a frame transmission. There are three specializations of this operation, one each for CAN, CAN FD and CAN XL frames.
Confirm: An acknowledgment of transmitted CAN frames is defined by the CAN standard. This kind of operation is used to simulate this behavior.
Error: This group of operations is used for protocol format errors and to simulate bus failures. For example, the failure of a transmission can be indicated.
Arbitration Lost: The operation is used by Bus Simulations to inform Network FMUs that a frame could not be transmitted immediately.
Configuration: This operation enables the configuration of bus-specific parameters and options that are required to simulate the bus behavior properly. For example, it allows the specification of the baud rate or influencing the buffer behavior.
Status: This operation is used by Networked FMUs to inform Bus Simulations about the internal state (Active/Passive/Bus-Off) which concerns the reaction on bus errors.
Wake up: CAN supports wake up and sleep scenarios. Normally there are two ways to wake up from sleep mode: a local wake up on a specified wake-up pin, or a wake up on the CAN bus via a CAN specific wake-up pulse. This operation is used to simulate triggering a wake up from bus side.

The following table gives a detailed overview of the available operations. It shows all operations and the arguments they contain.

Table 8. Overview of the available operations for CAN, CAN FD and CAN XL.
Operation Name	Operation Content
Operation Name	OP Code	Length	Specific Content
Format Error	0x01	:= 10 + n (4 byte)	DL (2 byte)	Data (n byte)
CAN Transmit	0x10	:= 16 + DL (4 byte)	ID (4 byte)	Ide (1 byte)	Rtr (1 byte)	DL (2 byte)	Data (n byte)
CAN FD Transmit	0x11	:= 17 + DL (4 byte)	ID (4 byte)	Ide (1 byte)	Brs (1 byte)	Esi (1 byte)	DL (2 byte)	Data (n byte)
CAN XL Transmit	0x12	:= 22 + DL (4 byte)	ID (4 byte)	Ide (1 byte)	Sec (1 byte)	SDT (1 byte)	VCID (1 byte)	AF (4 byte)	DL (2 byte)	Data (n byte)
Confirm	0x20	:= 12 (4 byte)	ID (4 byte)
Arbitration Lost	0x30	:= 12 (4 byte)	ID (4 byte)
Bus Error	0x31	:= 15 (4 byte)	ID (4 byte)	Error Code (1 byte)		Error Flag (1 byte)		Is Sender (1 byte)
Configuration	0x40	<Length> (4 byte)	Kind (1 byte)	Dynamic Part
Status	0x41	:= 9 (4 byte)	Status (1 byte)
Wakeup	0x42	:= 8 (4 byte)	---

5.5.1.2. Operations

This section defines the specified operations for CAN, CAN FD and CAN XL. The following tables provides an overview of all operations and specifies the position and length of the corresponding arguments, as well as the respective flow direction.

5.5.1.2.1. Transmit

There are three types of Transmit operations for transmission of CAN, CAN FD and CAN XL frames.

Table 9. Detailed description of the CAN Transmit operation.
Content	Argument	Length	Description
Name	CAN Transmit
Description	Initiates the transmission of CAN frames.
OP Code [hex]	0x10
	OP Code	4 byte	Contains the OP Code (0x10) of the operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: `Length = 16 + Data Length`.
	ID	4 byte	The specified ID of the CAN message. The ID must be considered here as a purely numerical value. This means that there is no need for separate segmentation between the 11-bit base CAN identifier and an 18-bit CAN identifier extension information that is known from the CAN protocol. Additional information such as Ide is also not part of the ID, but is treated separately.
	Ide	1 byte	Specified whether the ID should be transmitted as standard (11-bit) or extended (29-bit) message identifier. For specification the boolean values `TRUE` and `FALSE` (see Table 5) shall be used.
	Rtr	1 byte	Specifies whether the given frame represents a Remote Transmission Request frame. For specification the boolean values `TRUE` and `FALSE` (see Table 5) shall be used.
	Data Length	2 byte	Specifies the length of the Data argument in bytes.
	Data	n byte	Stores the given frame data to transfer, whereby the valid length of the data depends on the CAN Format.
Behavior	The `CAN Transmit` operation shall be provided by Network FMUs to initiate the transmission of a CAN frame. In case of directly connected Network FMUs (see Section 3.1.1), the FMU importer forwards the operation directly to the receiving Network FMUs. If a Bus Simulation is involved (see Section 3.1.2 and Section 3.1.3), the FMU importer forwards the operation initially to the Bus Simulation, where the operation is distributed with respect to the simulated bus behavior. Depending on the simulation details, the Bus Simulation might response with a `Confirm`, `Arbitration Lost`, `Bus Error` or `Format Error` operation. Depending on the status of the specified Network FMU further restrictions for `CAN Transmit` operations exist.

Table 10. Detailed description of the CAN FD Transmit operation.
Content	Argument	Length	Description
Name	CAN FD Transmit
Description	Represents an operation for the transmission of a CAN FD frame.
OP Code [hex]	0x11
	OP Code	4 byte	Contains the OP Code (0x11) of the operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: `Length = 17 + Data Length`.
	ID	4 byte	The specified ID of the CAN message. The ID must be considered here as a purely numerical value. This means that there is no need for separate segmentation between the 11-bit base CAN identifier and an 18-bit CAN identifier extension information that is known from the CAN protocol. Additional information such as Ide is also not part of the ID, but is treated separately.
	Ide	1 byte	Specified whether the ID should be transmitted as standard (11-bit) or extended (29-bit) message identifier. For specification the boolean values `TRUE` and `FALSE` (see Table 5) shall be used.
	Brs	1 byte	Defines the Bit Rate Switch. For specification the boolean values `TRUE` and `FALSE` (see Table 5) shall be used.
	Esi	1 byte	Error State indicator. For specification the boolean values `TRUE` and `FALSE` (see Table 5) shall be used.
	Data Length	2 byte	Specifies the length of the Data argument in bytes.
	Data	n byte	Stores the given frame data to transfer, whereby the valid length of the data depends on the CAN FD Format.
Behavior	The behavior is identical to the CAN Transmit behavior.

Table 11. Detailed description of the CAN XL Transmit operation.
Content	Argument	Length	Description
Name	CAN XL Transmit
Description	Represents an operation for the transmission of a CAN XL frame.
OP Code [hex]	0x12
	OP Code	4 byte	Contains the OP Code (0x12) of the operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: `Length = 22 + Data Length`.
	ID	4 byte	The specified ID of the CAN message. The ID must be considered here as a purely numerical value. This means that there is no need for separate segmentation between the 11-bit base CAN identifier and an 18-bit CAN identifier extension information that is known from the CAN protocol. Additional information such as Ide is also not part of the ID, but is treated separately.
	Ide	1 byte	Specified whether the ID should be transmitted as standard (11-bit) or extended (29-bit) message identifier. For specification the boolean values `TRUE` and `FALSE` (see Table 5) shall be used.
	Sec	1 byte	Simple Extended Content For specification the boolean values `TRUE` and `FALSE` (see Table 5) shall be used.
	SDT	1 byte	Describes the structure of the frames Data Field content (SDU type).
	VCID	1 byte	Represents the virtual CAN network ID.
	AF	4 byte	Represents the CAN XL Acceptance Field (AF).
	Data Length	2 byte	Specifies the length of the Data argument in bytes.
	Data	n byte	Stores the given frame data to transfer, whereby the valid length of the data depends on the CAN XL Format.
Behavior	The behavior is identical to the CAN Transmit behavior.

5.5.1.2.2. Confirm

The Confirm operation is used to signal the successful reception of a transmitted CAN frame (see Transmit operation) by at least one Network FMU.

Table 12. Detailed description of the Confirm operation.
Content	Argument	Length	Description
Name	Confirm
Description	Signals successful receipt of a transmitted CAN, CAN FD and CAN XL frame to simulate a CAN acknowledgment behavior.
OP Code [hex]	0x20
	OP Code	4 byte	Contains the OP Code (0x20) of the operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: `Length = 12`.
	ID	4 byte	The ID of the confirmed CAN message.
Behavior	The specified operation shall be produced by the Bus Simulation and consumed by Network FMUs. If the structural parameter `org.fmi_standard.fmi_ls_bus.Can_BusNotifications` of a Network FMU is set to `false`, the Network FMU does not wait for any responses from a Bus Simulation, i.e., potentially received `Confirm` operations are discarded by the Network FMU. Depending on the status of the specified Network FMU further restrictions for `Confirm` operations exist.

5.5.1.2.3. Format Error

Represents a format error that indicates a syntax or content error of receiving operations. See Format Error for definition.

5.5.1.2.4. Arbitration Lost

The Arbitration Lost operation defines a feedback message from a Bus Simulation to a Network FMU that a Transmit operation could not be sent immediately due to a concurrent transmit request.

Table 13. Detailed description of the Arbitration Lost operation.
Content	Argument	Length	Description
Name	Arbitration Lost
Description	The `Arbitration Lost` operation indicates that a CAN frame could not be sent immediately and was therefore discarded by the Bus Simulation. See Section 5.5.1.7 for further details.
OP Code [hex]	0x30
	OP Code	4 byte	Contains the OP Code (0x30) of the operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: `Length = 12`.
	ID	4 byte	The ID of the CAN message which which could not be transmitted immediately, because it loses arbitration.
Behavior	During simulation, several `Transmit` operations can be sent by Network FMUs to a Bus Simulation at the same time. In such case, the Bus Simulation has to decide which `Transmit` operation should be processed first. Depending on the configuration (see the `Arbitration Lost Behavior` argument of the `Configuration` operation), the deferred `Transmit` operations shall either be buffered or they shall be discarded and the `Arbitration Lost` operation shall be sent back to the respective Network FMUs. A Network FMU receiving the `Arbitration Lost` operation can decide to provide the `Transmit` operation again or e.g., to raise an internal transmit timeout failure after a while. If the structural parameter `org.fmi_standard.fmi_ls_bus.Can_BusNotifications` of a Network FMU is set to `false`, the Network FMU does not wait for any responses from a Bus Simulation, i.e., potentially received `Arbitration Lost` operations are discarded by the Network FMU.

5.5.1.2.5. Bus Error

The Bus Error operation represents special bus communication errors, which are delivered to every participant in the network.

Table 14. Detailed description of the Bus Error operation.
Content	Argument	Length	Description
Name	Bus Error
Description	Represents an operation for simulated bus errors.
OP Code [hex]	0x31
	OP Code	4 byte	Contains the OP Code (0x31) of the operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: `Length = 15`.
	ID	4 byte	The ID of the CAN message that was transmitted while the error happened.
	Error Code	1 byte	The simulated bus error, based on the table below.
	Error Flag	1 byte	Defines whether the Error was detected by a specified Network FMU. For specification the boolean values `PRIMARY_ERROR_FLAG` and `SECONDARY_ERROR_FLAG` (see Table 16) shall be used.
	Is Sender	1 byte	Set if the `Bus Error` operation is a reaction to a `Transmit` operation that was provided by the specified Network FMU from the Bus Simulation. For specification the boolean values `TRUE` and `FALSE` (see Table 5) shall be used.
Behavior	While transmitting CAN frames, various kinds of bus error may happen. A Bus Simulation can simulate such errors by providing `Bus Error` operations to the Network FMUs. Based on consumed `Bus Error` operations, Network FMUs shall maintain an internal CAN node state (see Section 5.5.1.6). To determine the CAN node state properly, Network FMUs need the information about their role at the time when the simulated error happened. For a Network FMU that initiated the `Transmit` operation, the argument `Is Sender` shall be set to `TRUE` in the corresponding `Bus Error` operation. For a Network FMU considered to be the one detecting the error first, the argument `Error Flag = PRIMARY_ERROR_FLAG` shall be set. The arguments `Is Sender = TRUE` and `Error Flag = PRIMARY_ERROR_FLAG` must only be set once per simulated error. If the structural parameter `org.fmi_standard.fmi_ls_bus.Can_BusNotifications` of a Network FMU is set to `false`, the Network FMU does not wait for any responses from a Bus Simulation, i.e., potentially received `Bus Error` operations are discarded by the Network FMU.

The following Error Codes are specified:

Table 15. Overview of the available error codes.
State	Error Code	Description
BIT_ERROR	0x01	Within the CAN standard, the sender also receives transmitted data for comparison. If the sent and received bits are not identical, this failure results in a Bit Error.
BIT_STUFFING_ERROR	0x02	A Bit Stuff Error occurs if 6 consecutive bits of equal value are detected on the bus.
FORM_ERROR	0x03	Occurs during a violation of End-of-Frame (EOF) format.
CRC_ERROR	0x04	Occurs when the data of a frame and the related checksum do not harmonize.
ACK_ERROR	0x05	All receiving nodes identify an invalid CAN frame.
BROKEN_ERROR_FRAME	0x06	Represents an invalid transmission of a CAN Error frame. Within CAN, an Error frame is transmitted by any unit on detection of a bus error.

The following values for the Error Flag option are defined:

Table 16. Overview of the available Error Flag values.
Error Flag	Value	Description
PRIMARY_ERROR_FLAG	0x01	Defines that a specified Network FMU is detecting the given `Bus Error` first.
SECONDARY_ERROR_FLAG	0x02	Defines that a specified Network FMU is reacting on a `Bus Error` and does not detect it.

5.5.1.2.6. Configuration

The Configuration operation is used by Network FMUs to send simulation specific options like baud rate settings to Bus Simulations. The following information is included within this operation:

Table 17. Detailed description of the Configuration operation.
Content	Argument			Length	Description
Name	Configuration
Description	Represents an operation for the configuration of a Bus Simulation. In detail, the configuration of a CAN, CAN FD and CAN XL baud rate is possible. Also the configuration of further options, like buffer handling, is supported by this operation.
OP Code [hex]	0x40
	OP Code			4 byte	Contains the OP Code (0x40) of the operation.
	Length			4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: `Length = 9 + Length of parameter arguments in bytes`.
	Parameter Type			1 byte	Defines the current configuration parameter. Note that only one parameter can be set per `Configuration` operation.
		Parameters
		CAN_BAUDRATE	Baud Rate	4 byte	The CAN baud rate value to configure. The required unit for the baud rate value is bit/s.
		CAN_FD_BAUDRATE	Baud Rate	4 byte	The CAN FD baud rate value to configure. The required unit for the baud rate value is bit/s.
		CAN_XL_BAUDRATE	Baud Rate	4 byte	The CAN XL baud rate value to configure. The required unit for the baud rate value is bit/s.
		ARBITRATION_LOST_BEHAVIOR	Arbitration Lost Behavior	1 byte	This parameter defines how a Bus Simulation shall behave in cases of an arbitration lost scenario. If the option is set to `BUFFER_AND_RETRANSMIT`, `Transmit` operations shall be buffered by the Bus Simulation and no `Arbitration Lost` operation shall be sent. If the option is set to `DISCARD_AND_NOTIFY`, the `Transmit` operation shall be discarded and an `Arbitration Lost` operation shall be sent to the Network FMU (see Section 5.5.1.7).
Behavior	The specified operation shall be produced by a Network FMU and consumed by the Bus Simulation. The operation shall not be routed to other Network FMUs by the Bus Simulation. A Network FMU shall ignore this operation on the consumer side. `Configuration` operations can be produced multiple times during the runtime of a Network FMU. In context of CAN FD, also a CAN baud rate should be configured by using `Parameter Type = CAN_BAUDRATE`. If configuration parameters are not adjusted by a Network FMU, the Bus Simulation shall choose a default behavior by itself.

The following configuration parameters are defined:

Table 18. Overview of the available configuration parameters.
Parameter	Value	Description
CAN_BAUDRATE	0x01	This code indicates that a CAN baud rate should be configured for the Bus Simulation.
CAN_FD_BAUDRATE	0x02	Allows the configuration of a CAN FD baud rate for the Bus Simulation.
CAN_XL_BAUDRATE	0x03	Allows the configuration of a CAN XL baud rate for the Bus Simulation.
ARBITRATION_LOST_BEHAVIOR	0x04	This code configures the behavior of a Bus Simulation if an arbitration is lost. See Table 19) for possible values.

The following values for the Arbitration Lost Behavior option are defined:

Table 19. Overview of the available Arbitration Lost Behavior values.
Arbitration Lost Behavior	Value	Description
BUFFER_AND_RETRANSMIT	0x01	`Transmit` operations shall be buffered by the Bus Simulation.
DISCARD_AND_NOTIFY	0x02	`Transmit` operations shall be discarded and the specified Network FMU shall be notified by the Bus Simulation via an `Arbitration Lost` operation.

5.5.1.2.7. Status

By using the Status operation, a Network FMU can communicate the current CAN node state to the Bus Simulation. The following information is included within this operation:

Table 20. Detailed description of the Status operation.
Content	Argument	Length	Description
Name	Status
Description	Represents an operation for status handling.
OP Code [hex]	0x41
	OP Code	4 byte	Contains the OP Code (0x41) of the operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: `Length = 9`.
	Status	1 byte	The specified status code, based on the table below.
Behavior	The specified operation shall be produced by Network FMUs and consumed by the Bus Simulation. The operation shall not be routed to other Network FMUs by the Bus Simulation. A Network FMU shall ignore this operation on the consumer side. A Network FMU shall report its status to the Bus Simulation after it changes.

The following status values can be used:

Table 21. Overview of the available status values.
Kind	Value	Description
ERROR_ACTIVE	0x01	Indicates that a simulated CAN controller within the Network FMU has currently the CAN node state: ERROR ACTIVE. If the status is not adjusted by a Network FMU, the Bus Simulation shall choose `ERROR_ACTIVE` by itself for a specified Network FMU.
ERROR_PASSIVE	0x02	Indicates that a simulated CAN controller within the Network FMU has currently the CAN node state: ERROR PASSIVE. This node state is relevant for arbitration, because `ERROR_ACTIVE` and `ERROR_PASSIVE` nodes requires different prioritization. See Section 5.5.1.7 for further details.
BUS_OFF	0x03	Indicates that a simulated CAN controller within the Network FMU has currently the CAN node state: Bus-Off. If a Network FMU communicates the status `BUS_OFF` to the Bus Simulation, the specified Network FMU shall not provide any new Transmission operations to the Bus Simulation. If all Network FMUs, except the `Transmit` operation initiating Network FMU, communicate the status `BUS_OFF`, the Bus Simulation shall not provide a confirmation.

5.5.1.2.8. Wake Up

By using the Wakeup operation, the underlying Bus Simulation can trigger a bus-specific wake up.

Table 22. Detailed description of the Wakeup operation.
Content	Argument	Length	Description
Name	Wakeup
Description	Represents an operation for triggering a bus-specific wake up.
OP Code [hex]	0x42
	OP Code	4 byte	Contains the OP Code (0x42) of the operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: `Length = 8`.
Behavior	The specified operation shall be produced by a Network FMU and distributed to all participants, except the wake-up initiator, of the bus using the Bus Simulation. If a Network FMU does not support wake up, this operation can be ignored on the consumer side.

5.5.1.3. Network Parameters

Using structural parameters, FMUs can be parameterized according to importer specifications. This chapter specifies the structural parameters that each CAN-specific Network FMU shall provide.

5.5.1.3.1. Bus Notification Parameter

For a detailed simulation, the CAN bus behavior regarding acknowledgment, bus errors and arbitration losses must be considered. A Bus Simulation can simulate these effects by sending bus notifications in terms of Confirm-, Bus Error- and Arbitration Lost operations to the Network FMUs.

However, in scenarios where Network FMUs are connected directly to each other, or where the Bus Simulation does not simulate such effects, it must be possible to configure the Network FMU such that it does not wait for any response after a Transmit operation. Therefore, the org.fmi_standard.fmi_ls_bus.Can_BusNotifications parameter is introduced. If the value of the parameter is set to false, the Network FMU must not wait for any response after a Transmit operation ("fire-and-forget"). The default value shall be false to allow the Network FMU to be run natively in each simulation scenario. If the Network FMU shall be configured to handle responses in the form of Confirm-, Bus Error- and Arbitration Lost operations, the org.fmi_standard.fmi_ls_bus.Can_BusNotifications parameter shall be set to true.
[This does not necessarily mean the FMU must fully support CAN error handling or sophisticated arbitration mechanisms. A simple Network FMU might also choose to treat Bus Error or Arbitration operations in a simplified manner, e.g., by treating them as a positive confirmation.]

FMU parameter for the configuration of bus notifications.

    org.fmi_standard.fmi_ls_bus.Can_BusNotifications
        Description:  "Specifies whether the respective Network FMU can rely on a Confirm,
                      Bus Error or Arbitration Lost operation after sending a message."
        Type:         Boolean
        Causality:    structuralParameter
        Variability:  fixed
        Start:        "false"

This structural parameter is mandatory for Network FMUs only. A Bus Simulation (FMU) does not require this structural parameter.

5.5.1.4. Configuration of Bus Simulation

The configuration of the Bus Simulation is done by the Network FMUs itself. For this purpose, the Configuration operation provides several configuration parameters. Configuration operations can be produced multiple times during the runtime of a Network FMU. Because the Bus Simulation shall choose a default behavior, it might be useful in several scenarios that Network FMUs finish configuration before the production of Transmit operations.

5.5.1.4.1. Baud Rate Handling

In order to calculate the time required for the transmission of a bus message, it is necessary to inform the Bus Simulation about the specified baud rate from a Network FMU. This baud rate information can be configured by using CAN_BAUDRATE, CAN_FD_BAUDRATE and CAN_XL_BAUDRATE configuration kind of the Configuration operation. In a CAN FD scenario, both the configuration for CAN_BAUDRATE and for CAN_FD_BAUDRATE shall be carried out. The Bus Simulation can derive the required CAN, CAN FD or CAN XL controller type from the baud rate configurations a Network FMU carried out. If the baud rate information is not adjusted by a specified Network FMU, the Bus Simulation shall choose a default behavior by itself.

5.5.1.4.2. Buffer Handling

By using the ARBITRATION_LOST_BEHAVIOR configuration kind of a Configuration operation, the buffer handling within the Bus Simulation can be adjusted. Using buffer handling is required in arbitration scenarios only and will be described within this context. If the buffering is not adjusted by a specified Network FMU, the Bus Simulation shall choose a default behavior by itself.

5.5.1.5. Transmission and Acknowledge

The Transmit operation represents the sending of a CAN, CAN FD and CAN XL frame. With appropriate options, relevant functionalities can be configured and used on a network abstraction level (e.g., Virtual CAN network ID for CAN XL or Bit Rate Switch for CAN FD). In the real world, flawlessly transmitted CAN frames will be acknowledged by at least one receiver CAN node. To simulate this behavior, the Confirm operations are introduced. In addition, the structural parameter org.fmi_standard.fmi_ls_bus.Can_BusNotifications is defined to support lightweight bus simulations and directly connected Network FMUs.

If org.fmi_standard.fmi_ls_bus.Can_BusNotifications is set to false (default), then Network FMUs must not rely on receiving Confirm operations. In this case, the bus simulation is idealized and takes place in a "fire-and-forget" manner. If a specified Network FMU is depending on Confirm operations and org.fmi_standard.fmi_ls_bus.Can_BusNotifications is set to false, the self confirmation shall be realized internally within the respective Network FMU.

Figure 12 illustrates this communication, whereby FMU 1 transmits network data to FMU 2. Subsequently, FMU 1 self-confirms the transmission internally.

Figure 12. Direct Confirmation of transmitted network data.

For a detailed simulation, the Bus Simulation has to support Confirm operations. In this case, the org.fmi_standard.fmi_ls_bus.Can_BusNotifications parameter of the Network FMUs can be set to true as Network FMUs can rely on receiving Confirm operations.

The following Figure 13 illustrates the behavior, whereby FMU 1 transmits network data to FMU 2 via a Bus Simulation.

can confirmation with bus simulation fmu

Figure 13. Confirmation of transmitted network data via Bus Simulation.

If all Network FMUs, except the one initiating the Transmit operation, communicate the status BUS_OFF, the Bus Simulation shall not provide a confirmation.

The FMI LS BUS Implementer’s Guide contains an example of the possible transmission results and displays them in a diagram.

5.5.1.6. Error Handling

The CAN protocol includes a sophisticated fault confinement mechanism to prevent malfunctioning within CAN nodes. A Transmit Error Counter (TEC) and a Receive Error Counter (REC) represent a historical communication quality metric. To maintain the TEC and REC values, Bus Error operations shall be provided to all Network FMUs by the Bus Simulation. The argument Is Sender shall be set to TRUE for the Network FMU the Transmit operation originated from. The argument Error Flag shall be set to PRIMARY_ERROR_FLAG if the Network FMU detects the transmission error. If a Network FMU changes its current CAN node state, the Status operation shall be provided to the Bus Simulation. When a Network FMU signals the BUS_OFF state to the Bus Simulation, it shall not provide any new Transmit operations in order to simulate a real Bus-Off behavior.

Figure 14. Architectural error handling overview.

The FMI LS BUS Implementer’s Guide contains an example of how to realize CAN error handling based on the Bus Operations specified by this layered standard.

5.5.1.7. Arbitration

Arbitration is an instrument of the CAN standard to resolve the conflict of the simultaneous sending of messages from several CAN nodes without a collision. The arbitration is handled in the Bus Simulation and can be recognized by the fact that the Bus Simulation receives a Transmit operation from several FMUs at the same time. As soon as an arbitration is lost, an Arbitration Lost operation shall be returned to the respective sender within the next Event Mode. As soon as an FMU receives an Arbitration Lost operation, it can independently repeat the corresponding Transmit operation.

Figure 15. Arbitration of two transmissions at the same time.

Within a Configuration operation, the Arbitration Lost Behavior argument can be specified. Once this option is set to BUFFER_AND_RETRANSMIT, the Bus Simulation buffers the frame after losing arbitration and sends it as soon as possible. In this case, it is not necessary for the Network FMU to re-send the respective frame and an Arbitration Lost operation shall not be returned to the specific Network FMU. If the Arbitration Lost Behavior is set to DISCARD_AND_NOTIFY, the specified Network FMU is informed by an Arbitration Lost operation and needs to repeat the corresponding Transmit operation by itself. Arbitration is available in communication architectures with Bus Simulation only, i.e., it is not available for directly connected Network FMUs.

In the case of arbitration, the Bus Simulation must also take the status of the respective Network FMU into account, which is communicated via a Status operation. To simulate the behavior of the CAN Extra Suspend Transmission Time when a CAN node is in Error Passive state, the Bus Simulation shall prefer Network FMUs whose status is ERROR_ACTIVE (see Table 21).

The FMI LS BUS Implementer’s Guide contains examples of the presented arbitration cases and visualizes them using sequence diagrams.

5.5.1.8. Wake Up/Sleep

This standard supports wake up and sleep functionality for the CAN bus. However, the realization of local virtual ECU wake-up and sleeping processes, i.e., the transition to the sleep state as well as the virtual ECU local wake-up process, is considered internal to the FMU implementation. Therefore, only the bus-related aspects are defined in this document.

The CAN-specific wake-up pulse can be simulated by using the Wakeup operation, initiated by one Network FMU. The Bus Simulation shall distribute this operation to all participants on the bus, excluding the wake-up initiator.

Figure 16. Wake up initiated by FMU 1 wakes up FMU 2 and FMU 3 via bus.

5.5.2. LIN

This chapter describes the Layered Standard Bus Protocol for LIN.

5.5.2.1. Overview

To simulate LIN buses, LIN-specific operations are specified based on the Layered Standard Bus Protocol. Overall, the following groups of operations exists:

Transmit: This group of operations is used to simulate a frame transmission. There are three specific operations that represent the different communication options between a LIN Master and one or more LIN Slaves.
Error: This group of operations is used for protocol format errors and to simulate bus failures. For example, the failure of a transmission can be indicated.
Configuration: This operation enables the configuration of bus-specific parameters and options that are required to simulate the bus behavior properly. For example, it allows the specification of the baud rate.
Status: This operation is used by Networked FMUs to inform Bus Simulations about the internal state (Power Off/Initialization/Operation/Sleep) which concerns the reaction on bus errors.
Wake up: LIN supports wake up and sleep scenarios. Normally there are two ways to wake up from sleep mode: a local wake up on a specified wake-up pin, or a wake up on the LIN bus via a LIN specific wake-up pulse. This operation is used to simulate triggering a wake up from bus side.

The following table gives a detailed overview of the available operations. It shows all operations and the arguments they contain.

Table 23. Overview of the available operations for LIN.
Operation Name	Operation Content
Operation Name	OP Code	Length	Specific Content
Format Error	0x00	:= 5 + n (4 byte)	Data (n byte)
Header	0x10	:= 7 (4 byte)	PID (1 byte)	Response Data Length (1 byte)
Response	0x11	:= 8 + DL (4 byte)	PID (1 byte)	Response Error (1 byte)		DL (1 byte)	Data (n byte)
Header Response	0x12	:= 7 + DL (4 byte)	PID (1 byte)	DL (1 byte)	Data (n byte)
Bus Error	0x20	:= 12 (4 byte)	ID (4 byte)	Error Code (1 byte)
Configuration	0x30	<Length> (4 byte)	Kind (1 byte)	Dynamic Part
Status	0x40	:= 6 (4 byte)	Status (1 byte)
Wakeup	0x41	:= 5 (4 byte)	---

5.5.2.2. Operations

This section defines the allowed operations for LIN. The following tables provides an overview of all operations and specifies the position and length of the corresponding arguments, as well as the respective flow direction.

5.5.2.2.1. Transmit

There are three types of Transmit operations, each representing the transmission of a LIN header, a response and a combination of a header and response.

Table 24. Detailed description of the LIN Header operation.
Content	Argument	Length	Description
Name	Header
Description	Represents an operation for the transmission of a LIN header from a LIN Master to LIN slaves.
OP Code [hex]	0x10
	OP Code	1 byte	Contains the OP Code of the specified operation. For this operation the OP Code always has the value 0x10.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. For this operation always applies: `Length = 7`.
	PID	1 byte	The specified protected ID (PID) of the LIN message. The maximum length of a PID is 8-bit.
	Response Data Length	1 byte	The size of the response in byte.
Behavior	The Header operation shall be provided by Network FMUs to initiate the transmission of a LIN header. In case of direct connected Network FMUs (see Section 3.1.1), the FMU importer forwards the operation directly to the receiving Network FMUs. If a Bus Simulation is involved (see Section 3.1.2 and Section 3.1.3), the FMU importer forwards the operation initially to the Bus Simulation, where the operation is distributed with respect to the simulated bus behavior. Depending on the simulation details, the Bus Simulation might response with a `Bus Error` or `Format Error` operation.

Table 25. Detailed description of the LIN Response operation.
Content	Argument	Length	Description
Name	Response
Description	Represents an operation for the transmission of a LIN response from a LIN Slave to the LIN Master.
OP Code [hex]	0x11
	OP Code	1 byte	Contains the OP Code of the specified operation. For this operation the OP Code always has the value 0x11.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. For this operation always applies: `Length = 8 + Data Length`.
	PID	1 byte	The specified protected ID (PID) of the LIN message. The maximum length of a PID is 8-bit.
	Response Error	1 byte	Represents the Response Error field of a LIN frame. For specification the boolean values `TRUE` and `FALSE` (see Table 5) shall be used.
	Data Length	1 byte	Specifies the length of the Data argument in bytes.
	Data	n byte	Stores the given frame data to transfer, whereby the valid length of the data depends on the LIN Format.
Behavior	The Response operation shall be provided by Network FMUs to initiate a response to a given LIN header. In case of direct connected Network FMUs (see Section 3.1.1), the FMU importer forwards the operation directly to the receiving Network FMUs. If a Bus Simulation is involved (see Section 3.1.2 and Section 3.1.3), the FMU importer forwards the operation initially to the Bus Simulation, where the operation is distributed with respect to the simulated bus behavior. Depending on the simulation details, the Bus Simulation might response with a `Bus Error` or `Format Error` operation.

Table 26. Detailed description of the LIN Header Response operation.
Content	Argument	Length	Description
Name	Header Response
Description	Represents an operation for the transmission of a LIN header and response from a LIN Master to LIN slaves.
OP Code [hex]	0x12
	OP Code	1 byte	Contains the OP Code of the specified operation. For this operation the OP Code always has the value 0x12.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. For this operation always applies: `Length = 7 + Data Length`.
	PID	1 byte	The specified protected ID (PID) of the LIN message. The maximum length of a PID is 8-bit.
	Data Length	1 byte	Specifies the length of the Data argument in bytes.
	Data	n byte	Stores the given frame data to transfer, whereby the valid length of the data depends on the LIN Format.
Behavior	The Header Response operation shall be provided by Network FMUs to initiate the transmission of a LIN frame that contains the specified header and response. In case of direct connected Network FMUs (see Section 3.1.1), the FMU importer forwards the operation directly to the receiving Network FMUs. If a Bus Simulation is involved (see Section 3.1.2 and Section 3.1.3), the FMU importer forwards the operation initially to the Bus Simulation, where the operation is distributed with respect to the simulated bus behavior. Depending on the simulation details, the Bus Simulation might response with a `Bus Error` or `Format Error` operation.

5.5.2.2.2. Format Error

Represents a format error that indicates a syntax or content error of receiving operations. See Format Error for definition.

5.5.2.2.3. Bus Error

The Bus Error represents special bus communication errors, which are delivered to the LIN Master node in the network.

Table 27. Detailed description of the Bus Error operation.
Content	Argument	Length	Description
Name	Bus Error
Description	Represents an operation for bus communication error handling.
OP Code [hex]	0x20
	OP Code	1 byte	Contains the OP Code of the specified operation. For this operation the OP Code always has the value 0x20.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. For this operation always applies: `Length = 10`.
	ID	4 byte	The specified ID of the LIN message which triggers the error.
	Error Code	1 byte	The specified error code, basing on the table below.
Behavior	The specified operation shall be produced by the Bus Simulation and consumed by Network FMUs. An Error operation is always a reaction from the Bus Simulation to a `Transmit` operation that was produced by a Network FMU. Out of this Error operations are available in the Composition with dedicated Bus Simulation FMU and Importer with Integrated Bus Simulation communication use case only.

The following codes are allowed to use as Error Code:

Table 28. Overview of the available error states and codes.
State	Error Code	Description
BIT_ERROR	0x01	Represents a bit error. The given error is always related to a specific `Transmit` operation.
CHECKSUM_ERROR	0x02	Represents a CRC error. The error can occurs during a collision of multiple response frames when Event-Triggered-Frames are used. The given error is always related to a specific `Transmit` operation.
IDENTIFIER_PARITY_ERROR	0x03	Represents an Identifier Parity Error. The error can occurs during a collision of multiple LIN headers. The given error is always related to a specific `Transmit` operation.
SLAVE_NOT_RESPONDING_ERROR	0x04	Represents a Slave Not Responding Error. The error can occurs if LIN Slaves does not response to a specified LIN header. The given error is always related to a specific `Transmit` operation.
SYNCH_FIELD_ERROR	0x05	Represents a Inconsistent-Synch Field Error. The given error is always related to a specific `Transmit` operation.
PHYSICAL_BUS_ERROR	0x06	Represents a Physical Bus Error. The given error is always related to a specific `Transmit` operation.

5.5.2.2.4. Configuration

The Configuration operation allows Network FMUs the configuration of the Bus Simulation with parameters like baud rate information and further options. The following information are included within this operation:

Table 29. Detailed description of the Configuration operation.
Content	Argument			Length	Description
Name	Configuration
Description	Represents an operation for the configuration of a Bus Simulation. In detail the configuration of a LIN baud rate is possible. Also the configuration of further options, like LIN Master or LIN Slave representation, is supported by this operation.
OP Code [hex]	0x30
	OP Code			1 byte	Contains the OP Code (0x30) of the operation.
	Length			4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: `Length = 6 + Length of parameter arguments in bytes`.
	Parameter Type			1 byte	Defines the current configuration parameter. Note that only one parameter can be set per `Configuration` operation.
		Parameters
		LIN_BAUDRATE	Baud Rate	4 byte	The specified baud rate value to configure, whereby the specified ranges are defined by the LIN standard. The required unit for the baud rate value is bit/s.
		LIN_NODE_DEFINITION	Node Definition	1 byte	Configures the required node type (Master or Slave) within a Bus Simulation. Possible values are: `LIN_MASTER` and `LIN_SLAVE` (see Table 31).
Behavior	The specified operation shall be produced by a Network FMU and consumed by the Bus Simulation. The operation shall not be routed to other Network FMUs by the Bus Simulation. A Network FMU shall ignored this operation on consumer side. The configuration shall be completed by a specified Network FMU before it produces any `Transmit` operations. The configuration must not be repeated multiple times during the runtime of a Network FMU. A Bus Simulation should stop as soon as more than one `LIN_MASTER` is configured in a network. If required configuration parameters are not adjusted by a Network FMU the Bus Simulation shall choose a default behavior by itself.

The following Kind values are allowed to be used:

Table 30. Overview of the available configuration kinds and values.
Kind	Value	Description
LIN_BAUDRATE	0x01	This code indicates that a LIN baud rate should be configured for the Bus Simulation.
LIN_NODE_DEFINITION	0x02	This code configures the specified node type (Master or Slave) within a Bus Simulation.

The following values for the Arbitration Lost Behavior option are defined:

Table 31. Overview of the available node definition values for LIN.
Node Definition	Value	Description
LIN_MASTER	0x01	Configuration of a LIN Master node within a specified Bus Simulation.
LIN_SLAVE	0x02	Configuration of a LIN Slave node within a specified Bus Simulation.

5.5.2.2.5. Status

By using the Status operation a Network FMU can communicate the current LIN node state of the simulated LIN Controller within the Network FMU to the Bus Simulation. The following information are included within this operation:

Table 32. Detailed description of the Status operation.
Content	Argument	Length	Description
Name	Status
Description	Represents an operation for status handling.
OP Code [hex]	0x40
	OP Code	1 byte	Contains the OP Code of the specified operation. For this operation the OP Code always has the value 0x40.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. For this operation always applies: `Length = 6`.
	Status	1 byte	The specified status code, basing on the table below.
Behavior	The specified operation shall be produced by Network FMUs and consumed by the Bus Simulation. The operation shall not be routed to other Network FMUs by the Bus Simulation. A Network FMU shall ignore this operation on the consumer side. A Network FMU shall report its status to the Bus Simulation after it changes.

The following status values are allowed to use:

Table 33. Overview of the available status values.
Kind	Value	Description
POWER_OFF	0x01	Indicates that a simulated LIN controller within the Network FMU has currently the LIN node state: Power Off.
INITIALIZATION	0x02	Indicates that a simulated LIN controller within the Network FMU has currently the LIN node state: Initialization.
OPERATION	0x03	Indicates that a simulated LIN controller within the Network FMU has currently the LIN node state: Operation.
SLEEP	0x04	Indicates that a simulated LIN controller within the Network FMU has currently the LIN node state: Sleep.

5.5.2.2.6. Wake Up

By using the Wakeup operation the underlying Bus Simulation can trigger a bus-specific wake up.

Table 34. Detailed description of the Wakeup operation.
Content	Argument	Length	Description
Name	Wakeup
Description	Represents an operation for triggering a bus-specific wake up.
OP Code [hex]	0x41
	OP Code	1 byte	Contains the OP Code of the specified operation. For this operation the OP Code always has the value 0x41.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. For this operation always applies: `Length = 5`.
Behavior	The specified operation shall be produced by a Network FMU and distributed to all participants, except the wake-up initiator, of the bus by using the Bus Simulation. If a Network FMU does not support wake-up this operation can be ignored on consumer side.

5.5.2.3. Transmission and Reception

TODO

5.5.2.4. Detection of Collisions

TODO

5.5.2.5. Configuration of Bus Simulation

5.5.2.5.1. Baud Rate Handling

In order to calculate the time required for the transmission of a bus message, it is necessary to inform the Bus Simulation about the specified baud rate from a Network FMU. This baud rate information can be configured by using LIN_BAUDRATE configuration kind of the Configuration operation. If the baud rate information is not adjusted by a specified Network FMU, the Bus Simulation shall choose a default behavior by itself.

5.5.2.5.2. Node Definition

By using the LIN_NODE_DEFINITION configuration kind of a Configuration operation, the specified node type LIN_MASTER or LIN_SLAVE needs to be adjusted. This configuration must be done before the first exchange of Transmit operations. A Bus Simulation should stop as soon as more than one LIN Master is configured in a network.

5.5.2.6. Error Handling

TODO

5.5.2.7. Wake Up/Sleep

This standard supports wake up and sleep for the LIN bus, whereby only the bus-specific parts are taken into account. This means that the realization of local virtual ECU wake-up and sleeping processes are internal parts of the respective FMU, which is not covered by this document. Because entering sleep state is a virtual ECU internal process always within LIN bus, this can be ignored. Also, the virtual ECU local wake-up process is ignored as well. The LIN-specific wake-up pulse can be simulated by using the Wakeup operation. A Wakeup operation is initiated by one Network FMU and shall be distributed to all participants of the bus,except the wake-up initiator, by the Bus Simulation.

Figure 17. Wake up initiated by FMU 1 wakes up FMU 2 and FMU 3 via bus.

5.5.3. FlexRay

TODO

5.5.4. Ethernet

TODO dSPACE

6. Contributions

TODO: Add contributions here

Contributions to this layered standard to the FMI standard are covered by the Corporate Contributors License Agreement (CCLA) of the Modelica Association Project FMI.

References

[PW13] Preston-Werner, T. (2013): Semantic Versioning 2.0.0. https://semver.org/spec/v2.0.0.html
[RFC2119] RFC 2119. https://tools.ietf.org/html/rfc2119

1. In AUTOSAR context this means a driver implementation within the MicroController Abstraction Layer (MCAL)

2. Simulated tasks are executed infinitely fast.

3. For details, refer to Functional Mock-up Interface Specification (fmi-standard.org) chapter 2.2.8 Clocks.