Skip to content
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

Merged
merged 11 commits into from
Sep 6, 2022

Conversation

mmccool
Copy link
Contributor

@mmccool mmccool commented Apr 6, 2022

A short document focusing on the technical objectives and requirements for a OPC-UA binding for WoT.

@mmccool mmccool changed the title Technical Requirements for OPC UA/WoT Binding Technical Objectives and Requirements for OPC UA/WoT Binding Apr 6, 2022
liaisons/opcf/tech_reqs.md Outdated Show resolved Hide resolved
liaisons/opcf/tech_reqs.md Outdated Show resolved Hide resolved
- 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)
Copy link
Collaborator

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?

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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 Show resolved Hide resolved
## 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"
Copy link
Collaborator

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.

Copy link
Contributor Author

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 Show resolved Hide resolved
- 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)
Copy link
Collaborator

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.

liaisons/opcf/tech_reqs.md Outdated Show resolved Hide resolved
liaisons/opcf/tech_reqs.md Outdated Show resolved Hide resolved
@mmccool
Copy link
Contributor Author

mmccool commented Jul 1, 2022

Notes from OPC-UA/WoT meeting July 1:

  • McCool: this PR is for collecting technical objectives independent of who does what. Once it is clear what we have to do from a technical viewpoint, we can discuss how to organize the work, including who does what. If you see an additional technical objective, please comment (or even provide a specific suggestion using the github tool).
  • Apana (from Siemens) has already been prototyping semantic bindings for OPC UA, and also has worked with WoT TDs
  • Darko Anicic (from Siemens) has also has been doing work with semantic interoperability and also OPC UA.
  • So in general, initial prototyping work on creating a binding has already been done
  • McCool: Discovery (probably) only relevant if needed to coordinate with OPC UA functionality that does something similar and need to avoid conflicting assertions
  • McCool: Security and onboarding (e.g. if we do a WoT onboarding spec in the next charter, which is being proposed) may also be relevant esp as we will be bridging different ecosystems with different security requirements.
  • Matt Wheeler: Are semantic links in scope or not? Seb: yes, TDs have links with associated relation types (and we could define semantics around those), although we also have other ways to specify semantics, e.g. via RDF ontologies (which technically are also links)

liaisons/opcf/tech_reqs.md Outdated Show resolved Hide resolved
@mmccool
Copy link
Contributor Author

mmccool commented Jul 7, 2022

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.

@mmccool
Copy link
Contributor Author

mmccool commented Jul 7, 2022

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
Copy link
Collaborator

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.

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).

Copy link
Contributor Author

@mmccool mmccool Sep 5, 2022

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?

@mmccool
Copy link
Contributor Author

mmccool commented Sep 6, 2022

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.

@mmccool mmccool merged commit 5c00084 into main Sep 6, 2022
@egekorkan egekorkan deleted the opcua-tech-reqs branch July 19, 2023 13:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants