VariableTypes are only used for DataVariables and should be used when there are several Variables having the same semantic (e.g. set point). It is not necessary to define a VariableType that only reflects the DataType of a Variable, e.g. an “Int32VariableType”.

Besides the semantic differences of Properties and DataVariables described in Clause 4 there are also syntactical differences. A Property is identified by its BrowseName, that is, if Properties having the same semantic are used several times, they should always have the same BrowseName. The same semantic of DataVariables is captured in the VariableType.

If it is not clear which concept to use based on the semantic described in Clause 4, then the different syntax can help. The following points identify when it shall be a DataVariable.

• If it is a complex Variable or it should contain additional information in the form of Properties.
• If the type definition may be refined (subtyping).
• If the type definition should be made available so the Client can use the AddNodes Service defined in OPC 10000-4 to create new instances of the type definition.
• If it is a component of a complex Variable exposing a part of the value of the complex Variable.

When structured data structures should be made available to the Client there are basically three different approaches:

1. Create several simple Variables using simple DataTypes always reflecting parts of the simple structure. Objects are used to group the Variables according to the structure of the data.
2. Create a Structured DataType and a simple Variable using this DataType.
3. Create a Structured DataType and a complex Variable using this DataType and also exposing the structured data structure as Variables of the complex Variable using simple DataTypes.

The advantages of the first approach are that the complex structure of the data is visible in the AddressSpace. A generic Client can easily access the data without knowledge of user-defined DataTypes and the Client can access individual parts of the structured data. The disadvantages of the first approach are that accessing the individual data does not provide any transactional context and for a specific Client the Server first has to convert the data and the Client has to convert the data, again, to get the data structure the underlying system provides.

The advantages of the second approach are, that the data is accessed in a transactional context and the Structured DataType can be constructed in a way that the Server does not have to convert the data and can pass directly to the specific Client that can directly use them. The disadvantages are that the generic Client might not be able to access and interpret the data or has at least the burden to read the DataTypeDefinition to interpret the data. The structure of the data is not visible in the AddressSpace; additional Properties describing the data structure cannot be added to the adequate places since they do not exist in the AddressSpace. Individual parts of the data cannot be read without accessing the whole data structure.

The third approach combines the other two approaches. Therefore a specific Client can access data in its native format in a transactional context, whereas a generic Client can access simple DataTypes of the components of the complex Variable. The disadvantage is that the Server must be able to provide the native format and also interpret it to be able to provide the information in simple DataTypes.

It is recommended to use the first approach. 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, then the third approach is suitable. However, the Server might not always have the knowledge to interpret the structured data of the underlying system and therefore has to use the second approach just passing the data to the specific Client who is able to interpret the data.