Handling of file access and pathname parameters

[pmai]

Fairly often string parameters are used to transport file pathnames into an FMU, that the FMU will then use to access files in the file system, even though there is no guarantee that file access is available, or that there is a defined way to locate the file using the path being passed into the FMU.

Use cases include instances where only the FMU is capable of parsing/handling the file content (e.g. encrypted or otherwise specialized parameter sets included or supplied together with the FMU or from the same source as the FMU).

This whole approach is of course very fragile, and works more despite than because of reality. Especially since the importer is usually not aware of this mechanism (as it is not in any way distinguishable from any other string parameters), there is little the importer can do to ensure this works or to at least provide useful diagnostics.

It should be discussed how to handle these cases going forward: Using binary parameters it would not be possible to easily supply the file contents in a portable manner, however again no mechanism exists for the importer to detect such parameters and e.g. provide access to the relevant file contents.

Alternatively clearly designating path parameters and providing some rules on how file access on platforms capable of providing such would be another approach.

This issue just serves to capture this issue, not to already supply preferred solutions. Solutions might be realized as either FMI 3.1 extensions and/or layered standards.

[chrbertsch]

FMI Design Web-Meeting:

Pierre: There are many use cases in system composition, where FMUs get parameterized by a file. People take just string parameters. This is opaque to the simulation environment. E.g. relative filenames are unclear. Problematic to package such FMUs e.g. as SSP. (FMI does not give guarantee to give access to a file system)
Torsten: CMake has a solution (String with an annotation), could be an inspiration