Support for non-Modelica enums

[modelica-trac-importer]

Modified by dietmarw on 19 Mar 2012 10:07 UTC Section 3.2 Definition of a Type (fmiType) of "FMI for Model Exchange" says that EnumerationType has integer-valued attributes min and max, and a list of zero or more Items. Comment in the corresponding UML diagram: "First item has value=1, Second value has value=2, etc."

I guess this comment implies that the min attribute has value 1 (at least if there is at least 1 Item), and max is the number of Items. If so, the constraints for min max of an EnumerationType should be made explicit in the spec.

However, I propose to generalize the current rep in a backward compatible way to also support non Modelica enums, e.g. those that start from 0, or contain gaps and duplicate values.

Background: a customer used the FMI to also represent control software compiled from C code. His example used an enum that started from -2 (meaning 2nd reverse gear in this case) and contained gaps.

The proposal is to fully support C enums.

• Item defines an optional integer-valued attribute "value"
• By default, enum vlaues start with 1, unless the first Item defines a different start
• A value attribute in Item resets the value counter to the given value
• min and max are constrained to be the extremal values of the enum defined this way

This would e.g. allow the encoding of the following C enum

enum e_tag{
      a, b, c, d=20, e, f, g=20, h
}var;

The names declared inside the enumeration are constants with int type. Their values are these:

a == 0
b == 1
c == 2
d == 20
e == 21
f == 22
g == 20
h == 21

This enum is of course ugly. But if we do not support such enums, it will be difficult to create automated conversion procedures from C to FMU. A tool could issue a warning here, but it should not silenty use a different value encoding (error prone) or force the user to stick to Modelica enum rules in their C code (difficult if he uses a code generator).

---

Reported by jakob on 25 Dec 2010 13:33 UTC Section 3.2 Definition of a Type (fmiType) of "FMI for Model Exchange" says that EnumerationType has integer-valued attributes min and max, and a list of zero or more Items. Comment in the corresponding UML diagram: "First item has value=1, Second value has value=2, etc."

I guess this comment implies that the min attribute has value 1 (at least if there is at least 1 Item), and max is the number of Items. If so, the constraints for min max of an EnumerationType should be made explicit in the spec.

However, I propose to generalize the current rep in a backward compatible way to also support non Modelica enums, e.g. those that start from 0, or contain gaps and duplicate values.

Background: a customer used the FMI to also represent control software compiled from C code. His example used an enum that started from -2 (meaning 2nd reverse gear in this case) and contained gaps.

The proposal is to fully support C enums.

• Item defines an optional integer-valued attribute "value"
• By default, enum vlaues start with 1, unless the first Item defines a different start
• A value attribute in Item resets the value counter to the given value
• min and max are constrained to be the extremal values of the enum defined this way

This would e.g. allow the encoding of the following C enum

enum e_tag{
      a, b, c, d=20, e, f, g=20, h
}var;

The names declared inside the enumeration are constants with int type. Their values are these:

a == 0
b == 1
c == 2
d == 20
e == 21
f == 22
g == 20
h == 21

This enum is of course ugly. But if we do not support such enums, it will be difficult to create automated conversion procedures from C to FMU. A tool could issue a warning here, but it should not silenty use a different value encoding (error prone) or force the user to stick to Modelica enum rules in their C code (difficult if he uses a code generator).

---

Migrated-From: https://trac.fmi-standard.org/ticket/42

[modelica-trac-importer]

Comment by jakob on 7 Feb 2011 10:09 UTC Related to this: There is a paper on Modelica 2011 about using FMUs to represent control software

Using the Functional Mockup Interface as an Intermediate Format 
in AUTOSAR Software Component Development. 
Thiele, Bernhard; Henriksson, Dan

[modelica-trac-importer]

Comment by otter on 14 Feb 2011 13:57 UTC Decision at meeting on Feb. 8, 2011

1. Enumerations can be additionally defined by a set of tuples(name,value), so a name/value pair. The values must be unique for the same enumeration.This means that most of C-enums are supported (with exception of enums with a non-unique mapping of values). This requires a change in the xml-schema "EnumerationType".

2. The "min/max" values in the xml schema "EnumerationType" do not make sense and are removed.

3. Clarify the meaning of min/max for enumerations in ScalarVariable: It restricts the range of the base enumeration (it also holds for non-monotonic enumerations with "holes").

[modelica-trac-importer]

Comment by otter on 4 Apr 2011 16:29 UTC Included in FMI 2.0 draft

[modelica-trac-importer]

Modified by dietmarw on 19 Mar 2012 10:07 UTC

[modelica-trac-importer]

Modified by dietmarw on 7 Sep 2012 10:18 UTC