fmi-guides
fmi-guides copied to clipboard
modelica
Changes to "Basic HiL & Sensor HiL Profile"
Regarding: https://modelica.github.io/fmi-guides/main/fmi-profiles/#_basic_hil_sensor_hil_profile
I propose to move "Scheduled Execution Interface" from required to optional.
"New Integer Types" have to be supported anyway, we can remove this.
"Source Code FMUs" and "Binary FMUs for non-Desktop Platforms (e.g. HiL)" should be alternatives, not both have to be supported
Proposal from design meeting 2022-07-26:
- Drop New Integer Types as a separate feature across the board
- Downgrade Scheduled Execution Interface to recommended
Aside: The naming of profiles and explanations should be regularized and enhanced (e.g. point out that the sensors in this profile are perception sensors, etc.).
We see many "classical" HIL applications that do not have perception sensors, e.g. drivelines and servos. If we call those Basic HIL, there is little need for Binary Data Types.
Regarding: https://modelica.github.io/fmi-guides/main/fmi-profiles/#_basic_hil_sensor_hil_profile
I propose to move "Scheduled Execution Interface" from required to optional.
Agreed. Let's do it.
"New Integer Types" have to be supported anyway, we can remove this.
Agreed. Let's remove it. Also in other profiles.
"Source Code FMUs" and "Binary FMUs for non-Desktop Platforms (e.g. HiL)" should be alternatives, not both have to be supported
Same goes for Desktop: Actually "Binary FMUs for Desktop Platforms" makes no sense in this profile. Let's remove it.
Also remove "Binary Data Type Parameters", or at least make it recommended.
Why is there a separate "Sensor Profile"? It could be confusing. For example "OSI-encoded sensor data via binary variables" is an important use case on HIL simulators, too. (Of course "Variable Co-Simulation Communication Step Size" and "Binary FMUs for Desktop Platforms" should not be mandatory)