Design decisions when modelling the server information

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 part and the NodeId is based on the symbolic name in section Mappings. Nevertheless, aggregating servers may want to expose the Server Objects of the OPC Unified Architecture servers they are aggregating in their Address Space. 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 Address Space. Clients are able to program against these structures if they are typed, because they have its type definition.

Since the general description in section Address Space about the semantic difference between Properties and data variables are not applicable for the information provided about the server the rules described in section Address Space 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, data variables are used. Examples of data variables are the ServerStatus of the Server Object and the ServerDiagnosticsSummary of the ServerDiagnostics Object.

data variables providing complex data structures expose their information as complex DataTypes, as well as components in the Address Space. 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

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 Address Space – such as having References or additional Properties or exposing their complex structure using data variables – 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 data variables 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 data variables used to expose complex data structures of complex data variables have the BaseDataVariableType as type definition if they are not complex by themselves. The reason for this approach is that the complex data variables already define the semantic of the containing data variables 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 next Clause).

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.