Skip to content

Latest commit

 

History

History
106 lines (85 loc) · 9.41 KB

2____common_concepts.adoc

File metadata and controls

106 lines (85 loc) · 9.41 KB

Common Concepts

Physical Signal Abstraction and Network Abstraction 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.

In both the Physical Signal Abstraction and the Network Abstraction layer, the exchange of network data takes place via FMI variables. In the case of the Physical Signal Abstraction, a separate FMI variable of the respective type is created for each network signal to transfer. The network signals are structured via a PDU and frame hierarchy by using FMI 3.0 Terminals. Within the Network Abstraction, the bus is simulated using a separate, bus-specific protocol. This protocol is exchanged between the various FMUs using binary FMI variables. Since network communication is not continuous but time discrete, FMI 3.0 Clocks are used to indicate when network data is sent or received.

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.

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.

General Recommendations

If triggered output Clocks are used, the importer must ensure to schedule and potentially roll-back FMUs that have advanced their fmi3DoStep past such a (surprising) triggered Clock activation from another FMU. It is strongly recommended to avoid using triggered output Clocks and to instead use time-based Clocks to avoid these complications and potential performance problems.

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.

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:

architecture direct connection
Figure 1. 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.

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.

architecture bus simulation fmu
Figure 2. 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 depend 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.

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.

architecture bus simulation importer
Figure 3. 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 formats, such as manufacturer-specific ones, into a bus simulation.

Provided C-API

Besides the textual specification for FMUs with bus support, this layered standard also provides 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 for common Bus Operations. These header files apply to all supported bus types of the layered standard.

  • fmi3LsBusUtil.h provides common utility macros and structures for all supported bus types.

  • fmi3LsBusCan.h provides macros, types and structures of Bus Operations for CAN, CAN FD and CAN XL.

  • fmi3LsBusUtilCan.h provides CAN, CAN FD and CAN XL explicit utility macros.

  • fmi3LsBusFlexRay.h provides macros, types and structures of Bus Operations for FlexRay.

  • fmi3LsBusUtilFlexRay.h provides FlexRay explicit utility macros.