Introducing a GenricEnumeration[Signal|Input|Output]

[dietmarw]

I copied this issue from the modelica-design mailing list so that it's not lost:

Dietmar Winkler wrote:

my colleague just tried to solve a problem with the help of
enumerations. He has a signal which is very similar to the signal of
type "VehicleInterfaces.Types.GearMode" of the VehicleInterfaces 1.0 RC1
Library. It can have different states (e.g. Park, Drive, Neutral,...).

Currently the VehicleInterfaces library is using the MSL2.2.x workaround
by accessing the signal via the temp model, i.e.
VehicleInterfaces.Types.GearMode.temp. This makes it quite easy to use
the "temp" type as a signal since it's the type of Integer with
connectors like "IntegerInput" and "IntegerOutput" available.

The question now is, since the enumeration workaround was now replaced
by the "real thing" in MSL3.0_dev will there also be an enumeration
*signal* type and the corresponding connectors "EnumerationSignal",
"EnumerationInput" and "EnumerationOutput".

The big benefit for example for automotive applications with lots of bus
control signals would be that the number of bus signals could be reduced
significantly (since lot's of them have only a boolean state depending
on each other, i.e. GearMode).

[dietmarw]

Combined answer of Martin Otter, Hans Olson, Dietmar Winkler:

[HO]:

Dear all,

It is possible, but there are some restrictions:

Having one connector will only work with _one_ enumeration type, since each enumeration introduces a new distinct type.

Obviously one can for each enumeration type make these connectors - but not a generic 'EnumerationInput' compatible with all.

[DW]:

Well how about introducing a GenricEnumeration[Signal|Input|Output]
where you can choose the type of enumeration with the help of matching
choices from enumeration types defined in the users model.

[HO]:

As for bus-signals: there is no need to declare members of expandable connectors as connectors (they are automatically connectors).

[DW]:

But what happens if you want connect a bus signal of type enumeration to
some other block. At least now you would need some kind of input or
output or am I completely wrong here?

[MO]:

You are right. This is a problem. The solution to this problem is "type inference/type propagation/type constraints". This concept is already under discussion by a subgroup and it is important to have this concept in Modelica 3.1. It is also needed for propagation of medium information about connectors (to define the medium only at one place). The basic idea is to have one generic connector type and the concrete representation is derived by the tool based on the usage of the connector. It is not easy to make this right and therefore this needs some time. In the meantime, it is probably best to keep the emulated enumerations for time signals and use "real" enumerations only for parameters.