Layered Standard to represent maps and curves

[chrbertsch]

@klausschuch had presented an initial draft at a previous meeting. Could you please provide more information?

[klausschuch]

We at AVL currently use a vendor annotation to represent nd-lookup tables.
I guess the simplest way to present our approach is by a snippet of a modeldescription.xml of a FMI2.0 FMU:

<VendorAnnotations>
  <Tool name="AVL_SDT">
    <AVLAnnotations>
      <RegularMaps>
        <RegularMap name="map2d">
          <Domains>
            <Domain name="x" input="in_2d_x" />
            <Domain name="y" input="in_2d_y" />
          </Domains>
          <Codomains>
            <Codomain name="v" />
          </Codomains>
        </RegularMap>
      
        <RegularMap name="lookup1d">
          <Domains>
            <Domain name="d" input="in_1d" />
          </Domains>
          <Codomains>
            <Codomain name="cd" />
          </Codomains>
        </RegularMap>
      </RegularMaps>
    </AVLAnnotations>
  </Tool>
</VendorAnnotations>

<ModelVariables>
  <!-- 01 --><ScalarVariable name="x[1]" valueReference="0" causality="parameter" variability="tunable"> <Real start="2.0"/> </ScalarVariable>
  <!-- 02 --><ScalarVariable name="x[2]" valueReference="1" causality="parameter" variability="tunable"> <Real start="3.0"/> </ScalarVariable>

  <!-- 03 --><ScalarVariable name="y[1]" valueReference="2" causality="parameter" variability="tunable"> <Real start="10.0"/> </ScalarVariable>
  <!-- 04 --><ScalarVariable name="y[2]" valueReference="3" causality="parameter" variability="tunable"> <Real start="25.0"/> </ScalarVariable>
  <!-- 05 --><ScalarVariable name="y[3]" valueReference="4" causality="parameter" variability="tunable"> <Real start="30.0"/> </ScalarVariable>

  <!-- 06 --><ScalarVariable name="v[1,1]" valueReference="5"  causality="parameter" variability="tunable"> <Real start="11" /> </ScalarVariable>
  <!-- 07 --><ScalarVariable name="v[1,2]" valueReference="6"  causality="parameter" variability="tunable"> <Real start="12" /> </ScalarVariable>
  <!-- 08 --><ScalarVariable name="v[1,3]" valueReference="7"  causality="parameter" variability="tunable"> <Real start="13" /> </ScalarVariable>
  <!-- 09 --><ScalarVariable name="v[2,1]" valueReference="8"  causality="parameter" variability="tunable"> <Real start="21"/> </ScalarVariable>
  <!-- 10 --><ScalarVariable name="v[2,2]" valueReference="9"  causality="parameter" variability="tunable"> <Real start="22"/> </ScalarVariable>
  <!-- 11 --><ScalarVariable name="v[2,3]" valueReference="10" causality="parameter" variability="tunable"> <Real start="23"/> </ScalarVariable>

  <!-- 12 --><ScalarVariable name="d[1]" valueReference="11" causality="parameter" variability="tunable" > <Real start="10.0"/> </ScalarVariable>
  <!-- 13 --><ScalarVariable name="d[2]" valueReference="12" causality="parameter" variability="tunable" > <Real start="20.0"/> </ScalarVariable>
  <!-- 14 --><ScalarVariable name="d[3]" valueReference="13" causality="parameter" variability="tunable" > <Real start="25.0"/> </ScalarVariable>
  <!-- 15 --><ScalarVariable name="d[4]" valueReference="14" causality="parameter" variability="tunable" > <Real start="30.0"/> </ScalarVariable>

  <!-- 16 --><ScalarVariable name="cd[1]" valueReference="15" causality="parameter" variability="tunable" > <Real start="10.0"/> </ScalarVariable>
  <!-- 17 --><ScalarVariable name="cd[2]" valueReference="16" causality="parameter" variability="tunable" > <Real start="20.0"/> </ScalarVariable>
  <!-- 18 --><ScalarVariable name="cd[3]" valueReference="17" causality="parameter" variability="tunable" > <Real start="30.0"/> </ScalarVariable>
  <!-- 19 --><ScalarVariable name="cd[4]" valueReference="18" causality="parameter" variability="tunable" > <Real start="40.0"/> </ScalarVariable>

  <!-- 20 --><ScalarVariable name="in_2d_x" valueReference="19" causality="input"  variability="discrete" > <Real start="2.0"/> </ScalarVariable>
  <!-- 21 --><ScalarVariable name="in_2d_y" valueReference="20" causality="input"  variability="discrete" > <Real start="10.0"/> </ScalarVariable>
  <!-- 22 --><ScalarVariable name="out_2d"  valueReference="21" causality="output" variability="discrete" > <Real/> </ScalarVariable>

  <!-- 23 --><ScalarVariable name="in_1d"  valueReference="22" causality="input"  variability="discrete" > <Real start="10.0"/> </ScalarVariable>
  <!-- 24 --><ScalarVariable name="out_1d" valueReference="23" causality="output" variability="discrete" > <Real/> </ScalarVariable>
