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