Add description of eFMI style production code

[t-sommer]

to allow the integration of source code FMUs into production environments. This information can be extracted from an eFMU (or any other production code) and allows importers to integrate it e.g. as a Simulink C-function block avoiding the overhead of the FMI interface.

The description file could look something like this (work in progress):

<?xml version="1.0" encoding="UTF-8"?>
<fmiProductionCode fmiVersion="3.0">

  <ProductionCodeDescription reusable="false">

    <!-- necessary information to compile the sources -->
    <ProductionCodeSources>

      <IncludePath name="include"/>

      <SourceFile name="block.c"/>
      <SourceFile name="sii_block_interface.c"/>

    </ProductionCodeSources>

    <!-- access to the model's functions, variables, and error signals -->
    <ProductionCodeInterface>

      <HeaderFile name="block.h"/>
      <HeaderFile name="galec_stl.h"/>
      <HeaderFile name="galec_types.h"/>
      <HeaderFile name="sii_block_interface.h"/>

      <Function name="startup" expression="sii_Startup_H697768718_859909373"/>
      <Function name="doStep" expression="sii_DoStep_H697768718_859909373"/>
      <Function name="recalibrate" expression="sii_Recalibrate_H697768718_859909373"/>

      <!-- struct variable that holds the model's data -->
      <BlockState expression="block_state_H697768718_859909373"/>

      <!-- error signals -->
      <Signal name="ErrorSignals" expression="ErrorSignals"/>

      <!-- ports, parameters, constants, and states -->
      <Variable name="M_desired" expression="M_desired"/>
      <Variable name="wRel" expression="wRel"/>
      <Variable name="M_motor" expression="M_motor"/>
      <!-- ... -->

    </ProductionCodeInterface>

  </ProductionCodeDescription>

  <ProductionCodeDescription reusable="true">

    <!-- necessary information to compile the sources -->
    <ProductionCodeSources>

      <PreprocessorDefinition name="REUSABLE_MODEL" value="1"/>

      <!-- ... -->

    </ProductionCodeSources>

    <!-- access to the model's functions, variables, and error signals -->
    <ProductionCodeInterface>

      <HeaderFile name="block.h"/>
      <HeaderFile name="galec_stl.h"/>
      <HeaderFile name="galec_types.h"/>
      <HeaderFile name="mei_block_interface.h"/>

      <Function name="startup" expression="mei_Startup_H697768718_859909373"/>
      <Function name="terminate" expression="mei_Terminate_H697768718_859909373"/>
      <Function name="doStep" expression="mei_DoStep_H697768718_859909373"/>
      <Function name="recalibrate" expression="mei_Recalibrate_H697768718_859909373"/>

      <!-- type of the struct that holds the model's data -->
      <BlockState type="BlockState_H697768718_859909373"/>

      <!-- error signals -->
      <Signal name="ErrorSignals" expression="ErrorSignals"/>

      <!-- ... -->

    </ProductionCodeInterface>

  </ProductionCodeDescription>

</fmiProductionCode>

[chrbertsch]

FMI Design Webmeeting:

Torsten S: e.g. you could import an FMU in Simulink without using the FMI headers or API. This does not replace eFMI, but is the missing link
Torsten B: Would this be a layered standard?
Torsten S: Yes
Torsten B: is this not more an eFMI thing?
Torsten S: It is simpler than eFMI; with my approach you do not have to parse the algorithm code xml for the variable name
Irina: This has nothing to do with the FMI API
Andreas: Such description exist, e.g. A2L, mostly memory layout
Torsten S: I do not want to describe memory layout?
Andreas: Which problem to you want to solve?
Torsten S: I am currently writing a converter from an eFMU to an FMU. Additionally I want to create a C-function block from an eFMU. I would like to store the intermediate result in this new XML file. Pierre thinks it is a good idea.
Torsten: there are more limitations, e.g. a fixed timestep (coming from the eFMU side). There would be no get/set functions for variables.
Torsten S: There are open questoins, e.g. whether mutliple instances shall be allowed.
Karl: I still do not get how this is related to FMI.
Torsten S: This makes only sense, when you go the eFMI route.
Karl: What API would you use? Only the doStep?
Torsten S: Yes ...
Torsten S: this is orthogonal to the approach of getting direct access to the variables via pointers.

--> We need more discussion.