</ModelVariables>

Here two 1d-arrays and one 2d-array (the building blocks) are grouped into one 2d-lookup table called "map2d".
These building blocks are defined via naming convention. The same concept would work with native fmi3.0 variables representing arrays.

[t-sommer]

Possible names for the XML elements/attributes:

• regular map, lookup table, array
• codomain, value, data, ordinate, table
• dimension scale, domain, abscissa, applicate, axis, breakpoints

[chrbertsch]

We should aim at being compatible with ASAM Standards such as https://www.asam.net/standards/detail/cdf/ .
As these are not free, we should discuss with ASAM.

[andreas-junghanns]

There are a number of standards that deal with multi-dimensional arrays and unfortunately, they often disagree on how to represent these objects. One more is ASAP2 (a2l), or PAR, DCM, ... we should discuss the "compatibility", but not be discouraged, if we cannot find a good solution. We just might have to pick one of the ways and then live with that decision.

[TorstenBlochwitz]

I created the repository https://github.com/modelica/fmi-ls-struct in which the development will take place.

[t-sommer]

This is what the definitions in https://github.com/klausschuch/Reference-FMUs/blob/lookup_tables/LookupMaps/FMI3.xml would look like in a separate file:

<?xml version="1.0" encoding="UTF-8"?>
<fmiRegularMaps version="1.0">

  <RegularMap name="map2d">
    <Domain name="x" input="map_x"/>
    <Domain name="y" input="map_y"/>
    <Codomain name="v"/>
  </RegularMap>

  <RegularMap name="lookup1d">
    <Domain name="d" input="curve_x"/>
    <Codomain name="cd"/>
  </RegularMap>

</fmiRegularMaps>

[t-sommer]

We should also consider maps in the style of Modelica.Blocks.Tables.CombiTable1Ds where multiple outputs are not provided as separate variables but stored in the second dimension of the co-domain.

[edit]: Further information that might be important:

• interpolation and extrapolation method (typically as an Enumeration variable)
• "bounding curves" that define the limits of the map (e.g. max. power for an inverter or max. torque for an ICE map)

[chrbertsch]

FMI Design meeting:

Christian: What does "regular" mean?
Torsten: monotonic inputs, there could be steps. Not equally spaced
Christian: is there any information on the interpolation behavior? (e.g. linear)
Torsten: not yet.
Torsten: We could create a draft xsd. I could create a prototype for export from Simulink.

[klausschuch]

We should also consider maps in the style of Modelica.Blocks.Tables.CombiTable1Ds where multiple outputs are not provided as separate variables but stored in the second dimension of the co-domain.

An FMU that contains such a CombiTable1Ds object could still expose several parameter Variables to be used as co-domains.

I think, we could either
a) allow several Codomains in an RegularMap:

<RegularMap name="map2d">
  <Domain name="x" input="map_x"/>
  <Domain name="y" input="map_y"/>
  <Codomain name="v1"/>
  <Codomain name="v2"/>
</RegularMap>

or b) allow shared axes (preferred, this can be aligned with a2l)

