5.2 Specification compliance verification for new machines

As an OPC UA compliance certification authority I could use tools which are automating the NameSpaces certification of new machines by using the public Cloud Library as a unique uniform source for accessing the relevant type libraries.

As an equipment supplier I need to perform partial or complete NameSpaces compliance verification for a new machine tool which is integrating besides its own components, hardware/software from one or more suppliers either by aggregation or extension.

During operation and maintenance of a machine, the structure of the AddressSpace could change to reflect variations of the new replacing parts. As a process control engineer / maintenance technician I want to perform verifications of the OPC UA Server’s loaded AddressSpace against reference NameSpaces for troubleshooting or validation.

As a SCADA software engineer, I need to use automated tools to check compliance of new/replacing servers to client applications and vice-versa, report differences or support necessary re-adaptions.

As an automation integration engineer, I need to have a consistent up to date source of information about devices/manufacturers/suppliers which are conformant to a given companion specification/version.

As an equipment manufacturer/supplier I want to publish information about product releases conformant to a given companion specification/version as a way for creating product/brand awareness.

Structuring NameSpaces and associated metadata such that every nodeset is mastered (or edited) in only one place (single source of truth) and referred through unique uniform identification could enhance the engineering tools for automated IM compliance verification, with the final aim of reducing the overall systems engineering effort.

There could be two categories of compliance checks that are needed for all those use cases.

First check if a given model is compliant to the OPC UA specification in general (i.e., not violate any rules of how IM can be designed). This includes checks if known models (companion model or vendor specific) are used in a correct way.

The other kind of check would target the maintenance / update task. Find out if an updated model is backwards compatible to what is currently used. In other words, answer the question: The model changed, it is still compliant to the specification, but will my application and configuration still work? For example, adding a new subtype of an Object Type in a server still enables the client to continue working with the known super type. Other non-compatible changes would generate an error.