The alarm system already provides a default value that can be used if the input node is not available, so i see no change needed in that specific use case.

Many alarm systems are generated by underlining system, but to support an OPC UA alarm server, some information has to added to the underlining alarm records and mappings need to be made. OPC Event's have the concept of EventId and ConditionId which have to be mapped into alarm that was generate in the underlining system. The Alarm system defined in OPC UA is the ISA 18.2 / IEC 62682 alarm model and an underlining system couple with the OPC UA A&C server that is collect and sourcing the alarms to OPC UA clients would have to meet the requirements from this standard. This often means adding addition information or functionality to the generated alarm messages.

At this time I see no required changes

We still don't know how this part of the definition needs to be interpreted: "If this Variable is not in the AddressSpace, a NULL NodeId shall be provided."

In Part 9 - 5.1 General - second Paragraph stands:

• Instances of Alarm and Condition Types may be optionally exposed in the AddressSpace in order to allow direct access to the state of an Alarm or Condition. Instances not exposed in the AddressSpace still have a ConditionId (NodeId).

Assumption: If Instances of Alarms/Conditions are NOT exposed in the AddressSpace -> the InputNode is not visible in the AddressSpace.

• Is this the right assumption?

For reference this has been discussed and decided on a way forward in the UA Working Group today

The specification state when InputNode can be null - it was discussed in the working group and no additional text is needed. If the Alarm Engine is a separate UA server that does not have any knowledge of a DA server (or other non-OPC server) that is the source of the value for the Alarm , then this statement would apply "If this Variable is not in the AddressSpace, a NULL NodeId shall be provided"
The value of the InputNode is not related whether an Alarm instance is exposed in the address space, i.e. just because the Alarm instance is not expose, it does not mean that an InputNode which is exposed can be null.
Objects (or Variables) can have a reference to an HasCondition reference to a type, in this case the Object (or Variable) can generate the given AlarmType, but the instance may not be in the AddressSpace. The InputNode would be filled in since the node is in the AddressSpace (and easily identified).

Agreed to no change required to Part 9. Compliance test needs to be changed. Moving to CTT.

If the InputNode is null, then a warning should be generate instead of an error. This also results in many tests becoming skips, since the check that an alarm is generate at the correct value can not be automated (many tests will become manual tests)

Verified that all references to InputNode can be null.

Most of the changes were implemented in handling Mantis 8315.

Reviewed change off-line - agreed to changes by all reviewers - closed issue