<RegularMap name="map2d_v1">
  <Domain name="x" input="map_x"/>
  <Domain name="y" input="map_y"/>
  <Codomain name="v1"/>
</RegularMap>
<RegularMap name="map2d_v2">
  <Domain name="x" input="map_x"/>
  <Domain name="y" input="map_y"/>
  <Codomain name="v2"/>
</RegularMap>

• interpolation and extrapolation method (typically as an Enumeration variable)

If an FMU-exporter wants to let the user decide how the data is used (i.e., which interpolation method), the FMU should expose parameters for this.
We could just link such parameters to the RegularMap but don't define any meaning for it.
It basically just tells the importer that it would be nice to show these parameters as related to the regular map.

<RegularMap name="map2d">
  <Domain name="x" input="map_x"/>
  <Domain name="y" input="map_y"/>
  <Codomain name="v"/>
  <RelatedParameter name="MyInterpolMechanism">
  <RelatedParameter name="Interpol.poly.order"/>
</RegularMap>
...
<TypeDefinitions>
  <EnumerationType name="AvailableMechanisms">
    <Item name="const" value="0">
    <Item name="linear" value="1">
  </EnumerationType>
</TypeDefinition>
...
<Int32 name="Interpol.poly.order" causality="parameter" variability="tunable" start="1" />
<Enumeration name="MyInterpolMechanism" declaredType="AvailableMechanisms" causality="parameter" variability="tunable" start="0"/>

• "bounding curves" that define the limits of the map (e.g. max. power for an inverter or max. torque for an ICE map)

Wouldn't such constraints just be defined at the linked parameter Variable by defining a min and/or max attribute?
Or should it be more detailed? We would then need constant Variables of the same size as the codomain and "link" them to the RegularMap.

[klausschuch]

Web-Meeting 7th March 2023:

@TorstenBlochwitz brought up the idea to have a more general xml element Record. The Record kind could be specified by an attribute kind. This would be similar concept as for Terminals.
The RegularMap could be a Record with a certain kind attribute.
Example:

<Record kind="LookupTable" name="my2dmap">
  <Variable kind="Domain" name="x" input="map_x" />
  <Variable kind="Domain" name="y" input="map_y" />
  <Variable kind="Codomain" name="v" input="map_y" />
  <Variable kind="Other" name="MyInterpolMechanism" />
</Record>

A tool that doesn't care about regular maps could still show the parts of a Record as a group (similar to the structural naming convention).

A grouping of Variables without any further meaning could be done with Records without a kind attribute or by a different kind attribute:

<Record name="mystruct" >
  <Variable name="a" />
  <Variable name="b" />
  <Variable name="c" />
</Record>
<Record name="mystruct_nested" >
  <Variable name="x" />
  <Variable name="y" />
  <Record name="mystruct" />
</Record>

Discussion about further parameters of a lookup table like inter-/extrapolation types.
This could either be just a RelatedParameter without any further meaning (as mentioned in a comment before) or the different types could be specified (or better reference a standard). The importing tool could then for example show the surface of the lookuptable.

@andreas-junghanns pointed out that more could be done with this info. For example the user might want to give values on a different grid than the FMU exports.
@klausschuch The FMU should just expose structural parameters to allow the resizing of the involved arrays.
@andreas-junghanns: some exporters will not be able to support this, user will expect the importer to handle this

