|
| 1 | += Binary variables |
| 2 | + |
| 3 | +FMI 2.0 does not directly support the efficient exchange of arbitrary binary data between FMUs. |
| 4 | +OSMP, therefore, introduces the concept of notional binary variables, which are mapped to actual integer variables for use with FMI 2.0. |
| 5 | +Future FMI versions will directly support binary variables compatible with this concept. |
| 6 | + |
| 7 | +A notional binary variable named `<prefix>` is defined using the following conventions: |
| 8 | + |
| 9 | +The name of the notional binary variable given by `<prefix>` shall be a valid structured name according to FMI 2.0. |
| 10 | + |
| 11 | +The FMU shall not contain any other variable that is named `<prefix>`. |
| 12 | +This restriction ensures that there is no conflict between notional binary variables and actual variables. |
| 13 | + |
| 14 | +For each notional binary variable, three actual FMU integer variables shall be defined: |
| 15 | + |
| 16 | +`<prefix>.base.lo`:: |
| 17 | +Lower, meaning least significant, 32-bit address part of the binary data buffer to be passed into or out of the model, cast into a signed 32-bit integer without changing the bit values. |
| 18 | +`<prefix>.base.hi`:: |
| 19 | +Higher, meaning most significant, 32-bit address part of the binary data buffer to be passed into or out of the model, cast into a signed 32-bit integer without changing the bit values. |
| 20 | +Note that this variable is only used for 64-bit platforms. |
| 21 | +For 32-bit platforms, it shall still be present but will always be 0 to support FMUs with 32-bit and 64-bit implementations. |
| 22 | +`<prefix>.size`:: |
| 23 | +Size of the binary data buffer to be passed into or out of the model as a signed 32-bit integer. |
| 24 | +This restricts the maximum size of binary data buffers being passed around to a size less than 2 GB. |
| 25 | + |
| 26 | +The three actual variables shall have matching causality and variability, which will be the causality and variability of the notional binary variable. |
| 27 | + |
| 28 | +The variables shall have a start value of 0, indicating that no valid binary data buffer is available. |
| 29 | +The variables may have a different or no start value if the combination of causality and variability precludes this, for example, for `@variability = fixed` or `@variability = tunable` and `@causality = calculatedParameter`. |
| 30 | + |
| 31 | +Model FMUs shall interpret values of 0 for the merged base address or the size to indicate that no valid binary data buffer is available. |
| 32 | +Models FMUs shall handle this case safely. |
| 33 | + |
| 34 | +The three actual variables shall contain an annotation of the following form in the `<Annotations>` child element of their `<ScalarVariable>` element of the `modelDescription.xml`: |
| 35 | + |
| 36 | +[source,xml] |
| 37 | +---- |
| 38 | +<Tool name="net.pmsf.osmp" xmlns:osmp="http://xsd.pmsf.net/OSISensorModelPackaging"><osmp:osmp-binary-variable name="<prefix>" role="<role>" mime-type="<mime-type>"/></Tool> |
| 39 | +---- |
| 40 | + |
| 41 | +`<prefix>` is the prefix as defined above, and `@role` is either `base.lo`, `base.hi`, or `size`, depending on the variable. |
| 42 | + |
| 43 | +It is an error if there is not exactly one variable of each role for the same name. |
| 44 | + |
| 45 | +The MIME type given in `@mime-type` shall be a valid MIME type specification. |
| 46 | + |
| 47 | +It is an error if the MIME types specified in the annotations for one notional binary variable differ. |
| 48 | + |
| 49 | +In the case of OSI-specified data, the MIME type shall have the following form to indicate that the binary content is conformant to the given OSI version and contains a message of the given type: |
| 50 | + |
| 51 | +[source,xml] |
| 52 | +---- |
| 53 | +application/x-open-simulation-interface; type=<type>; version=x.y.z |
| 54 | +---- |
| 55 | + |
| 56 | +`<type>` shall be the name of an OSI top-level message, excluding the `osi3::` prefix. |
| 57 | + |
| 58 | +The version parameter of the MIME type `application/x-open-simulation-interface` will default to the version specified in the `@osi-version` attribute as part of the top-level `<osmp:osmp>` annotation. |
| 59 | +It is an error if a version number is specified neither as part of the MIME type nor using the `@osi-version` attribute. |
| 60 | + |
| 61 | +The guaranteed lifetime of the binary data buffer pointer transported through the actual variables is defined for each kind of variable, as specified in the following sections. |
| 62 | + |
| 63 | +Generally the lifetime for inputs is from the time they are set to the time the corresponding co-simulation step calculation finishes. |
| 64 | +For outputs the lifetime is extended from the point the output is provided at the end of a co-simulation step until the end of the next co-simulation step. |
| 65 | + |
| 66 | +This convention allows the use of FMUs in simulation engines that have no special support for the protocol buffer pointers: |
| 67 | +The simulation engine can rely on the provided buffer to remain valid from the moment it is passed out of a model until the end of the next co-simulation calculation cycle. |
| 68 | +Thus, the simulation engine does not need to copy the contents in that case, corresponding to zero-copy output for the simulation engine at the cost of double buffering for the model providing the output data. |
| 69 | +It is possible to daisy-chain FMUs with protocol buffer inputs and outputs in a normal simulation engine supporting FMI, and get valid results. |
0 commit comments