Object Model

The primary objective of the OPC Unified Architecture is to provide a standard that allows servers to represent real-time process state and its environment to clients, in a unique and platform-independent way. The OPC Unified Architecture Object Model has been designed to meet this objective.

According to the concept, Unified Architecture servers expose current process information to all clients as a collection of objects. The main role of the objects is to expose a selected, well-defined part of information of the underlying process. Represented information could be complex. Representation of the process in terms of values is not enough to control the behavior of the process. Therefore the server has to provide clients the possibility to perform operations on the objects (see fig. 1 bellow).

Note
Objects are a collection of: Variables – representing current state Methods – offering a functionality of the object

The Object Model defines objects in terms of variables and methods. It also allows us to express the relationships to other objects as references. In other words, the object is a placeholder collecting variables, methods and references. Using it, clients get access to the selected part of the underlying process. Therefore, the objects must have established a connection to the physical plant floor devices. On the client side, objects should provide functionality of transferring current values and operating on the object.

Note
The object connection (interface) to real-time process is plant floor devices vendor specific. The object management functionality is standardized by the OPC Unified Architecture Service Model.

Access to the values representing the current process state is provided by the Read/Write functions. Client can be also informed about the process state changes using the "data change" notifications provided by the OPC Unified Architecture Service Model. Invoke and event notification functionality allows clients to use the methods coupled with the object (see fig. 1 bellow).

Industrial process management requires information of two types: process data and metadata. From the previous discussion we know that the same way as process data represents the process physical state, metadata describes the process itself and in the OPC Unified Architecture it is exposed simultaneously the as object relationships (see fig. 1 bellow).

Because each object is a placeholder of the methods and process data, clients need a handler to call appropriate procedures provided by the Services. Therefore each object has been assigned a unique identifier. This indentifier can by unique globally or locally. Globally unique identifiers make the object randomly accessible to the clients. Locally unique identifiers mean that clients are required to access objects indirectly using defined relationships. In any case, we cannot assume that all addresses are well-known, therefore, in order to find required node, functionality provided by the Services allows browsing the objects collection exposed by the server. As a result of this functionality, we call the object identifier browse name. BrowseName is the first required attribute of each object that can be the subject of server-provided Services.

One of the requirements is the necessity of randomly accessing and getting process data by the client in a standard way without any programming. To meet this requirement, any client is supposed to have an anchor with a well-known address as a browse starting point. Information Model provides definition of all of the objects that can be found in the collection exposed by servers.

It is obvious that the process state and infrastructure is changing, so the process representation must follow those changes. Variable notion provides values representing the process state, but cannot reflect changes in the structure of the underlying process. This kind of information requires object relationship modification including creation of new objects and disposing of the existing ones. Disposing of the existing objects and managing objects references is easy to be accomplished having appropriate functionality (Services) and objects unique identification. But, the above is insufficient to create a new object, because the object kind has to be selected. The object behavior could be process-dependent, therefore cannot be subject of standardization. Creation of objects from a generic description is very difficult or impossible without any programming and, what is more, it is very error prone.

To resolve this issue, a concept of type is used. This concept uses the mechanism of replication of precisely defined templates, known for ages. The process type has similar role to DNA (Deoxyribonucleic acid) in the construction of cell components. The type contains the genetic instructions used in the development of the objects collections exposed by the server. The main role of the type is a long-term storage of information. It is often compared to a set of blueprints or a recipe, or a code, since it contains instructions needed to construct objects and relationship of the objects. Because the type is also a kind of information, and because information is an abstract concept, it cannot be subject to processing performed by a physical device. Therefore, to be exposed, it has to be represented also as an object in the collection maintained by the server.

As a result of introducing the type concept, servers could expose two object kids:

• Instance

• Type

According to this concept, an object represents a piece of underlying real process. But as it is only a piece, often it cannot exist alone, i.e. it requires an existence of other objects coupled together. Creation of the whole set on the step by step basis is error prone, as we have to address the issue what to do if the creation process has not been accomplished.

Let me give an example. Each boiler has input and output pipes, each car has four wheels. Creating objects that represent a boiler without all required pipes and a car with an incomplete number of wheels makes those objects defective and useless.

The concept of a complex type provides a solution. The complex type allows defining all objects – the whole set - that has to be created as a one step process. As a result, it is impossible to create the set of objects partially. Objects tightly coupled by the type as its parts are called instance declarations. A very powerful feature of the instance declaration is that children can also be complex, see Type Definition.

Figure 1: OPC UA Object Model

Other Resources