@t-sommer mentioned that we should cover the modelica specific CombiTable1Ds (see https://www.maplesoft.com/documentation_center/online_manuals/modelica/Modelica_Blocks_Tables.html#Modelica.Blocks.Tables.CombiTable1Ds)

@klausschuch: The FMU export could hide the internals and still export a variable for the first time column and a Variable for each other column and then just combine this in a RegularMap.
Or we could add an index to the RegularMap (I don't think this is a good idea):

<RegularMap name="myCombiTable1Ds">
  <Domain name="v" input="time" index="0"/>
  <Codomain name="v" index="1"/>
  <Codomain name="v" index="2"/>
  <Codomain name="v" index="3"/>
  <Codomain name="v" index="4"/>
</RegularMap>

[klausschuch]

@TorstenBlochwitz What would be the main benefit of such a generic grouping of variables as records in comparison to the already available (and still available) structural naming convention using dots?

[TorstenBlochwitz]

@klausschuch : The structural naming convention requires parsing of the names, which is not really a nice concept. More imporatnt: A generic record approach allows to add additional semantics to groups of variables, which in case of utilizing the naming convention must be given to each of the variable belonging to such a record.

[TorstenBlochwitz]

The biggest advantage of using a generic record approach compared to a special syntax only for look-up-tables is for importers. In this way, importers have to implement the treatment of such records only once. Tools which do not provide a high sophisticated GUI for look-up tables simply keep the parameters belonging to this group together, which is definitely of some help for the user. The same mechanism would work for records of parameters and other applications we don't know yet.

There are lots of different look-up table implementations outside. The definition of a generic look-up table thing might be a lot of work. No importer will ever support all kinds of look-up tables. That's why, from my point of view, utilizing a more general concept from the beginning might be useful.

[t-sommer]

Here is a Modelica model that in contains all table blocks from the MSL. I'm not sure if we can (and should) consider them because of the messy way the parameters are provided (i.e. scales as part of the data, no units, etc.).

model ModelicaTables
  Modelica.Blocks.Tables.CombiTable1Ds combiTable1Ds(
    table=[0,0.1,1.1; 1,0.3,1.3; 2,0.2,1.2],
    smoothness=Modelica.Blocks.Types.Smoothness.LinearSegments,
    extrapolation=Modelica.Blocks.Types.Extrapolation.HoldLastPoint,
    verboseExtrapolation=true)
    annotation (Placement(transformation(extent={{-10,120},{10,140}})));
  Modelica.Blocks.Tables.CombiTable1Dv combiTable1Dv(
    table=[0,0,2; 1,1,1; 2,4,5],
    smoothness=Modelica.Blocks.Types.Smoothness.ContinuousDerivative,
    extrapolation=Modelica.Blocks.Types.Extrapolation.LastTwoPoints,
    verboseExtrapolation=true)
    annotation (Placement(transformation(extent={{-10,80},{10,100}})));
  Modelica.Blocks.Tables.CombiTable2Ds combiTable2Ds(
    table=[0.0,0,1,2; 0,0,0,0; 1,0,1,2; 2,0,2,4],
    smoothness=Modelica.Blocks.Types.Smoothness.MonotoneContinuousDerivative1,
    extrapolation=Modelica.Blocks.Types.Extrapolation.Periodic)
    annotation (Placement(transformation(extent={{-10,40},{10,60}})));
  Modelica.Blocks.Tables.CombiTable2Dv combiTable2Dv(
    n=2,
    table=[0.0,0,1,2; 0,0,0,0; 1,0,1,2; 2,0,2,4],
    smoothness=Modelica.Blocks.Types.Smoothness.MonotoneContinuousDerivative2,
    extrapolation=Modelica.Blocks.Types.Extrapolation.NoExtrapolation)
    annotation (Placement(transformation(extent={{-10,0},{10,20}})));
  Modelica.Blocks.Sources.TimeTable timeTable(
    table=[0,1; 1,3; 2,2],
    timeScale=1,
    offset=1,
    startTime=1,
    shiftTime=1)
    annotation (Placement(transformation(extent={{-10,-40},{10,-20}})));
  Modelica.Blocks.Sources.CombiTimeTable combiTimeTable(
    table=[0,1; 1,3; 2,2],
    smoothness=Modelica.Blocks.Types.Smoothness.ContinuousDerivative,
    extrapolation=Modelica.Blocks.Types.Extrapolation.Periodic,
    timeScale=1,
    offset={0},
    startTime=0,
    shiftTime=1)
    annotation (Placement(transformation(extent={{-10,-80},{10,-60}})));

// ...
end ModelicaTables;

[t-sommer]

A Simulink 2-d lookup table block exported with FMI Kit's grtfmi.tlc looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<fmiModelDescription
  fmiVersion="2.0"
  guid="{3f6f5fd6-ed86-452c-9658-ebc2a1d5453f}"
  modelName="tables"
  generationTool="Simulink 9.8 (R2022b) 13-May-2022 with FMI Kit 3.0 (grtfmi.tlc, FixedStepDiscrete, 0.2 s)"
  generationDateAndTime="2023-03-23T16:24:19"
  author="TSR2"
  version="1.2">

  <CoSimulation
    modelIdentifier="tables"
    canBeInstantiatedOnlyOncePerProcess="true"
    canHandleVariableCommunicationStepSize="true">
  </CoSimulation>

  <DefaultExperiment
    startTime="0.0"
    stopTime="10.0"
    stepSize="0.2"/>

  <ModelVariables>

    <!-- Parameters -->
    <ScalarVariable name="Parameters.uDLookupTable_tableData[0,0]" valueReference="1" causality="parameter" variability="tunable">
      <Real start="4.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_tableData[1,0]" valueReference="2" causality="parameter" variability="tunable">
      <Real start="16.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_tableData[2,0]" valueReference="3" causality="parameter" variability="tunable">
      <Real start="10.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_tableData[0,1]" valueReference="4" causality="parameter" variability="tunable">
      <Real start="5.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_tableData[1,1]" valueReference="5" causality="parameter" variability="tunable">
      <Real start="19.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_tableData[2,1]" valueReference="6" causality="parameter" variability="tunable">
      <Real start="18.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_tableData[0,2]" valueReference="7" causality="parameter" variability="tunable">
      <Real start="6.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_tableData[1,2]" valueReference="8" causality="parameter" variability="tunable">
      <Real start="20.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_tableData[2,2]" valueReference="9" causality="parameter" variability="tunable">
      <Real start="23.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_bp01Data[0]" valueReference="10" causality="parameter" variability="tunable">
      <Real start="1.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_bp01Data[1]" valueReference="11" causality="parameter" variability="tunable">
      <Real start="2.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_bp01Data[2]" valueReference="12" causality="parameter" variability="tunable">
      <Real start="3.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_bp02Data[0]" valueReference="13" causality="parameter" variability="tunable">
      <Real start="1.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_bp02Data[1]" valueReference="14" causality="parameter" variability="tunable">
      <Real start="2.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_bp02Data[2]" valueReference="15" causality="parameter" variability="tunable">
      <Real start="3.0"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_maxIndex[0]" valueReference="16" causality="parameter" variability="tunable">
      <Integer start="2"/>
    </ScalarVariable>
    <ScalarVariable name="Parameters.uDLookupTable_maxIndex[1]" valueReference="17" causality="parameter" variability="tunable">
      <Integer start="2"/>
    </ScalarVariable>

    <!-- Inputs -->
    <ScalarVariable name="In1" valueReference="18" causality="input">
      <Real start="0"/>
    </ScalarVariable>
    <ScalarVariable name="In2" valueReference="19" causality="input">
      <Real start="0"/>
    </ScalarVariable>

    <!-- Outputs -->
    <ScalarVariable name="Out1" valueReference="20" causality="output">
      <Real/>
    </ScalarVariable>

  </ModelVariables>

  <ModelStructure>
    <Outputs>
      <Unknown index="20"/>
    </Outputs>
    <InitialUnknowns>
      <Unknown index="20"/>
    </InitialUnknowns>
  </ModelStructure>

</fmiModelDescription>

[chrbertsch]

(FMI Design Webmeeting)

Klaus: the most important questions is, whether to have something special for maps and curves, or have something more general.
Andreas: The records are similar to terminals.
Antoine: We can have parameters in terminals already
Andreas: why not use terminals? We could backport them? We could define new terminal kinds.
Klaus: matching rules not make sense. We would re-use only a part. E.g. an Icon does not really make sense (e.g. where to put it)
Andreas: Matching would not have a meaning.
Torsten B: Icons are optional. Terminals are not a good way to express look-up tables.
The general idea of "record" came to late for the "terminals"
Torsten: The benefit is simplicity for importers. A look-up table is mainly a group of variables and parameters. Why not define a record similar to terminals.
Klaus: we already have the naming convention.
Andreas: the ideas are very similar, but the terminals are already out.
With the records one could do many things (e.g. create a layered standard on top of layered standards)
Klaus: even the matching rules could make sense
Torsten B.: parameter would have to be equal.
I would keep terminals. using them for look-up tables feels strange.

Poll: Should we

1. define something specific for maps and curves,
2. define records and specialize them for maps and curves, or
3. use terminals and specialize them for maps and curves
   (multiple votes possible)

1 ) Klaus, Antoine, Masoud, Daniel, Oliver (5)
2 ) Andreas, Torsten B., Antoine, Christian, Jumayev, Jan, Oliver, Klaus (8)
3 ) -
abstain: -

