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.

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.

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.

https://reference.opcfoundatio.....docs/6.3.2

The mapping between information in a token and the local roles is defined by Part 18

https://reference.opcfoundatio.....docs/4.4.4

In this case, the server admin would set up mapping rules for the roles that actually appear in the token and the the roles it knows about.

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.

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.

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

This could mean long time outs or other error reporting delays that occur when relying on TCP stack error notifications.

The spec provides no recommendations when it comes to setting TCP socket properties but perhaps it should.

Can you add a mantis issue for Part 6 with some suggestions for spec additions:

https://mantis.opcfoundation.o.....default=no

What is the preferable way to determine the connection loss so ua server can resend RHEL message to the client?

Can we enable tcp keep-alive on ua-server side?

Or should we have some configurable timeout on ua-server side like "timeout of no client messages received" ?

Or may be ua-server shall once in a sec try to open socket to the client and this way monitor connection loss?

Or may be ua-server should wait for session timeout to pass?

Any other way?

But this sounds like an issue that OPC needs to investigate more carefully.

It should not affect users since GPLv2 is inherited from Core no matter what.

"If your plugin or package links to a GPLv2 DLL, it is considered a combined work. The entire combination (plugin + GPLv2 DLL) must be GPLv2. If your main application loads that plugin, it may also be subject to GPLv2"

Is the MIT License correct for the Client package?? Doesn't seem correct to me and others as discussed here: the project licence · Issue #2347 · OPCFoundation/UA-.NETStandard

NuGet Gallery | OPCFoundation.NetStandard.Opc.Ua.Client 1.5.377.21

My interpretation has been that these are just information for the client application that the server is not able to provide actual data. But, nobody really uses these, anyway, and as can be seen with the .NET stack it's not even possible, if it cannot ever provide all of the defined values. 

Based on this definition you can go through the states and decide which ones mean it cannot process requests:

FAILED, SHUTDOWN and maybe UNKNOWN,

If the Server is in states other than these and Bad_ServerHalted is returned then it is bug in the .NET code.

Can @Randy or someone help to explain to me about the UA ServerState specification? I cannot find out a clear answer concerning the UA Server's behaviour when it's not in Running state. It feels like an undefined behaviour from UA Specification: UA Part 5: Information Model - 12.6 ServerState
The default behaviour from OPC Foundation's .NET standard stack is that, the server rejects any service request with ServiceResult: BadServerHalted. It results:

• The client cannot establish a session with the server.
• The already established session fails.
• The ServerState cannot be read by the Client, nor be sent from the server to the client.

Is this expected behaviour across all vendors? Or is it vendor specific how the server should behave in non-Running states?

I am aware of that the server's behaviour can be overided. So why the standard stack choose to reject any service request?

Thanks in advance,

Siyuan