Click or drag to resize

How to Use the Address Space Model

Home

This topic contains the following sections:

This topic points out some general considerations how the Address Space model can be used. Each server vendor can model its data in the appropriated way that fits to its needs, however, this topic gives some hints the server vendor may consider.

Typically OPC Unified Architecture 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 on the clients accessing the OPC Unified Architecture server. It is also expected that companion specifications will be developed on top of OPC Unified Architecture with additional rules how to model the data. However, the following subclauses will give some general consideration about the different concepts of OPC Unified Architecture to model data and when they should be used and when not.

The subsection Design decisions when modelling the server information gives an overview over the design decisions made when modelling the information about the server described in section Information Model.

Type Definitions

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.

Object Types

Section Object states: “Objects are used to represent systems, system components, real-world objects, and software objects.” Therefore object types should be used if a type definition of those is useful.

From a more abstract point of view objects are used to group variables and other objects in the Address Space. Therefore object types 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 (described in section Services) on the instances.

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

Variable Types

This section contains the following subsections:

Variable types are only used for data variables and should be used when there are several variables having the same semantic (e.g. set point). It is not needed to define a VariableType just reflecting the data type of the Variable, e.g. an “Int32VaraibleType”.

Properties or Data Variables

Besides the semantic differences of properties and data variables there are also syntactic differences. A property is identified by its BrowseName, i.e. if properties having the same semantic are used several times, they should always have the same BrowseName. The same semantic of data variables is captured in the VariableType.

If it’s not clear what concept to use based on the semantic described in Address Space, the different syntax can help. The following points identify that it has to be a data variable:

  • If it’s 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 (described in section Services) to create new instances of the type definition.

  • If it’s a component of a complex Variable exposing a part of the value of the complex Variable.

Many Variables and / or Complex Data Types

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

  1. Create several simple variables using simple data types always reflecting parts of the simple structure. Objects are used to group the variables according to the structure of the data.

  2. Create a complex data types and a simple Variable using this type.

  3. Create a complex data type and a complex Variable using this type and also exposing the complex data structure as variables of the complex Variable using simple data types

The advantages of the first approach are that the complex structure of the data is visible in the Address Space; a generic client can easily access those data without knowledge of user-defined data types; and the client can access individual parts of the complex 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 are accessed in a transaction context and the complex data type can be constructed in a way that the server does not have to convert the data and can pass them 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 data type description to interpret the data. The structure of the data is not visible in the Address Space; additional properties describing the data structure cannot be added to the adequate places since they do not exist in the Address Space. Individual parts of the data cannot be read without accessing the whole data structure.

The third approach combines both other approaches. Therefore the specific client can access the 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 shall be able to provide the native format and also interpret it to be able to provide the information in simple data types.

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, the third approach is suitable. However, the server might not always have the knowledge to interpret the complex 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.

Views

Server-defined View nodes can be used to present an excerpt of the Address Space suitable for a special class of clients, e.g. maintenance clients, engineering clients, etc. The View only provides the information needed for the purpose of the client and hides unnecessary information.

Methods

Methods should be used whenever some input is expected and the server delivers a result. One should avoid using Variable nodes to write the input values and other variables to get the output results as it was needed 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, i.e. methods that cannot directly be assigned to a special object, should be assigned to the Server object.

Defining Reference Types

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

It is expected that servers will have new defined hierarchical reference types to expose different hierarchies and new non-hierarchical references to expose relationships between nodes in the Address Space.

Defining Modelling Rules

New modelling rules have to be defined if the predefined once are not appropriated for the model exposed by the server.

Depending on the model used by the underlying system the server may need to define new modelling rules, since the OPC Unified Architecture 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 modelling rules might not be sufficient to specify the needed behaviour for instantiation and subtyping.

See Also