Log In
02/22/2022
Offline
Hi all
We implemented a lot of different interfaces for our products, and we had always some issues or soultions regarding different interface versions of communication partners.
With OPC UA, there is a promise that this will be solved in a robust manner. therefore some questions arise: So what must be provided by the server?
- I assume that for each used NodeSet with its Namespace and details, there must be an entry in the Namespace-Array. Accessing the namespace-details in the ServerType isn't possible, because it is optional (https://reference.opcfoundatio.....docs/6.3.1). So as client, at this point we get just the URIs. On the other side, with the URIs the client could rely on that there is no breaking change (https://reference.opcfoundatio...../docs/11.3). But no informations regarding intermediate versions.
- A client could only rely on all mandatory parts of a specification (https://reference.opcfoundatio.....103/docs/3) -> that is clear, but most specifications defines more elements optional, than mandatory. on the other side the server could react with errors (e.g. BadNotImplemented) or just provide default values (e.g. empty strings) for mandatory parts, to bypass this requirement.
- Does the ServerStatus https://reference.opcfoundatio.....docs/12.10 provide BuildInfos regarding the used SDK or in general the OPC UA Server?
- If there are different profiles available, the interface and also the application will propably have an implementation progress.
- Any "software revision" provided by the nameplate will cover the entire machine - not just the OPC UA server or the interface definition. In addition this is only available whithin a limitted scope like companion specifications.
I've the feeling to overlook the basic version-information... like it is done for Rest-API versioning
Thanks, and best regards
P51D
05/30/2017
Offline
Profiles are the primary way to to determine what functionality is supported.
NodeSet minor versions are always backward compatible.
NodeSet major versions are not.
Usually, the URI will change with the major version.
The Namespaces component of the Server Object has all of the metadata associated with the NamespaceUris.
02/22/2022
Offline
Randy Armstrong said
Profiles are the primary way to to determine what functionality is supported.
But then we got the key-problems:
- how could a client read out the supported profiles from a server?
- it seems that OPC UA server doesn't offer a "interface version" in a common/generic way. If I implement the Machinery Basic Building Blocks V1.04, then I earn 4-7 additional nodeSets. Each of them has his own version and URI information - but what the machine really provides as funcitonality at the interface (assuming that no machine provide all defined things from day 1) is the question.
05/30/2017
Offline
Every Server should publish a list of Profiles that it supports:
ServerProfileArray lists the Profiles that the Server supports. The String shall be the URI of the Profile. See OPC 10000-7 for definitions of OPC UA Server Profiles. This list should be limited to the Profiles the Server supports in its current configuration.
02/22/2022
Offline
Oh, I've didn't seen this - thanks for the link.
Based on your answer this list isn't limitted to the scope of server capabilities but also includes all used companion specification or vendor specific defined profiles?
I'm not shure if all servers are conform to this (at least the uamit demo server isn't it) https://github.com/umati/Sample-Server. So from a robust client perspecivte this isn't a feacable way.
05/30/2017
Offline
It includes all profiles for any CS supported by the server.
While all servers may not support today, it is something that can be easily filled in as part of a dialog with server vendors.
I believe that certification testing will require that this property be filled out correctly.
So insisting on certified servers would make the field more useful.
1 Guest(s)
Usage Policy