Skip to content

Using Nodeset Files to Exchange Information

    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 to exchange data. The OPC UA specification provides various ways for clients to get this information:

    1. Browsing the address space for the information required.
    2. Server and Client developers agreeing upon the information model outside of OPC UA.
    3. Server developers providing excel files or text documents describing the instances.

    However the methods described above have serious limitations in the context of MDIS (an organization for controls on offshore oil and gas platforms) as given below:

    • The server might not be deployed at the time the client needs this information.
    • The MDIS Standard defines Object Types, however vendors are allowed and often do 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 causes problematic data entry issues.

    Tucked away in the OPC UA Spec, Part 6, Annex F is a neat feature: “Information Model XML Schema.” It 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 referenced as a NodesetFile. It is used extensively for defining industry standard models such as MDIS. Many examples of it can be found on the OPC Foundation web site. There are also a number of tools that generate and information model and provide a description of the 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). There are multiple ways this feature helps in the development of clients and servers, especially in MDIS.

    Method 1

    The server vendors and client vendors implementing MDIS can agree upon an Information Model (extension and subtyped Objects) and exchange this as an XML File which can be version controlled. The server and 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

    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 (a number of which are available). 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. Therefore 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.  End users 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 NodesetFiles greatly 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 has the ability to overcome the ever present late changes and testing pressure that results from them in a server. Users can be assured that the configuration is correct and it can minimize testing of systems.

    Vijaya Rama Raju is a principal Systems Architect with Yokogawa
    Paul Hunkar is an independent consultant with DS Interoperability