Simplification of the modeling of Enumerations, like "FEMALE" and "MALE"

[foprs]

Modeling of enumeration values for properties is a hard job with the metamodel (when creating Submodel Templates).

As I understand there are two ways:
way 1) create multiple valueIds with reference to a ConceptDescription per enum, add a DataSpecification to every ConceptDescription and enter the value (value field of IEC 61360 DataSpecification)

way 2) create a ConceptDescription for the property, add a DataSpecification (IEC 61360 Data Specification), create a value list and link the valueID to a ConceptDescription for every enum to get a global id.

Proposal:

• create multiple valueIds with reference to a ConceptDescription
• Allow the shortId of the CD to be the value by a proper definition within the Spec.

There might be arguments why this is not possible and I could understand this due to deviation to the normal modeling logic. However, to model enumerations is very often a requirement. There should be a simplification somehow.

[BirgitBoss]

In IEC61360 and ECLASS there are coded or explicit enumeration values. In AAS with Part 3a data specification IEC61360 we only support coded enumeration values, i.e. values with an own unique identifier.

One reason for this is that we do not (yet) support an xsd type that would represent a list/array.

[BirgitBoss]

Discussion Workstream AAS 2023-11-23

MALE/FEMALE is not a good example for explicit enumeration value because you typically need an translation of the values. In this case coded values are the preferred way to model it.

explicit
[MALE; FEMALE;...]
vs coded (already supported)
[IRDI-MALE; IRDI-FEMALE,...]
cd IRDI_MALE preferrredname: male, männlich ....

Alternatives:

• no change
• new attribute explicitValueList with Type string (comma-separated string with values)
• Idea is a simple data type like:
  int[0..6]
  string[0..*]
  but this is not existing in xsd

check how many explicit value lists exist in ECLASS
coded values are typically preferred

Not accepted for V3.1 of Part 3a

[foprs]

My question/wish for clarification was regarding modeling an enumeration in a SMT. The enumeration shall act as list of values that are allowed as value for a property in a Submodel Instance. It does not has to be a explicit list; coded values are fine.

I have seen multiple ways how to model it and for me it is not exectly clear

• a) are way 1 and way 2 right understood as according specification
• b) what is the preferred approach (way 1 or way 2) ?
• c) proposal for simplification - would be way 3 an option/could be specified

Here are the three ways:

way 1) create multiple valueIds for a property with reference to a ConceptDescription per enum value, add a DataSpecification to every ConceptDescription and enter the value (value field of IEC 61360 DataSpecification). Enter the actual enum value as property value in case Submodel Instance.

way 2) create one semanticId for a property with reference to a ConceptDescription for the property, add a DataSpecification (IEC 61360 Data Specification), create a IEC 61360 value list and link a valueID for each value of the value list to a ConceptDescription. Create a DataSpecification for every CD for every value of the value list. Enter the actual enum value as property value in case Submodel Instance.

Way 2 is descibed in Part 3a: Data Specification – IEC 61360, p. 46-47

way 3) = proposal for simplification by a respective definition in the Metamodel specification
create multiple valueIds for a property with reference to a ConceptDescription per enum value. Allow the shortId of the CD to be the enum value. Abstain from modeling the DataSpecification for every CD that carries the value (specify that the shortId of the DS can be an enum value. Enter the actual enum value as property value in case Submodel Instance.
Way three would mean that there is a CD without DataSpecification created.

[BirgitBoss]

transfer to Part 3a https://github.com/admin-shell-io/aas-specs-iec61360