A primary objective of analyzers is to determine the process state/ behavior by measuring selected physical values that are characteristic for it. Obtained result – process data – is used to control, trace and optimize the production process.
To integrate analyzers into the supervisory control and tracing systems the process data must be transported and unambiguously represent the process and product for parties that are to be interoperable. To meet the above requirement it is proposed to employ OPC Unified Architecture technology that is universally accepted, platform-neutral communication standard.
In 2008 the OPC Foundation announced support for Analyzer Devices Integration into the OPC Unified Architecture and created a working group composed of end users and vendors with its main goal to develop a common method for data exchange and an analyzer data model for process and laboratory analyzers. In 2009 the OPC Unified Architecture Companion Specification for Analyser Devices was released. To prove the concept a reference implementation has been developed containing ADI compliant server and simple client using the Software Development Kid released by the OPC Foundation.
The model described in the specification is intended to provide a unified view of analyzers irrespective of the underlying device. This Information Model is also referred to as the ADI Information Model. As it was mentioned, analyzers can be further refined into various groups, but the specification defines an Information Model that can be applied to all the groups of analyzers.
The ADI Information Model is located above the DI Information Model. It means that the ADI model refers to definitions provided by the DI model, but the reverse is not true. To expand the ADI Information Model, the additional layers shall be provided.
There are variety of analysers groups. however, but the ADI Information Model is generic, and therefore before implementing it in a particular application must be expanded by application specific types and customized by overriding the predefined components.
Appropriate Information Model adaptation and implementation is a basic requirement to offer ADI ready and interoperable products. From the experience gained during development of the reference implementation it can be stated that this process can be accomplished engaging very limited resources. Thanks to the reference implementation and supporting tools like CAS Address Space Model Designer only basic knowledge of the Address Space and Information Model concepts are required.
Because there are a large variety of analyzers types, from various vendors with many different types of data, including complex arrays and structures a real challenge is integration of the analyzers and control, tracing and monitoring systems. Initiatives such as Process Analytical Technology are driving analyzer integration and the best way to accomplish this is via open standards. To address this problem two questions can be distinguished:
- How to get access to (transport) the process data,
- How to represent (model) the process data.
OPC Unified Architecture technology meets all the requirements, because:
- It is a platform neutral standard allowing easy embedded implementation.
- It is designed to publish real-time, historical and meta data.
- It is designed to support complex data types and object models.
- It is designed to achieve high speed data transfers using efficient binary protocols.
- It has broad industry support beyond just process automation and is being used in support of other industry standards such as S95, S88, EDDL, MIMOSA, OAGiS.
One of the main goals of the OPC Unified Architecture is to provide a consistent mechanism for the integration of process control and enterprise management systems using client/server middle-range archetype. To make systems interoperable, the data transfer mechanism must be associated with a consistent information representation model. OPC UA uses an object as a fundamental notion to represent data and activity of an underlying system. The objects are placeholders of variables, events and methods and are interconnected by references. This concept is similar to well-known object oriented programming (OOP) that is a programming paradigm using “objects” – data structures consisting of fields, events and methods – and their interactions to design computer programs. The OPC UA Information Model provides features such as data abstraction, encapsulation, polymorphism, and inheritance.
The OPC UA object model allows servers to provide type definitions for objects and their components. Type definitions may be abstract, and may be inherited by new types to reflect polymorphism. They may also be common or they may be system-specific. Using the type definitions to describe the exposed by the server information allows:
- Development against type definition.
- Unambiguous assignment of the semantic to the expected by the client data.
Having defined types in advance, clients may provide dedicated functionality, for example: displaying the information in the context of specific graphics.
The Information Model is a very powerful concept, but it is abstract and hence, in a real environment, it must be implemented in terms of bit streams (to make information transferable) and addresses (to make information selectively available).
Information exposed by the OPC UA Server is composite. Generally speaking, to select a particular target piece of information a client has two options: random access or browsing. Random access requires that any target entity must have been assigned globally unique address and the clients must know it in advance. We call them well-known addresses. It is applicable mostly to entities defined by standardization bodies. The browsing approach means that clients walk down available paths that build up the structure of information. This process is costly, because instead of pointing out the target, we need to discover the structure of information step by step using relative identifiers. The main advantage of this approach is that clients do not need any prior knowledge of the structure – clients of this type are called generic clients. To minimize the cost, after having found the target, every access to it can use random access. Random access is possible since the browsing path is convertible to a globally unique address using the server services.
- OPC UA – Specifications (mpostol.wordpress.com)
- OPC UA Makes Smart Factory Possible (mpostol.wordpress.com)
- OPC Unified Architecture – Main Technological Features (mpostol.wordpress.com)
- OPC UA Information Model Deployment
- OPC UA For Analyser Devices 1.1 Companion Specification (limited access)