Andreas: which option would hinder us most?
Torsten: If we choose 1), and want to define records, we would have to start again and would have 3 layered standards
Klaus: if we choose 2), we have to comment on the naming convention.

[chrbertsch]

Discussion about further parameters of a lookup table like inter-/extrapolation types. This could either be just a RelatedParameter without any further meaning (as mentioned in a comment before) or the different types could be specified (or better reference a standard). The importing tool could then for example show the surface of the lookuptable.

@andreas-junghanns pointed out that more could be done with this info. For example the user might want to give values on a different grid than the FMU exports.

Klaus: this looks comlicated.
Andreas: this is not very important.
Christian/Klaus: some tools could agree on common additinal parameter names. (e.g Modelica tools for combitables).
Klaus: the records could have additional attributes.
Torsten B: We could give recommendations how enums/strings for certain inter/extrapolation could look like

(Difference to A2L, XCP)

Andreas: Are there quantities,... in this proposal
Klaus: ... we could do this with our solution
Klaus: this proposal is more abstract than the A2L
Andreas: the creation of such an FMU is more complicated, this has to be done at export time.

[chrbertsch]

FMI-Design Meeting (Klaus, Irina, Christian, Torsten S.)
(old example from Klaus with annotations https://github.com/klausschuch/Reference-FMUs/blob/lookup_tables/LookupMaps/FMI3.xml)

With both approaches we can reach what we want for look-up tables.
Which way to follow has to be decided in a larger group.

Main concerns for "Record" approach:

• overlap w.r.t structured naming convention (If we have both structured naming convention, and records: which one has preference?)
  Options:

1. if using Records: require NamingConventions=flat
2. Allow NamingConventions=structured, allow only Records with kind=RegularMap
3. allow parallel usage of NamingConvention=structured and use of Records (can lead ambiguities; how to display this?)
   Ask interested parties in Records: would they export all structural information via records? (Would they use dot-notation for variables also in the case of using Records? Or would they define a new hierarchy

• few xsd checks possible, procedural checks needed

Issues for both approaches:

• Uniqueness for names of RegularMaps: unique w.r.t. RegularMaps and ModelVariables (of the FMU)
  (consequence: have to follow structured naming convention, if VariableNamingConvention=structured)
• Optional: displayName for for referenced Variabls (similar concept as for memberName of Terminals)
• Can we define several co-domains in A) one table or B) several tables?
  B) Preferred. (grouping of several regular maps could also be reached with structured naming convention map.map2d_v1 in Layered Standard to represent maps and curves #1 (comment))
• Use names: "RegularMap", "Domain", "Codomain", "RelatedVariable"
• Add optional description (to RegularMap / Record)

[chrbertsch]

Discussion in the larger group at the FMI Design meeting:

Why not use the terminals of the core standard instead of a new concept of "records" that does similar things?

[chrbertsch]

(Discussion: Klaus, Irina, Christian)

• We would prefer using Terminals instead of defining an almost identical concept Records
• Technically this seems feasible
• Introductory text in https://fmi-standard.org/docs/3.0/#fmiTerminalsAndIcons talks about "semantic groups of variables to ease connecting compatible signals". "Signals" are not defined anyway and we could clarify this and/or make this non-normative.

A first draft could looks like:

<fmiTerminalsAndIcons fmiVersion="3.0">
  <Terminals>
    <Terminal name="a.b.c.map"" terminalKind="org.fmi-standard.fmi-ls-struct.regularMap" matchingRule="plug">
      <TerminalMemberVariable variableName="a.b.c.map_x" memberName="x" variableKind="org.fmi-standard.fmi-ls-struct.domain" />
      <TerminalMemberVariable variableName="a.b.c.map_y" memberName="y" variableKind="org.fmi-standard.fmi-ls-struct.domain" />
      <TerminalMemberVariable variableName="x.y.map_z" memberName="z" variableKind="org.fmi-standard.fmi-ls-struct.codomain" />
      <TerminalMemberVariable variableName="InterpolMechanism" memberName="InterpolationOptions" variableKind="org.fmi-standard.fmi-ls-struct.interpolationOptions" />
    </Terminal>
  </Terminals>
</fmiTerminalsAndIcons>

tbd. What to define what "matching" means in this context, define also "None" for matching rule.

[pmai]

The draft PR for clarification of terminals in 3.0.1 is modelica/fmi-standard#1885, please add further needed clarifications and add feedback...

[chrbertsch]

Discussion Web-meeting

Torsten B.: Usage of Terminals for parameter records and maps and curves seems far-fetched. Maps and curves helps users to display them.
Pierre: What is the semantic difference?
Torsten B.: This is not generic
Pierre: We switch between solving specific solution for maps and curves and generic solution for records. What are our goals?
Torsten S: Terminals and Icons are a different view on variables. It would not be good to have different of such views.
Klaus: and we have the structured naming convention ...
Klaus: we have to define in which name space the names are unique.
Pierre: Which problems do we want to solve?

Problem description:

• realize loop-up tables (maps, curves): this is quite clear, and solution approaches are available
• parameter grouping (see slide 8 of https://github.com/modelica/fmi-design/blob/master/Meetings/2022/2022-10-25_27-F2F-FMI-Design-Meeting/Material/2022_10_25_LayeredStandardsFMI_Ideas_ESI.pdf)

Pierre: Look-up tables have more specific semantic than grouping of parameters.
Torsten B.: Look-up tables are more specific and have more semantic
Pierre: The generic problem is solved by Terminals. Parameter Groups are related to connections (Parameter group equality). This fits also to SSP view on parameters.
Pierre: if we would use the Terminals Concept, we would have to check the standard text.
Klaus, Pierre: we have to fulfill what is written in 3.0
Irina: In a future FMI version we could replace Terminals conept with Records, we should not define a parallel construct to Terminals
Klaus: with a specific format we could have XSD checking
Pierre: With XML1.1 this would also be possible for records and Terminals

Poll: Should we

1.) define something specific for maps and curves,
2.) define records and specialize them for maps and curves, or
3.) use terminals and specialize them for maps and curves

