Delete property/method in inheriting entity/functionblock/etc.

[Ebolon]

If a device do not support all properties/etc. it would be helpful to block those for the code generator. I would like to start a discussion if this is a feature the Vorto DSL benefits from and if how the syntax looks like.

Here an example:
Here we have a standard entity:

entity EntityA {
	mandatory parm1 as int
	optional parm2 as int
	optional parm3 as int
}

The device do not supports parm2:

entity EntityB extends EntityA {
	delete parm2
}

Deleting a mandatory property should result in an error.

[aedelmann]

Hi @Ebolon
that is a good point that you are bringing up because we have been facing this situation internally too. Not too much for deleting properties but extending properties. Optional values are anyway not so critical as the device may or may not send them, still fulfilling the definition. Looking at IPSO definitions, their definition properties are almost all optional. That way devices do not necessarily have to send these values.
More interestingly, how does it look like if properties are defined but need to be enriched with device specific meta data? What we came up with so far, that you can "override" function block properties / datatype properties in the information model itself since the information model is specific for the device whereas the datatypes and functionblocks are device agnostic in nature.

Long story short, here is an example where the distance is overridden from the information model by adding the max constraint to the distance functionblock sensor_value property:

Abstract IPSO model:

namespace com.ipso.smartobjects

functionblock Distance {

   status {
       mandatory sensor_value as float
       optional sensor_units as string 
       ...    
   }
}

Information model using the IPSO model and overriding it:

using com.ipso.smartobjects.Distance;0.0.1

infomodel MyDistance100MeterDevice {

   functionblocks {
       distance as Distance with {
            mandatory sensor_value as float <max:100>
       }
   }
}

So instead of extending functionblocks by defining yet another functionblock for the device which would end up in tons of device specific functionblocks (which would be hard to manage), the extension is merely defined as part of the information model itself in an more embedded way.
Thoughts?

[Ebolon]

I like this approach! Currently I try to use the Vorto DSL to generate rules for a streaming system to check if all values are in there defined boundaries. I would like to suppress values which are never used. The main reason is to reduce complexity and save cost in data transfer/processing. My current model has for example all potential attributes of the Electrical Measurement Cluster in ZigBee. The reason for that I would like to reuse this model for any potential ZigBee use cases. But my device does only support barely half of those attributes (maybe this happens also with IPSO in some cases). Thats why I got more than 50 unused values. I think there are many potential ways to suppress those attributes. Someone can delete those manually from the generated code, the generator could get some extra parameters or there could be an additional model. I can not really say what should be best practice.

Here is a diagram what I would like to archive (not final order):

Did you already thought about to support nesting? It would be nice to have the possibility to change properties in any hierarchical level like this:

entity EntityA {
	mandatory valueA as int
	optional valueB as int
}

using de.vorto.EntityA;0.0.1

functionblock FunctionblockA {
   status {
       mandatory entityA as EntityA
       optional unit as string 
   }
}

using de.vorto.FunctionblockA;0.0.1

infomodel DeviceA {
   functionblocks {
       distance as FunctionblockA with {
            mandatory entityA as EntityA with {
            	valueA as int <MAX 100>
            }
       }
   }
}

[aedelmann]

I understand what your motivation is. But what happens if an optional field becomes necessary in some situation, where the backend requires this optional field ? In that case, you would need to create another information model for the device including the property, re-generate code etc. That sounds pretty cumbersome to me. Instead and I guess preferable way, that device management deals with this kind of stuff depending upon context where the device is used.
I would be in favor of your option to allow the generator to generate checks for the presence of optional properties and only send them over the wire , if they are present.

Regarding entity overriding: I see why not extending this principle to data types as well. I like your example :)

[Ebolon]

Sounds a bit conflicting that a backend requires an optional field :) But lets close this issue for now. I am also not to 100% confident if this should be part of the DSL. I need first to get more hands on experience to have a better feeling for this.

I create a new issue for the overriding feature.