Should we extend PLCValues with a map of Meta-Information?

[chrisdutz]

I am currently implementing some protocols, where the tag itself is passed along with some meta-information.

Till now I have the chance to either skip the additional fields and return a strongly typed PlcValue or I use a PlcStruct and the user needs to know which field the "value" is stored in.

I would however like to change the PlcValue type, to have a Map<String, PlcValue> of meta-information. This way the person interested in the information can access it, but still the PlcValue keeps it's "value".

[sruehl]

as map[string]PlcValue is basically the same as PlcStruct you could even use metadata PlcStruct from the get go

[chrisdutz]

Unfortunately PlcValue is defined in API and PlcStruct in SPI, so I cant reference it from there.

[splatch]

I don't think its a valid way, cause it complicates handling of plc values. Instead we could introduce result metadata, just like jdbc does for results sets. Since Apache PLC4X aimed to become a "jdbc for plcs" that way would fit initial declaration.

[splatch]

As far I remember in early days PlcStruct was intended for complex types which could be reported by various equipment. In principle this is the type for values which can not be mapped to basic scalar values. I am not familiar with iec driver you are working on, but if we will follow a path with PlcStruct then we should also amend OPC UA driver to reflect new philosophy and propagate meta information attached to tag (namely quality codes).

[chrisdutz]

I'm working on an implementation ... in a branch ...

[splatch]

I think that current way complicates handling of values, because collaboration with drivers will need to take into account this metadata. Any code which is a generic callback for plc read response or subscription callback intended to work across multiple drivers, will need to address it. And since metadata is driver specific and encoded by "string" keys we have no ways to keep this stuff simple. You also propose metadata at value level which means that it can be part of write request, and each of written values individually, as well.

I see direction in which you went, however I still question myself if that's the right way. Is this metadata available always within the protocol and needed for decoded value? If so, we definitely need to describe such use cases and make a recommendation for drivers to keep some level of consistency.
I know for example that M-Bus (and WM-Bus) have a concept of "tariff" and "register" which are encoded before value, effectively it is a divider between values which have same meaning such "energy consumption" or use registers as past hours, days or months. More over, it is not possible to determine available tariff and registers during discovery phase, cause it is part of regular readout. I think the metadata concept you brought fits there. Similar for OPC UA status codes and timestamps (ie. server timestamp) which might turn to be useful to some use cases.
Last thing I can bring is CAN and probably other ethernet level protocols where driver might source hardware timestamp. Such information is not associated with any of the values delivered by encoded message, but all of them, independently of the message itself. This I believe is another level of metadata which do not fit value metadata and will cause confusion. Still, if we bring metadata for values we should be clear how to do it for frames/messages which is above decoded value. While there is no concrete usecase for that yet, I would want to keep awareness/perspective of that case.

[chrisdutz]

So ... how would you then handle all this additional informaiton? Would you simply discard it? Because everything except discarding it would make things complicated in some way. My proposal keeps the core value simple but makes additional information available ... less comfortable, but still available. The only other alternative I see would be to build one universal fixed set of metadata and to map all of the variants for each driver to these. But I'm definitely not willing to put in the effort of developing such a universal set of fixed meta-data.

[chrisdutz]

So ... as I only got questions and no suggestions, I'll merge my version ... we can always change it later on ...

Right now I know of multiple protocols, that generally have such concepts of meta-data ... IEC 60870-5-104, KNX, Profinet, DeltaV (even if we don't have a working driver for that). I was always annoyed that when using PlcStruct you needed to know which are the values and which is meta-data and needed to explicitly reference them. With my changed proposal, the driver developer decides what is data and what it meta-data and modells the driver accordingly. This way the user can use the values in their natural type directly and still access the other information.

I'm not quite sure how to do this for KNX, as I generate the DataIO mspec via XSLT, but for the others, this is clearly a way better option. I'm also thinking of adding a new "metadata" field type for Data-IO types. So if you have a simple files with the name "value", that becomes the dominant field in that case, all "metadata" fields get added as metadata ... if you have multiple simple fields and none named "value", a struct is created.

[chrisdutz]

#1088 is waiting for comments ...