FMI 3 and OSI
With the FMI 3 binary port, the implementation of OSI interfaces for FMUs (functional mock-up units) will be more robust and replaces an existing work-around (OSMP – OSI Sensor Model Packaging). The binary data type is an opaque binary data type to FMU variables to allow, for instance, the efficient exchange of complex sensor data (OSI) or also field bus data (V-ECU). (Note: The OSI standard itself is discussed in an extra section of this document.)
FMI 3 and V-ECUs
Currently, no standardization project for V-ECUs exists. Definitions for V-ECUs and the need for standardization currently are documented in a PROSTEP white paper: WhitePaper_V-ECU.pdf. The idea is to implement a V-ECU standard as a layered standard on top of FMI 3 to be usable for all kinds of ECU projects (AUTOSAR Classic, AUTOSAR Adaptive, and non-AUTOSAR ECUs).
Besides the FMI 3 binary port for bus data, some more FMI 3 features are important for this layered approach. The FMI 3 “extra directory” adds a new folder in the ZIP archive representing an FMU, providing additional data to travel with the FMU that can be modified by different tools, allowing for layered standards. The FMI 3 “clocks and hybrid cosimulation” feature introduces clocks for synchronization of variable changes across FMUs and allows cosimulation with events.
Thus, the realization of most V-ECU input/output signals with FMI 3.0 will be possible. The following aspects need to be evaluated and then would determine the content for a V-ECU layered standard:
- Bus ports (CAN, LIN, FlexRay, Ethernet):
Maybe possible via FMI 3 binary ports in combination with MIME types for each bus system, but multiple frames per channel must be possible
- Events and callback functions:
Events essential for bus communication or simulated hardware events, for instance; callbacks for data measurement services outside of V-ECU; maybe possible via clocks in FMI 3.0
- Address based access to calibration and measurement variables (with A2L files). Not possible with get/set functions, but via direct memory access; extension of FMI especially for V-ECUs necessary
- Simulation performance:
Events/callbacks via several clocks; if no direct memory access possible, additional memory copies necessary, which reduces performance
FMI 3, OSI, V-ECU, and XIL API
Some new features of FMI 3.0 along with the increasing usage of OSI for environment models (coupling of sensors, agents, etc.) raise the need for the XIL API to extend its functionality accordingly to support MIL, SIL, and HIL testing for future AD applications. Especially the new data types and the binary data type used by OSI need some adaptions to allow them to capture, to record, or to stimulate OSI data. The relation of a V-ECU standard to the XIL API ports (MA, ECUC, ECUM, EES, DIAG, NETWORK) needs to be evaluated. (Note: The XIL API standard itself is discussed in an extra section of this document.)
Study group summary of FMI 3
The findings of the study group do not conflict with the FMI 3 planned features. Nevertheless, the study group has identified the interrelations between the standards FMI 3, OSI, V-ECU, and XIL API as described in this section. The recommendation is to check on the coordination activities between the different standardization projects.