Removing listed limitations (I am an author of the cited paper). They do not hold for FMI in general but only when porting FMUs to embedded software. The limitation on data types do no longer hold for FMI 3
| title=FMI for physical models on automotive embedded targets
|author1=Christian Bertsch |author2=Jonathan Neudorfer |author3=Elmar Ahle |author4=Siva Sankar Arumugham |author5=Karthikeyan Ramachandran |author6=Andreas Thuy | publisher=Proceedings of the 11th International Modelica Conference)
| accessdate=2015-09-21}}</ref>
* Memory - Parameters, states, inputs, and outputs are not exposed directly to the outside, which is in contrast to how ECU software is normally organized with respect to memory to allow transparency, simplicity, and efficiency.
* Event handling - Events could increase the runtime for real-time systems in an unpredictable manner.
* Potentially dangerous features can be included on ECU - Some features that make sense for offline simulations should not be present on the ECU. Examples of features that are either supported or not explicitly forbidden in the FMI include logging and I/O operations such as print().
* Data type support - More supported data types are necessary for optimized code. For example, there is not a way to distinguish between a uint8 and uint32 variable.
