And for the BrowseName under the Objects (i=85) folder: Should we use 0:FileSystem or <instanceNs>:FileSystem (e.g. 5:FileSystem, when 5 is our FileSystem namespace)?

Clients can only detect if a Server supports the File Transfer - File System Spec by browsing the Objects-Folder (i=85) and filtering for *:FileSystem results, right?

Need to add IsDesignTool which will make it clear why it is not referenced.

You should never use i=16314

when to use the FileSystem NodeId i=16314 for a FileSystem instance? Is it reserved for FileSystem instances referenced directly under the Objects (i=85) folder?

The spec says, that the BrowseName has to match "<ns>:FileSystem" (not even restricts it to "0:FileSystem") but it does not define the standard NodeId (i=16314):

The Object representing the root of a file directory structure shall have the BrowseName FileSystem. An OPC UA Server may have different FileSystem Objects in the AddressSpace. HasComponent is used to reference a FileSystem from aggregating Objects like the Objects Folder or the Object representing a device.

The Opc.Ua.NodeSet2.xml contains this NodeId, but is not referenced:

<UAObject NodeId="i=16314" BrowseName="FileSystem">

Best regards,

Thomas

we would need to check the details of the certification as well as the behavior to see whether there was a gap in testing which caused this to be missed or whether this is actually compliant behavior under the given circumstances.

Since we would not like to discuss this in public, can you please send a mail to compliance@opcfoundation.org with further details about the product, the version you are using and in which scenario you are experiencing the issue?

We will then investigate and get back to you via e-mail. If we find something missing in the testing we will then create additional test cases to cover those cases and make sure these are caught in the future.

Regards,
Alexander Allmendinger

A follow up question on ConditionName.

We have observed OPC UA servers that provide an empty or null ConditionName, while at the same time holding OPC Foundation certification. 

Given that the confirmation that ConditionName must not be null or empty, we are trying to understand how such a server could still pass conformance testing. Is ConditionName perhaps covered by a different Facet or Profile than those included in the server's certification (see below)? Or is the value simply not validated as part of the relevant conformance test cases?

It would be useful to understand whether this behavior is outside the scope of the certification tests, whether there is an interpretation issue regarding the specification requirements, or whether there is a gap in the current test coverage.

Any clarification on how ConditionName is evaluated during OPC Foundation certification would be greatly appreciated.

The A&C facet that the OPC UA servers holding OPC Foundation certification on are:

- A&C Base Condition Server Facet
- A&C Acknowledgeable Alarm Server Facet

Thanks

ConditionName identifies the Condition instance that the Event originated from. It can be used together with the SourceName in a user display to distinguish between different Condition instances. If a ConditionSource has only one instance of a ConditionType, and the Server has no instance name, the Server shall supply the name element of the BrowseName of the ConditionType.

Specification says no and provides a default if it does not make sense.

Another question in same area. 

Is it allow to set property ConditionName (in EventType ConditionType) to null or empty according to the OPC UA specifications. 

Thanks

OPC 10000-24, OPC Unified Architecture - Part 24: Scheduler
http://www.opcfoundation.org/UA/Part24/
OPC 10000-25, OPC Unified Architecture - Part 24: Scheduler
http://www.opcfoundation.org/UA/Part24/
OPC 10000-26, OPC Unified Architecture - Part 24: Scheduler
http://www.opcfoundation.org/UA/Part24/

For "OPC 10000-24, OPC Unified Architecture" this is fine, but not for "OPC 10000-25..." and "OPC 10000-26..."

This need to be 

OPC 10000-24, OPC Unified Architecture - Part 24: Scheduler
http://www.opcfoundation.org/UA/Part24/
OPC 10000-25, OPC Unified Architecture - Part 25: ObjectSerialization
http://www.opcfoundation.org/UA/Part25/
OPC 10000-26, OPC Unified Architecture - Part 26: LogObject
http://www.opcfoundation.org/UA/Part26/

Btw: the underlying links for OPC 10000-25 and -26 are correct

And the Bibliography is only in the PDF, not downloaded markdown or browsed spec.

But the Value cannot be Variant.Empty for mandatory properties.

However, the "" rule does not apply if the description of the property makes it clear that "" is not a valid value:

SourceName provides a description of the source of the Event. This could be the string-part of the DisplayName of the Event source using the default locale of the server, if the Event is specific to a Node, or some server-specific notation.

(i.e. "" is not a description)

Clients should be designed defensively to deal with misbehaving Servers but that does not make the server right.

Is it allowed, according to the specifications, to set the value on a mandatory property, in an event, to null. 

For example:

Assuming an event of EventType BaseEventType.

Is it allowed for an OPC UA server to set, for example, property SourceName to null in the event?

If it is, is it the same for any mandatory property in any EventType? 

Should an OPC UA client be able to take that into account?

Thanks