Using Nodeset Files to Exchange Information: A Case in MDIS
Any client that needs to work with an OPC UA Server has to understand the information model present in the server and discover the instance of the model to be able to wire up to the correct nodes and exchange data.
OPC UA Specification provides various ways for clients to get information. These include:
- Browsing the address space for the information required
- Server Developer and Client Developers agreeing upon the information model outside of OPC UA
- Server Developer providing excel files or text documents describing the instances.
However, the methods described above have serious limitations in the context of MDIS. These are:
- The server might not be deployed by the time the client needs this information.
- The MDIS Standard defines Object Types. Vendors however, are allowed to, and often do define Object Types in order to extend or customize these objects.
- The instances of objects depend on each vendor or installation, and providing the instance information in excel or text files with different formats cause problematic data entry issues.
An “Information Model XML Schema” describes a standard syntax that information model developers can use to define their information models in way a computer program can read. A file that uses the XML Schema is usually referred to as a NodesetFile. It is used extensively for defining industry standard models such as MDIS. There are also a number of modelling tools that generate information models and provide a description of each model as a NodesetFile. This method also applies to instance data, not just models. The XML Schema can easily be used to serialize information models directly from a server (i.e. Import/Export) and there are multiple ways this feature helps in the development of clients and servers, especially in MDIS.
Method 1 (Chart 1):
Server vendors and client vendors implementing MDIS can agree upon an Information Model (extension and sub-typed Objects) and exchange this as an Xml File which can be version controlled. The server & client vendors can proceed to develop client and server extension or sub-types in parallel. When instance information is available, additional NodesetFiles can be generated representing all of the instance information. The client vendor can process and configure the client system based on these NodesetFiles.
Method 2 (Chart 2):
If the Server is readily available, the actual configuration of the server can be extracted. Since OPC UA servers include type information, the extraction includes custom type information as well as any instance information. The generation of an extracted NodesetFile can be done with a standard third party tool. These tools can run on a separate machine and only need access to the UA Server. The client can use the exported NodesetFiles to generate any configuration, including all instance data.
Client Configuration
The nodeset format, since it is defined in the specification, allows the same tool to be used for importing configuration information from different server vendors. It allows for easy determination of changes in models. Tools can be built that actually provide detailed configuration for the client system. Yokogawa as part of the pilot project for MDIS built tools that include generating logic for interlock handling, mapping of MDIS types to existing Yokogawa Centum and UGS types, generation of Centum logic and assignment of standard faceplates to these types. These tools made use of Smart Parts, which is a standard feature in Centum systems.
The tools allow for easy extension for new types, just by configuring the additional sub-type or extension in a configuration file; any additional logic could be generated. The tool only needs to be validated for a single instance of a custom type, i.e. that the configured logic is correct, and all instances will work correctly. Providing the Nodeset configuration and tools to import the industry standard format greatly reduced configuration time as well as testing time. The end user can be assured that no data entry errors exist, and that configuration errors do not exist. If the designed logic for the given type needs to be changed, a single change and a quick regeneration will correct it for all instances. Yokogawa saw that it took only a few minutes to generate a complete configuration for its UGS OPC UA Client including Centum logic.
Conclusion
The usage of Nodeset Files simplifies the exchange of information models and the configuration of clients and servers. It has the capability to decouple the development of client and server. It also has the ability to overcome the ever-present late changes and testing pressure that results from them in-server. End user can be assured that configuration is correct and it can minimize the testing of systems.