Multiple attribute thing properties or hierachical tags

[jdieringer]

Hello,

Not sure how to word this one, but this is the gist:

I have been working on resolving Rockwell EIP User Define Types (UDTs) recursively and it is all working fine. However, the current architecture creates an individual thing property per tag. Those are then read and each tag is added to a poller. The issue is that some of these nested UDTs can become massive, and if I am reading 1000 fields from the UDT, it is being re-read 1000 times per polling period and each field indivdually extracted.

Is there a concept in the WoT Thing Description that would allow me to model the UDT as a single Thing Property that is polled, but then it has a bunch of sub-fields that are updated on that read?

For example:

myUDT (as an OPC-UA FolderType node):
Field1
Field2
Field3.subField1
Field3.subField2

or:

myUDT (as an OPC-UA FolderType node):
Field1
Field2
Field3: (as an OPC-UA FolderType node)
subField1
subField2

I am fine with modifying the Rockwell client to do this if it is possible, but I just want to make sure this is possible with the format of the Thigng Description file format.

Thanks!

[jdieringer]

Reviewing the WoT TD standard, it does appear that nested tags are allowed:

But I think a few architecture changes would be necessary. I think that the deserializer would need to support nested properties, I think the node manager would need to iterate through the hierarchy and generate the nodes. Fortunately nodes have a global identifier so you don't really need to know the path, just the handle which is in there. Does it make sense to just poll the top level property and pass the entire thing to the protocol driver and let it sort out how to get all the values? That should accomplish the single read, multiple update need. But not really sure how I would handle writing for a sub property. Am I on the right track in my thinking here?

Is this a generalizable problem or is this just an issue with Ethernet/IP and should I be looking for a different solution like having a read cache in the protocol driver that just reuses the last value within some limit if the tag is the same?

[barnstee]

I think you are indeed on the right track. In terms of multiple update, OPC UA also has the concept of UDTs, called complex types. There is already an example of a complex type definition in the pac4200 sample (an energy measurement complex type from the PNEM OPC UA Companion Spec made up of 3 float "fields" A, B and C). Since it is Modbus, Translator is reading each tag separately from different Modbus registers and then updating the corresponding complex type field. What you want is to simply define the UDT as a single WoT property but then map it to an OPC UA complex type, the definition of which should be covered in the field path...

I am also currently working on separating the protocol drivers into DLLs and making them load dynamically. This is a larger change, so please hold off on making changes to the Ethernet/IP driver for now to avoid a big merge. I should be done by early next week.

[jdieringer]

Will do, I think that the modular approach is a nice improvement. Looking forward to it!

[barnstee]

OK, the dynamic protocol driver loading is in, please see the updated section on how to load them when running the Translator from a Docker environment: https://github.com/OPCFoundation/UA-EdgeTranslator?tab=readme-ov-file#running-ua-edge-translator-from-a-docker-environment

The Ethernet/IP driver now lives in https://github.com/OPCFoundation/UA-EdgeTranslator/tree/main/ProtocolDrivers/Rockwell

[barnstee]

In addition, this is what Copilot had to say (and I agree) about mapping UDTs to WoT properties and from there to OPC UA Complex Types:

In a TD, you describe the data shape using Data Schemas (including ObjectSchema) and expose interaction points via Properties/Actions/Events with forms describing protocol endpoints and payload media types. This makes a UDT naturally representable as: [w3.org]

a WoT Property (for state/telemetry) whose data schema is type: "object" with named fields
optionally an Action for atomic write/update of the whole UDT (or “setpoint structure”) [w3.org]

This is the encoding that most cleanly maps to OPC UA custom Structures later (because both are “named fields with types”). It’s also consistent with the goal stated in your WoT/OPC UA harmonization material: TDs can describe “simple types, complex types”, protocol/serialization, semantics, etc.

