Annex A points out some general considerations on how the Address Space Model can be used. Annex A is for information only, that is, each Server vendor can model its data in the appropriate way that fits its needs. However, it gives some hints the Server vendor may consider.

Typically OPC UA Servers will offer data provided by an underlying system like a device, a configuration database, an OPC COM Server, etc. Therefore the modelling of the data depends on the model of the underlying system as well as the requirements of the Clients accessing the OPC UA Server. It is also expected that companion specifications will be developed on top of OPC UA with additional rules on how to model the data. However, the remainder of Annex A will give some general considerations about the different concepts of OPC UA to model data and when they should be used, and when not.

OPC 10000-5:–, Annex A, provides an overview of the design decisions made when modelling the information about the Server defined in OPC 10000-5.

Type definitions should be used whenever it is expected that the type information may be used more than once in the same system or for interoperability between different systems supporting the same type definitions.

Subclause 5.5.1 states: “Objects are used to represent systems, system components, real-world objects, and software objects.” Therefore ObjectTypes should be used if a type definition of those ObjectTypes is useful (see A.2).

From a more abstract point of view Objects are used to group Variables and other Objects in the AddressSpace. Therefore ObjectTypes should be used when some common structures/groups of Objects and/or Variables should be described. Clients can use this knowledge to program against the ObjectType structure and use the TranslateBrowsePathsToNodeIds Service defined in OPC 10000-4 on the instances.

Simple objects only having one value (e.g. a simple heat sensor) can also be modelled as VariableTypes. However, extensibility mechanisms should be considered (e.g. a complex heat sensor subtype could have several values) and whether that object should be exposed as an object in the Client's GUI or just as a value. Whenever a modeller is in doubt as to which solution to use the ObjectType having one Variable should be preferred.

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.

Server-defined Views can be used to present an excerpt of the AddressSpace suitable for a special class of Clients, for example maintenance Clients, engineering Clients, etc. The View only provides the information needed for the purpose of the Client and hides unnecessary information.

Methods should be used whenever some input is expected and the Server delivers a result. One should avoid using Variables to write the input values and other Variables to get the output results as it was necessary to do in OPC COM since there was no concept of a Method available. However, a simple OPC COM wrapper might not be able to do this.

Methods can also be used to trigger some execution in the Server that does not require input and / or output parameters.

Global Methods, that is, Methods that cannot directly be assigned to a special Object, should be assigned to the Server Object defined in OPC 10000-5.

Defining new ReferenceTypes should only be done if the predefined ReferenceTypes are not suitable. Whenever a new ReferenceType is defined, the most appropriate ReferenceType should be used as its supertype.

It is expected that Servers will have new defined hierarchical ReferenceTypes to expose different hierarchies, and new Nonhierarchical ReferenceTypes to expose relationships between Nodes in the AddressSpace.

New ModellingRules have to be defined if the predefined ModellingRules are not appropriate for the model exposed by the Server.

Depending on the model used by the underlying system the Server may need to define new ModellingRules, since the OPC UA Server may only pass the data to the underlying system and this system may use its own internal rules for instantiation, subtyping, etc.

Beside this, the predefined ModellingRules might not be sufficient to specify the required behaviour for instantiation and subtyping.