(multiple votes possible)
(in brackets: can live with this proposal, is not my favourite)

1: (Torsten B.) (Pierre) Klaus, (Irina), (Christian), (Matthias), (Kahramon)
2: Torsten B, (Klaus)
3: Andreas, Christian, (Matthias), Patrick, Timo, (Klaus), Daniel, Irina, Pierre
Abstain: Torsten S.

Next steps:
Create proposal for look-up tables and parameter groups with Terminals, and then decide.

Klaus: what has to be changed in 3.0.x?
Pierre: At least we could include warning ("This will be clarified in 3.0.2")
Klaus: e.g. "signals" is undefined.
Torsten: TerminalKind, Matching rules and Variables kinds can be used for specialization.

Pierre: I will start a PR to clarify Signals ... i.e. --> e.g.
Torsten: Sentencen on causality is important, as some users though on acausal connectors

Start with layered standard:
Pierre: start with "prosa", create both XSD 1.0 and XSD 1.1
Klaus: add attribute values in XSD ?
Pierre: have to check if additional 1.1 schema can be applied to existing schema ...
Pierre: we could also provide a new schema for everything, not so good.

Klaus: I will change our examples on this variant.
Christian: I will start with a draft PR for the "prosa".
Klaus: We will start with the maps and curves, "records" later

Klaus: displayNames vs. MemberNames? There is no "any" in XSD?
Pierre: über Annotations?
Klaus: ... one can realize it differently.

Next meeting: in two weeks web meeting

[chrbertsch]

I think this issue can be closed, as IMHO the poins are all reflected in the current draft