[Task] Asset Administration Shell - variable range values for constraints

[yk0]

Is your task related to a problem? Please describe.
Constraints in BAMM can be used to restrict value ranges for properties in AAS submodels. On the other side, BAMM constraints do only support static values, while in a lot of use cases the range of a property might depend on other properties of the same (or another) AAS. An example: nominal power input voltage for a device depends on the target region the device was produced for (220 V for Europe, 110 V for USA).

Describe the solution you'd like
One solution would be for a BAMM constraint to reference the source where the actual value(s) for the constraint is stored, in the case of the AAS it would be the path to the AAS submodel property storing the value.

Describe alternatives you've considered
none

Additional context

[atextor]

Hello @yk0,
I understand the use case and the flexibility for a modeler this grants. Currently this is not possible, but with addressing #160 this should become viable. When something like this is to be implemented, we need to take great care to not diminish the value of an Aspect Model for a solution developer when the value is increased for a modeler. In other words, the capabability of code generation from an Aspect Model must not be restricted. If certain information is not present in the model itself, then it should be made present at the moment the code is generated (i.e., the Constraint-specific code generator knows how to resolve a certain value) or it must be well-defined how the value can be retrieved at run time (so that code can be generated that does this). The latter option could be a technical challenge, since validation frameworks such as Jackson (which is used in the generated Java code) validate mostly using compile-time annotations, i.e., the constraint values must be known at code generation time.
In any case, the first step would be to define how a model should look like and what the exact semantics are.

[yk0]

Hi @atextor,

just a sketch of how a rather minimally invasive solution might look like by using one inderection level for attribute values:

With such a solution it is possible to just define static values independently from other data sources, but also to reference external (specific) data sources like AAS.

[atextor]

WG discussion 2022-09-08:

• We can't model the source for information
• There is currently no concept of a constant (on model level) that could be referenced
• There is also currently no concept for referring to a (runtime) value of another property
• Further discussion is required.