WoT TD purposely separates abstract interaction from concrete protocol binding. Concretely, forms carry the protocol endpoint (href), plus protocol/binding terms (including subprotocol, contentType, etc.). If there is no off‑the‑shelf binding vocabulary for EtherNet/IP in your environment, WoT explicitly allows adding protocol bindings through TD context extensions. [w3.org]
So for EtherNet/IP you typically introduce a small custom vocabulary, e.g.:

cip:service (read/write/tag op)
cip:path (route/path)
cip:tag (symbolic tag name)
cip:udtTypeCrc (the Rockwell abbreviated type code)
cip:timeout, cip:segmentSize, etc.

Rockwell’s own doc stresses that their CIP Data Table Read/Write services include an “abbreviated data type” code, and for UDT structures it’s computed with a CRC‑16 over a vendor-specific “type encoding string”; it can also be obtained from a read reply or the structure template. That is exactly the kind of “binding detail” you’d carry in a WoT form.

{
"@context": [
"https://www.w3.org/2022/wot/td/v1.1",
{ "cip": "urn:example:cip-binding#" }
],
"id": "urn:plc:compactlogix:line1",
"title": "Line1PLC",
"securityDefinitions": { "nosec_sc": { "scheme": "nosec" } },
"security": ["nosec_sc"],

"properties": {
"motorStatus": {
"description": "UDT MotorStatus read from PLC tag",
"readOnly": true,
"type": "object",
"required": ["Running", "SpeedRpm", "Alarms", "PhaseCurrent"],
"properties": {
"Running": { "type": "boolean" },
"SpeedRpm": { "type": "number" },
"Alarms": { "type": "integer", "minimum": 0 },
"PhaseCurrent": { "type": "array", "items": { "type": "number" }, "minItems": 3, "maxItems": 3 }
},
"forms": [
{
"href": "cip://192.0.2.10",
"contentType": "application/json",
"op": ["readproperty"],
"cip:tag": "MotorStatusTag",
"cip:service": "CIPDataTableRead",
"cip:udtTypeCrc": "0xA1B2"
}
]
}
}
}

Mapping the same UDT to OPC UA complex types (custom Structures):
Define a custom DataType as a Structure with StructureDefinition
In OPC UA, a “complex type” is typically a custom DataType whose DataTypeDefinition is a StructureDefinition listing fields, base type, and default encoding ids. The spec explicitly says the StructureDefinition assumes a sequential layout and contains a list of StructureField entries. [reference....dation.org]
So MotorStatus becomes:

MotorStatusDataType (subtype of Structure)
fields: Running:Boolean, SpeedRpm:Float, Alarms:Int32, PhaseCurrent:Float[3]

Encode values as an ExtensionObject
OPC UA transports structure values in an ExtensionObject, which “contains the encoding NodeId of the structure DataType and the structure as blob encoded in the requested format”. That’s the runtime equivalent of “a struct instance”.

Let me worry about the ExtensionObject encoding, I have done this before...

[jdieringer]

Nice updates, I really like the new DLL Protocol Driver architecture. I was looking through this and seeing where all the code is, and I noted that the ThingDescription.cs in UAServer still has protocol driver specific code like EIPTypeString. Should those also be moved to the protocol driver model file for their respective driver or is there a technical reason they need to stay in UAServer? Tyring to think through how to add a different protocol and what goes where. Thanks!

[barnstee]

Yeah, the WoT file parsing is still happening in Edge Translator itself, including the WoT protocol binding as in theory these are all standardized inside the W3C (or will be eventually), so no need to move them to the protocol driver. If you disagree, I could think about how to create a new IWoTProtocolBinding interface?

[barnstee]

OK, you convinced me, I moved the protocol binding definitions into the protocol driver projects. It's cleaner that way.

[jdieringer]

Thanks! My gut was that it made sense to move into the protocol drivers. If the protocol drivers were completely abstracted away from anything WoT, then maybe this would be different, but currently they still need to understand a WoT TD and generate those, so having the protocol bindings local seems cleaner as you say. It allows for the drivers to provide the appropriate protocol bindings, even experimental or WIP, without having to touch the main UAServer.

OK I will get back to some Ethernet/IP stuff now. Still doing some local POCs with the libplctag library.