Automotive CAN, LIN, FlexRay, CAN FD, CAN XL and Ethernet are network technologies that have been applied successfully over many years by all automotive OEMs worldwide. Virtualizing electronic control units (ECUs) and then simulating multiple such virtual ECUs requires connecting them using a virtual version of these network technologies.
This layered standard defines what input and output variables and which FMI 3.0 features are used and how to emulate a transport layer for such network traffic. At this point it should be explicitly mentioned that this layered standard not only relates to automotive buses, but can also be extended to buses from other domains in the future.
There are mainly two base use cases envisioned here:
-
Physical Signal Abstraction (or 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 (or 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 and uses a common FMU importer that does not require any special features for simulating buses. The importer only needs to support FMI variables, Clocks, and terminals, which are sufficient to emulate bus communication between the FMUs.
-
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.
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 modelling technologies, as of writing this standard, do not allow practical implementations in terms of modelling time and run time of virtual ECUs that can be used to simulate all realistic bus simulation effects, such as collision and arbitration events.
Conventions used in this document:
-
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.
This layered standard defines requires the use of a layered standard manifest file and Attribute Details. shows the content of fmi-ls-manifest.xml.
| Attribute | Namespace | Value | Description |
|---|---|---|---|
|
|
|
Name of the layered standard in reverse domain name notation. |
|
|
|
Version of the layered standard. This layered standard uses semantic versioning, as defined in [PW13]. |
|
|
|
String with a brief description of the layered standard that is suitable for display to users. |
|
|
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 |
An example of a manifest file for this layered standard is shown below:
link:examples/fmi_ls_bus_manifest_example.xml[role=include]The manifest file shall be stored inside the FMU at the following path: /extra/org.fmi-standard.fmi-ls-bus/fmi-ls-manifest.xml.