-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Technical Objectives and Requirements for OPC UA/WoT Binding #1020
Conversation
liaisons/opcf/tech_reqs.md
Outdated
- Note: useful for activites other than 2 | ||
2. WoT TD Protocol Binding for OPC UA Nodesets | ||
- Depends on 1 (TDs with this protocol binding would include the OPC UA ontology defined in 1) | ||
3. Process to transform a OPC UA NodesetFile to a WoT Thing Description (and vice versa, if TD describes OPC UA Nodeset) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Automatic process or just a textual description?
Create a tool?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the mapping should be specified. Tooling can then follow this approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think our goal should be a formal definition of the mapping so that it can be performed automatically. As a standards activity we would not be creating tools ourselves as a deliverable, but members should probably do so as test cases.
We might have to do certain things manually though, e.g. generate TMs for OPC UA device classes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
made a few changes to try and make this more explicit
liaisons/opcf/tech_reqs.md
Outdated
## Objectives | ||
1. Use OPC UA servers (device, node) from WoT Consumers; treat an OPC UA server as a Thing | ||
2. Access WoT TD metadata for OPC UA servers - integrate discovery process with OPC UA | ||
3. ? Let OPC UA servers connect to WoT Things; but if OPC UA devices are ALSO WoT Consumers, 1 satisfies this; --> "OPC UA Servients" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Theoretical, this would be possible. However, that should not be the primary goal for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume you mean Objective 3. I agree, which is why there is a ?. I also separated out the deliverables for the reverse conversion, also marked with a ?. The ? is marking the fact that we should ask if this is goal, and if it is not, we can remove it (or even explicitly state it as a non-goal).
liaisons/opcf/tech_reqs.md
Outdated
- Note: useful for activites other than 2 | ||
2. WoT TD Protocol Binding for OPC UA Nodesets | ||
- Depends on 1 (TDs with this protocol binding would include the OPC UA ontology defined in 1) | ||
3. Process to transform a OPC UA NodesetFile to a WoT Thing Description (and vice versa, if TD describes OPC UA Nodeset) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the mapping should be specified. Tooling can then follow this approach.
Notes from OPC-UA/WoT meeting July 1:
|
OK, I did a bunch of changes based on all the feedback so far, please take a look and do another round of reviews. BTW it would be very helpful to provide specific suggested changes (which you can do in github using the icon that has a "+" and "-" sign inside a "document" icon on the menu bar) when you write a review comment. |
Sorry, a few more tweaks. I'll try to leave it alone now so there is a stable version for reviewers. |
|
||
## Objectives | ||
1. Use OPC UA servers (device, node) from WoT Consumers; treat an OPC UA server as a Thing | ||
2. Express metadata for OPC UA servers using WoT TDs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we may also discuss "what" should be represented in the TD. It is not unusual for a UA server to have tens of thousands of nodes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An OPC UA server of a single device will have the mandatory Server object and then depending on used information model the instance of the device is represents. But as @sebastiankb says, could be a few 10 ... x000, therefore the standardized information models should be taken into account here.
As chair of the OPC UA for Machine Tools, JWG, this is an example https://github.com/OPCFoundation/UA-Nodeset/blob/latest/MachineTool/Machinetool-Example.csv (119 Nodes for a simple machine tool + Server Object).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have also seen this same pattern in Home IoT. In Home Assistant, it is more common to focus on "entities" (single measurements or actuators) rather than "Devices". Even in my test setup I have some devices with dozens of entities, and when I write automation rules, etc. I focus more on entities than devices. I suspect OPC UA nodes are more like entities than devices...
So: should Things map to devices, or entities? Should OPC UA nodes be Things, or affordances? If we use Things, can we use collections, etc. to represent the co-location of nodes in a particular device?
Will merge so an up-to-date version is in the repo, but it seems we probably do need additional updates, which can be done in a new PR. |
A short document focusing on the technical objectives and requirements for a OPC-UA binding for WoT.