Errata exists for this version of the document.

This annex describes the design decisions of modelling the information provided by each OPC UA Server, exposing its capabilities, diagnostic information, and other data needed to work with the Server, such as the NamespaceArray.

This annex gives an example of what should be considered when modelling data using the Address Space Model. General considerations for using the Address Space Model can be found in OPC 10000-3.

This annex is for information only, that is, each Server vendor can model its data in the appropriate way that fits its needs.

The following subclauses describe the design decisions made while modelling the Server Object. General DataTypes, VariableTypes and ObjectTypes such as the EventTypes described in this standard are not taken into account.

The first decision is to decide at what level types are needed. Typically, each Server will provide one Server Object with a well-known NodeId. The NodeIds of the containing Nodes are also well-known because their symbolic name is specified in this standard and the NodeId is based on the symbolic name in OPC 10000-6. Nevertheless, aggregating Servers may want to expose the Server Objects of the OPC UA Servers they are aggregating in their AddressSpace. Therefore, it is very helpful to have a type definition for the Server Object. The Server Object is an Object, because it groups a set of Variables and Objects containing information about the Server. The ServerType is a complex ObjectType, because the basic structure of the Server Object should be well-defined. However, the Server Object can be extended by adding Variables and Objects in an appropriate structure of the Server Object or its containing Objects.

Objects beneath the Server Object used to group information, such as Server capabilities or diagnostics, are also typed because an aggregating Server may want to provide only part of the Server information, such as diagnostics information, in its AddressSpace. Clients are able to program against these structures if they are typed, because they have its type definition.

Since the general description in OPC 10000-3 about the semantic difference between Properties and DataVariables are not applicable for the information provided about the Server the rules described in OPC 10000-3 are used.

If simple data structures should be provided, Properties are used. Examples of Properties are the NamespaceArray of the Server Object and the MinSupportedSampleRate of the ServerCapabilities Object.

If complex data structures are used, DataVariables are used. Examples of DataVariables are the ServerStatus of the Server Object and the ServerDiagnosticsSummary of the ServerDiagnostics Object.

DataVariables providing complex data structures expose their information as complex DataTypes, as well as components in the AddressSpace. This allows access to simple values as well as access to the whole information at once in a transactional context.

For example, the ServerStatus Variable of the Server Object is modelled as a complex DataVariable having the ServerStatusDataType providing all information about the Server status. But it also exposes the CurrentTime as a simple DataVariable, because a client may want to read only the current time of the Server, and is not interested in the build information, etc.

A special case of providing complex data structures is an array of complex data structures. The SubscriptionDiagnosticsArrayType is an example of how this is modelled. It is an array of a complex data structure, providing information of a subscription. Because a Server typically has several subscriptions, it is an array. Some clients may want to read the diagnostic information about all subscriptions at once; therefore it is modelled as an array in a Variable. On the other hand, a client may be interested in only a single entry of the complex structure, such as the PublishRequestCount. Therefore, each entry of the array is also exposed individually as a complex DataVariable, having each entry exposed as simple data.

Note that it is never necessary to expose the individual entries of an array to access them separately. The Services already allow accessing individual entries of an array of a Variable. However, if the entries should also be used for other purposes in the AddressSpace, such as having References or additional Properties or exposing their complex structure using DataVariables, it is useful to expose them individually.

Providing redundant information should generally be avoided. But to fulfil the needs of different clients, it may be helpful.

Using complex DataVariables automatically leads to providing redundant information, because the information is directly provided in the complex DataType of the Value Attribute of the complex Variable, and also exposed individually in the components of the complex Variable.

The diagnostics information about subscriptions is provided in two different locations. One location is the SubscriptionDiagnosticsArray of the ServerDiagnostics Object, providing the information for all subscriptions of the Server. The second location is the SubscriptionDiagnosticsArray of each individual SessionDiagnosticsObject Object, providing only the subscriptions of the session. This is useful because some clients may be interested in only the subscriptions grouped by sessions, whereas other clients may want to access the diagnostics information of all sessions at once.

The SessionDiagnosticsArray and the SessionSecurityDiagnosticsArray of the SessionsDiagnosticsSummary Object do not expose their individual entries, although they represent an array of complex data structures. But the information of the entries can also be accessed individually as components of the SessionDiagnostics Objects provided for each session by the SessionsDiagnosticsSummary Object. A client can either access the arrays (or parts of the arrays) directly or browse to the SessionDiagnostics Objects to get the information of the individual entries. Thus, the information provided is redundant, but the Variables containing the arrays do not expose their individual entries.

All DataVariables used to expose complex data structures of complex DataVariables have the BaseDataVariableType as type definition if they are not complex by themselves. The reason for this approach is that the complex DataVariables already define the semantic of the containing DataVariables and this semantic is not used in another context. It is not expected that they are subtyped, because they should reflect the data structure of the DataType of the complex DataVariable.

Subtyping is used for modelling information about the redundancy support of the Server. Because the provided information shall differ depending on the supported redundancy of the Server, subtypes of the ServerRedundancyType will be used for this purpose.

Subtyping is also used as an extensibility mechanism (see A.10).

The information of the Server will be extended by other parts of this series of standards, by companion specifications or by Server vendors. There are preferred ways to provide the additional information.

Do not subtype DataTypes to provide additional information about the Server. Clients might not be able to read those new defined DataTypes and are not able to get the information, including the basic information. If information is added by several sources, the DataType hierarchy may be difficult to maintain. Note that this rule applies to the information about the Server; in other scenarios this may be a useful way to add information.

Add Objects containing Variables or add Variables to the Objects defined in this part. If, for example, additional diagnostic information per subscription is needed, add a new Variable containing in array with an entry per subscription in the same places that the SubscriptionDiagnosticsArray is used.

Use subtypes of the ServerVendorCapabilityType to add information about the server-specific capabilities on the ServerCapabilities Objects. Because this extensibility point is already defined in this part, clients will look there for additional information.

Use a subtype of the VendorServerInfoType to add server-specific information. Because an Object of this type is already defined in this part, clients will look there for server-specific information.