Standard Information Model
NodeClassis used to define objects as parts involved in the underling real-time process. Each
Objectin the Address Space has an assigned object type. The OPC UA specification has defined a
BaseObjectTypefrom which all other
ObjectTypes shall either inherit, directly or indirectly.
The standard types derived from the
BaseObjectTypeare listed in Table 1.
Table 1 Standard Object Types
Many of these standard types are used for describing OPC UA Server functionality and to provide diagnostic information. The
BaseEventTypehas many specialized subtypes to allow handling most common transient Events. System configuration changes, operator interaction and system errors are examples of Events. OPC UA Part 9 – Alarm and Conditions expands on this object type to define alarm and condition events.
Variable is dedicated to provide a value to the clients. To define a variable two types must be provided (Figure 1):
- VariableType: which describes the type of a variable. A Variable node has a
HasTypeDefinitionreference to its type definition (depicted as double closed and filled arrows).
- DataType: which describes the type of the variable value. It is assigned to the
Figure 1 Variable types relationship
In this section we focus on the available standard variable types, but in the next one we will review standard data types.
The root for all
BaseVariableType(Figure 2). This means that all other types must inherit from it. The
BaseDataVariableTypeare most important for information representation. Consequently, there are two independent inheritance sub-trees.
Figure 2 `VariableType`s inheritance hierarchy exposed by the server
Both of the above-mentioned types have the same
BaseDataType, which is abstract and defines a value that can have any valid type (Figure 3). The double closed arrows point to the source of the
HasSubtypereference. An interesting feature of these types is that even though they have an abstract
BaseDataTypeboth are concrete and therefore can be instantiated. Abstract
DataTypes do not have any encoding and cannot be exchanged on the wire; therefore the instantiated variables with an abstract
DataTypemust redefine it. The
DataTypeattribute can only be changed to a new one if it is a subtype of the original
Figure 3 BaseDataType association
Dividing the variables into properties and data variables has its source in two different information categories: data and metadata. For example, data can represent a signal, say pressure, and metadata describes the data and can be engineering units in this example. Of course we are not limited to the process control domain; it can be also a file content as the data, and last modification time as the metadata. Both may change in time, but properties are recognized as more stable. Whereas talking about stability is useful only to better understand the semantics difference, this difference has a major impact on the data source access.
Usually data is obtained from smart plant-floor digital devices responsible for converting analog signals to a digital representation. Therefore, to emphasize their origin, we call them real-time process data.
There are many sources of metadata including a human interface, memory of smart plug and play devices, etc. Usually any change of the metadata value exposed as a property is a result of an environment modification, e.g. a new sensor, new accessory, but also a file modification.
In spite of their role, both properties and variables must have a defined type of the provided value to allow clients to interpret a stream of bits sent on the wire and obtained by a client from the server.
It is worth stressing that, according to the specification, the inheritance chain is broken for the properties it means that the
PropertyTypemust not have subtypes. Additionally, it is not permitted to have a Property as source of the
HierarchicalReferences type or any type inherited from it. In other words properties cannot be complex. To prevent recursion, properties are also not allowed to have properties defined for them. Additionally, a node and all its properties shall always reside in the same server.
From the inheritance tree of the standard variable types exposed by the server (Figure 2) we can discover that the
BaseDataVariableTypeis a parent of two sets of types dedicated to:
- describe data types, i.e.
- provide diagnostic information. i.e.
Figure 4 VariableTypes to represent items of data
Users and other parts of OPC UA specification can expand the set of types presented above. For example, Part 8 of the specification defines
DataItemTypethat derives from the
BaseDataVariableTypeto represent any item of data (see Figure 4). Users can create new types from the already defined ones to meet specific requirements of the application (see example case below). A detailed description of the types derived from the
BaseDataVariableTypeis beyond the scope of this chapter, but some features of this inheritance branch are worth noting. As opposed to the properties, the variables may be complex. One example of a complex
ServerStatusTypeshown in Figure 5. Components of the complex variable can be accessed independently. The next very important future of the variables is that new user specific types can be freely defined by deriving them from those already defined.
The type of data provided by the
Valueattribute is defined by the associated
DataTypeis pointed out by the
DataTypeattribute of the
DataTypeattribute is of the
NodeIdtype (Table 2). In many cases, the value of the
DataTypeattribute – called
DataTypeId– will be well-known to clients and servers. Well-known values of
DataTypeIdallow clients to use random addressing and interpret values without having to read the type description from the server. Therefore, servers may use well-known
DataTypeIdvalues without representing the corresponding
DataTypenodes in their Address Space.
Figure 5 ServerStatusType structure
NodeClassis dedicated to describe types. In this case, the represented types have a special mission, because they describe data provided by the UA Server to clients. For example, a node of the DataType can provide information to clients that the data has a numeric value and the clients reading it can use this knowledge to interpret and process the obtained value – stream of bits.
BaseDataTypeis the root of the inheritance tree. The simplified inheritance hierarchy of the standard data types is shown in Figure 6, where the whole sub-tree of built-in types are represented commonly by a single symbol.
Table 2 Built-in Data Types
To some standard data types – called built-in types - special rules apply. Built-in data types have no encoding visible in the UA Address Space since the encoding should be known to all OPC UA products. Examples of built-in data types are
Double. The built-in data types with a short description are listed in the Table 2
Figure 6 Standard DataTypes inheritance hierarchy
Most of the built-in types are similar to those known in other IT systems, except the
NodeIdtype. This type needs some comments, because it is intended to be used by the random addressing mechanism to represent information allowing clients to uniquely identify and access the nodes. This built-in data type is a structure composed of:
namespaceIndex: numeric values used to identify namespace
identifierType: identifies the type of the
NodeId, its format and its scope
identifier: a unique identifier within the context of the namespace
The namespace is a URI (Unique Resource Identifier) that identifies the naming authority responsible for assigning the identifier element of the
NodeId. Namespace URIs are identified by numeric values in OPC UA Services to permit a more efficient transfer and processing (e.g. table lookups).
Depending on the application requirements, the
identifierTypefield may have the following values:
- NUMERIC: numeric
- STRING: text string
- GUID: Globally Unique Identifier
- OPAQUE: namespace specific format
Enumeration (Figure 6) is the next standard data type derived directly from
BaseDataType, that needs some comments. It is to be used to represent a limited set of simple information entities. Therefore it is a simple and abstract type. All enumerations, like
NodeClass, have to inherit from it. All types inheriting from the
Enumerationhave a special processing for the encoding.
Process data could be complex.
Structure(Figure 6) is an abstract data type defined as the base for all structured types. All data types inheriting from it have a special processing for the encoding. All complex data, if not defined explicitly as primitive in the specification, are created by defining of new types derived from the
When complex data structures should be made available to the client there are basically three different approaches:
- Create several simple variables using simple data types reflecting parts of the structure and map the data structure using these variables as object or variable components
- Create a complex data type and a simple variable using data type derived from
- Create a complex data type and a complex variable using this data type and also exposing the complex data structure as variables of the complex variable using simple data types
An example of the first scenario is shown in Figure 5 where a variable of the
ServerStatusTypehas components of a simple data type. Advantages of this approach:
- the complex structure of data is visible in the Address Space
- a generic client can easily access the data without any knowledge of user-defined data types
- the client can access individual parts of complex data
Disadvantages of the first approach are that accessing individual data does not provide any transactional context; and for a specific client the server first has to convert data and the client has to convert data, again, to get the data structure the underlying system provides.
Figure 7 ServerStatusDataType Structure
An example of the second scenario is shown in Figure 7. Here, the same information as previously is available as a complex data type of the
ServerStatusDataTypethat inherits from the Structure. The
ServerStatusDataTypearranges the server status data as a collection of fields. Advantages of this approach:
- data is accessed in a transaction context,
- the complex data type can be constructed in a way that the server does not have to convert data and can pass it directly to the specific client that can directly use it.
Disadvantages are that the generic client might not be able to access and interpret the data or it has the burden to read the
DataTypeDescriptionto interpret the data. The data structure is not visible in the Address Space; additional Properties describing the data structure cannot be added to the data type. Individual parts of data cannot be read without accessing the whole data structure.
The third approach combines both other approaches. The specific client can, therefore, access data in its native format in a transactional context, whereas the generic client can access the simple data types of the components of the complex variable. The disadvantage is that the server has to be able to provide the native format and also interpret it to be able to provide information in simple data types. In some SDK’s support for this mapping is provided automatically; for example the OPC .NET SDK will provide this mapping as part of its code generator for user defined types.
When a transactional context is needed or the client should be able to get a large amount of data instead of subscribing to several individual values, the third approach is suitable. However, the server might not always have the knowledge how to interpret complex data or be able to have predefined structures for the complex data of the underlying system and it, therefore, has to use the second approach just passing data to the specific client who is able to interpret the data.
Reference types are used to create interconnections between nodes. They are not instantiated, i.e. a NodeClass representing a reference is not defined. Instead of instantiating the references, they are added to a collection associated with each node. NodeClass of the node and its type decide what references are allowed to be added to this collection. The base of all references is an abstract References type (Figure 8). There is no semantics associated with it. There are two disjoint sets of standard references:
Figure 8 Standard reference type hierarchy exposed by the server
This distinction reflects two fundamental relationship categories that can be generally distinguished: the association and the dependency. Associations are used to build information architecture – nodes hierarchy - that can be discovered by the clients using the browsing mechanism. An example of the association is the parent/child relationship. In this case we can say that the target belongs to the source. A dependency from a source element (called the client) to a target element (called the supplier) indicates that the source element uses or depends on the target element. An example of dependency is the variable and variable type relationship. In this case we can state that the target describes the source.
HierarchicalReferencesdo not forbid loops. For example, starting from node “A” and following
HierarchicalReferencesmay lead to browse to node “A” again.
HasChildis an abstract type derived from
HierarchicalReferencesthat creates a branch of types, which forbids loops. In this case, starting from node “A” and only following references, which are subtypes of
HasChild, we shall never be able to return to “A”. But it is allowed that there may be more than one path leading to another node “B”.
HasProperty. Both are derived from the Aggregates type and used to reflect the parent – child relationship. There is also
HasSubtypeon this branch, but in this case it is used to expose the inheritance hierarchy.
HasComponentis derived from the
Aggregates(Figure 8) is defined to build the part of relationship, i.e. the target node of
HasComponentis a part of the source node. This type is used to relate objects, object types, variables and methods. Table 3 contains the allowed composite nodes (source) and allowed components as the target of this type of reference. By using this reference, the variable is defined as a
The semantics of
Aggregates(Figure 8) is to identify the properties of a node. The source node of this type can be of any
NodeClass. The target node shall be a variable. By using the
HasProperty, the variable is defined as
Property. Since properties shall not have properties, a property shall never be the source node of a
Figure 9 `ServerType` definition exposed by the server
An example of a complex object using the references described above is shown in Figure 9. The
HasPropertyreferences pointing to the
ServiceLeveland Auditing properties. The
ServerStatusis a child variable pointed by a reference of the
HasComponenttype. Objects of this type have also components:
ServerRedundancyobjects pointed also by a reference of the
HasSubtypeis a subtype of the
HasChildtype. It is worth noting, that inheritance using HasSubtype is represented using the one-to-many (parent/child) relationship. Because new types can be freely derived from the existing ones we cannot enumerate all children in advance - the tree must be built and maintained dynamically during the life-cycle of the Address Space. This means that when a new type is created it is created with a reference to its base (parent), which results in a new subtype being added to the parent.
Organizesis the next subtype of
HierarchicalReferences. The semantics of it is to organize nodes in the Address Space. It can be used to span multiple hierarchies independent of any hierarchy created with the non-looping
Aggregatesreferences. The source node of references of this type shall be an object or a view. If it is an object it should be an object of the
FolderTypeor one of its subtypes. The target node of this type can be of any
The information model provides constructs that can be used to model discrete object behavior in terms of the states an object can reside in and the transitions that can happen between those states. State machines (see example in Figure 10) are built as objects graph using dedicated object types, variable types and reference types, whose behavior is governed by the rules that must be strictly observed.
Figure 10 Example of a simple state machine
A state is a condition in which an object can be at some point during its lifetime, for some finite amount of time. A transition is a change of an object from one state (the source state) to another (the target state). The transition is triggered ("fires") when an event of interest – cause - to a given object occurs. According to the information model concept, causes are represented in the form of methods that have to be called, but a vendor can define other items or have them be internal (i.e. nothing is listed causing the transition). There may also be an action associated with a triggered transition. This action called an effect is executed unconditionally before the object enters the target state. Effects are events that are generated.
Figure 11 Representation of the example state machine.
The simplified state machine model described above can be freely expanded to provide more complex functionality like sub-machines, parallel states, forks and joins, history states, choices and junctions, etc.
State machines are represented in the Address Space as an object of a type derived from the
StateMachineTypethat defines a single variable of the
StateVariableType, which represents the current state of the machine. An instance of the
StateMachineTypeshall generate an event whenever a state change occurs. Transitions are represented as objects of the
TransitionType. Each valid transition shall have exactly one
FromStatereference and exactly one
ToStatereference, each pointing to an object of the
Using the above terminology we can represent any state machine from Figure 10 as a diagram shown in Figure 11. For this diagram it is assumed that
MyStateMachineTypeis derived directly or indirectly from the
StateMachineType. All states, transitions and methods are components of this type.