DataType Node Class

The data type model is used to define simple and complex data types. Types are used to describe the structure of the Value attribute of variables and their types. Therefore each Variable and VariableType node is pointing with its DataType attribute to a node of the DataType node class as shown Figure 1.

Figure 1: Variables, Variable Types and their Data Types

Note

The data type term has the following meanings: A node class kind representing design time information about the type of underlying system information in the OPC Unified ArchitectureAddress Space according to the Node Model – an element of the Node Model vocabulary (written as: “DataType”); An object, i.e. an instance of the DataType node class exposed as an element of the OPC Unified ArchitectureAddress Space by the server at runtime according to the Object Model; it is also accessible to clients using Service Sets; (written as: “DataType object”); A DataType attribute of the Variable and VariableType node classes (written as: “DataType attribute”); One of the predefined types (see Standard Data Types) of underlying system information, i.e. a precisely defined set of information and their binary representation on the wire (written as: “DataType <type identifier>"); A general term to refer to the information type provided by the underlaying system (written as: “data type”)

In many cases, predefined values of the DataType NodeId attribute (of the type NodeId) will be well-known to clients and servers. Standard Data Types defines data types and section Mappings describes coupled values of the NodeId attribute. In addition, other organizations may define data types that are well-known in the industry. Well-known values of the NodeId attribute provide for commonality across OPC Unified Architecture servers and allow clients to interpret values without having to read the type description from the server. Therefore, servers may use well-known values of the NodeId attribute without instantiating the corresponding DataType nodes in their Address Space.

In other cases, data types and their corresponding identifiers may be vendor-defined. Servers should attempt to expose the DataType nodes and the information about the structure of those types represented by the DataType nodes for clients to read, although this information might not always be available to the server.

Note
NodeId attribute play a role of the type identifier, and therefore well-known types must have globally unique NodeId values.

Figure 2 illustrates the nodes used in the Address Space to describe the structure of a data type represented by the DataType node. The DataType points to an object of type DataTypeEncodingType. Each DataType can have several data type encoding, for example Default, UA Binary and XML encoding. Services described in the section Services allow clients to request an encoding or choosing the Default.

Note
Each data type encoding is used by exactly one DataType node, that is, it is not permitted for two DataType nodes to point to the same node representing DataTypeEncodingType. The node of DataTypeEncodingType points to exactly one Variable representing DataTypeDescriptionType. The Variable node representing DataTypeDescriptionType belongs to a Variable representing DataTypeDictionaryType.

Figure 2: Data Type Model

Since the identifiers of the data type encoding will be used in some mappings to identify the DataType and its encoding as described in section Mappings, those values may also be well-known for well-known values of DataType NodeId attribute.

The data type dictionary describes a set of data types in sufficient detail to allow clients to parse/interpret variable values that they receive and to construct values that they send. The data type dictionary is represented as a Variable of type DataTypeDictionaryType in the Address Space, the description about the data types is contained in its Value attribute. All containing data types exposed in the Address Space are represented as Variable nodes of type DataTypeDescriptionType The Value of one of these variables identifies the description of a DataType in the Value attribute of the data type dictionary.

The data type of a Variable representing DataTypeDictionaryType is always a ByteString. The format and conventions for defining data types in this ByteString are defined by data type systems. Data type systems are identified by the value of the NodeId attribute. They are represented in the Address Space as ObjectType node class representing the DataTypeSystemType type. Each Variable representing a data type dictionary references a data type system object to identify their data type system.

A client must recognize the data type system to parse any of the type description information. OPC Unified Architecture clients that do not recognize a data type system will not be able to interpret its type descriptions, and consequently, the values described by them. In these cases, clients interpret these values as opaque ByteString.

OPC Binary and W3C XML Schema are examples of data type systems. OPC Binary uses XML to describe binary data values. W3C XML Schema is specified in XML Schema Part 1 and XML Schema Part 2.

DataType nodes are distinguished between depending on the represented type and are handled differently regarding their encoding and whether this encoding is represented in the Address Space.

Built-in data types is a fixed set (see section Mappings for a complete list of Built-in DataTypes). They have no encodings visible in the Address Space since the encoding should be known to all OPC Unified Architecture products. Examples of Built-in data types are Int32 and Double.

Simple data types are subtypes of the built-in data types. They are handled on the wire like the built-in data type, i.e. they cannot be distinguished on the wire from their built-in supertypes. Since they are handled like built-in data types regarding the encoding they cannot have encodings defined in the Address Space. Clients can read the DataType attribute of a Variable or VariableType node to identify the simple data type of the Value attribute. An example of a simple data type is Duration. It is handled on the wire as a Double but the client can read the DataType attribute and thus interpret the value as defined by Duration type.

Structured data types are data types that represent structured data and are not defined as built-in data types. Structured data types inherit directly or indirectly from the Structure data type. Structured data types may have several encodings and the encodings are exposed in the Address Space. How the encoding of structured data types is handled on the wire is described in section Mappings. The encoding of the structured data type is transmitted with each value, thus clients are aware of the data type without reading the DataType attribute. The encoding has to be transmitted so the client is able to interpret the data. An example of a structured data type is Argument.

Enumeration data type represents discrete sets of named values. Enumerations are always encoded as Int32 on the wire as described in section Mappings. New enumeration data types inherit directly or indirectly from the Enumeration. Enumerations have no encodings exposed in the Address Space. To expose the human-readable representation of an enumerated value the DataType node may have a property EnumStrings containing an array of LocalizedText. The rnteger representation of the enumeration value points to a position of that array. An example of an enumeration data type is NodeClass.

In addition to the data types described above, abstract data types are also supported, which do not have any encodings and cannot be exchanged on the wire. Variables and variable types use abstract data types to indicate that their Value may be any one of the subtypes of the abstract data type. An example of an abstract DataType is Integer.

The DataType node class describes the syntax of a VariableValue attribute. The data types may be simple or complex, depending on the data type system. Data types are defined using the DataType node class.

The DataType node class inherits the base attributes from the Basenode class. The IsAbstract attribute specifies if the data type is abstract or not. Abstract data types can be used in the Address Space, i.e. variables and variable types can point with their DataType attribute to node representing an abstract type. However, concrete values can never be of an abstract type and shall always be of a concrete subtype of the abstract type.

HasProperty references are used to identify the properties of a DataType node. The property NodeVersion is used to indicate the version of the DataType. This version is not affected by the DataTypeVersion property of data type dictionaries and data type descriptions. The property EnumStrings contains human-readable representations of enumeration values and is only applied to Enumeration data types.

HasSubtype references may be used to expose a data type hierarchy in the Address Space. This hierarchy shall reflect the hierarchy specified in the data type dictionary. The semantic of subtyping depends on the data type system. Servers need not provide HasSubtype references, even if their data types span a type hierarchy. Clients should not make any assumptions about any other semantic with that information than provided by the data type dictionary. For example, it might not be possible to cast a value of one data type to its base data type.

HasEncoding references point from the DataType to its data type encodings. Following such a reference, the client can browse to the data type dictionary describing the structure of the data type for the used encoding. Each concrete structured DataType can point to many data type encodings, but each data type encoding shall belong to one DataType node that is, it is not permitted for two DataType nodes to point to the same DataTypeEncodingType object using HasEncoding references.

An abstract DataType is not the source node of a HasEncoding reference. The data type encoding of an abstract DataType is provided by its concrete subtypes.

DataType nodes shall not be the source node of other types of references. However, they may be the target node of other references.

A data type dictionary is an entity that contains a set of type descriptions, such as an XML schema. Thae dictionaries are represented as Variable nodes of the DataTypeDictionaryType.

A data type system specifies the format and conventions for defining data types in data type dictionaries. Data type systems are defined as ObjectType node class representing the DataTypeSystemType.

The reference type used to relate of the ObjectType node representing the DataTypeSystemType type to the VariableType node representing the DataTypeDictionaryType is the HasComponent reference type. Thus, the variable is always the target node of a HasComponent reference – a requirement for variables. However, for data type dictionaries the server shall always provide the inverse reference, since it is necessary to know the data type system when processing the data type dictionary.

An example of a data type dictionary is an XML document containing an XML schema. In this case, the data type system is the W3C XML Schema and the top level element declarations in the schema document are the data type descriptions. Each of these descriptions is defined in different versions of an XML schema using the same XML target namespace. This target namespace is used as the namespace component of the type identifier in the server’s Address Space. Since the same target namespace can be used in other XML schemas, clients shall be aware that two type identifiers with the same namespace are not necessarily defined in the same data type dictionary.

Changes may be a result of a change to a type description, but it is more likely that dictionary changes are a result of the addition or deletion of type descriptions. This includes changes made while the server is offline so that the new version is available when the server restarts. Clients may subscribe to the DataTypeVersion property to determine if the data type dictionary has changed since it was last read.

The server may – but is not required to – make the data type dictionary contents available to clients through the Value attribute. Clients should assume that data type dictionary contents are relatively large and that they will encounter performance problems if they automatically read the data type dictionary contents each time they encounter an instance of a specific data type. The client should use the DataTypeVersion property to determine whether the locally cached copy is still valid. If the client detects a change to the DataTypeVersion, then it shall re-read the data type dictionary. This implies that the DataTypeVersion shall be updated by a server even after restart since clients may persistently store the locally cached copy.

The Value attribute of the data type dictionary containing the type descriptions is a ByteString whose formatting is defined by the data type system. For the “XML Schema” data type system, the ByteString contains a valid XML schema document. For the “OPC Binary” data type system, the ByteString contains a string that is a valid XML document. The server shall ensure that any change to the contents of the ByteString is matched with a corresponding change to the DataTypeVersion property. In other words, the client may safely use a cached copy of the data type dictionary, as long as the DataTypeVersion remains the same.

Data type dictionaries are complex variables which expose their data type descriptions as Variable nodes using HasComponent references. A data type description provides the information necessary to find the formal description of a DataType within the data type dictionary. The Value of a data type description depends on the data type system of the data type dictionary. When using “OPC Binary” dictionaries the Value attribute shall be the name of the type description. When using “XML Schema” dictionaries the Value shall be an Xpath expression XPATH which points to an XML element in the schema document.

Like data type dictionaries each data type description provides the property DataTypeVersion indicating whether the type description of the DataType has changed. Changes to the DataTypeVersion may impact the operation of subscriptions. If the DataTypeVersion changes for a Variable that is being monitored for a subscription and that uses this data type description, then the next data change notification sent for the Variable will contain a status that indicates the change in the data type description.

Data type encoding objects reference their data type descriptions of the data type dictionaries using HasDescription references. However, servers are not required to provide the inverse references that relate the data type descriptions back to the data type encoding objects. If a DataType node is exposed in the Address Space, it shall provide its data type encodings and if a data type dictionary is exposed, it should expose all its data type descriptions. Both of these references shall be bi-directional.

Figure 3 gives an example how data types are modeled in the Address Space.

Figure 3: Example of DataType modeling

In some scenarios an OPC Unified Architecture server may have resource limitations which make it impractical to expose large data type dictionaries. In these scenarios the server may be able to provide access to descriptions for individual data types even if the entire dictionary cannot be read. For this reason, the OPC Unified Architecture specification defines a property for the data type description called DictionaryFragment (see Variable). This property is a ByteString that contains a subset of the data type dictionary which describes the format of the DataType associated with the data type description. Thus the server splits the large data type dictionary into several small parts clients can access without affecting the overall system performance.

However, servers should provide the whole data type dictionary at once and if this is possible. Clients can typically act more effective reading the whole data type dictionary at once instead of reading several parts and building their own data type dictionary over a period of time.

Other Resources