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 Servervendor 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, VariableTypesand ObjectTypessuch as the EventTypesdescribed in this standard are not taken into account.
The first decision is to decide at what level types are needed. Typically, each Serverwill provide one Server Objectwith a well-known NodeId. The NodeIdsof the containing Nodesare also well-known because their symbolic name is specified in this standard and the NodeIdis based on the symbolic name in OPC 10000-6. Nevertheless, aggregating Serversmay want to expose the Server Objectsof the OPC UA Serversthey are aggregating in their AddressSpace. Therefore, it is very helpful to have a type definition for the Server Object. The Server Objectis an Object, because it groups a set of Variablesand Objectscontaining information about the Server. The ServerTypeis a complex ObjectType, because the basic structure of the Server Objectshould be well-defined. However, the Server Objectcan be extended by adding Variablesand Objectsin an appropriate structure of the Server Objector its containing Objects.
Objectsbeneath the Server Objectused to group information, such as Servercapabilities or diagnostics, are also typed because an aggregating Servermay want to provide only part of the Serverinformation, 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-3about the semantic difference between Propertiesand DataVariablesare not applicable for the information provided about the Serverthe rules described in OPC 10000-3are used.
DataVariablesproviding 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 Variableof the Server Objectis modelled as a complex DataVariablehaving the ServerStatusDataTypeproviding all information about the Serverstatus. But it also exposes the CurrentTimeas 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 SubscriptionDiagnosticsArrayTypeis an example of how this is modelled. It is an array of a complex data structure, providing information of a subscription. Because a Servertypically 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 Servicesalready 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 Referencesor additional Propertiesor 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 DataVariablesautomatically leads to providing redundant information, because the information is directly provided in the complex DataTypeof the Value Attributeof 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 SubscriptionDiagnosticsArrayof the ServerDiagnostics Object, providing the information for all subscriptions of the Server. The second location is the SubscriptionDiagnosticsArrayof 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 SessionDiagnosticsArrayand the SessionSecurityDiagnosticsArrayof the SessionsDiagnosticsSummary Objectdo 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 Objectsprovided 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 Objectsto get the information of the individual entries. Thus, the information provided is redundant, but the Variablescontaining the arrays do not expose their individual entries.
All DataVariablesused to expose complex data structures of complex DataVariableshave the BaseDataVariableTypeas type definition if they are not complex by themselves. The reason for this approach is that the complex DataVariablesalready define the semantic of the containing DataVariablesand 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 DataTypeof 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 ServerRedundancyTypewill be used for this purpose.
Subtyping is also used as an extensibility mechanism (see A.10).
The information of the Serverwill be extended by other parts of this series of standards, by companion specifications or by Servervendors. There are preferred ways to provide the additional information.
Do not subtype DataTypesto provide additional information about the Server. Clients might not be able to read those new defined DataTypesand are not able to get the information, including the basic information. If information is added by several sources, the DataTypehierarchy 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 Objectscontaining Variablesor add Variablesto the Objectsdefined in this part. If, for example, additional diagnostic information per subscription is needed, add a new Variablecontaining in array with an entry per subscription in the same places that the SubscriptionDiagnosticsArrayis used.
Use subtypes of the ServerVendorCapabilityTypeto 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 VendorServerInfoTypeto add server-specific information. Because an Objectof this type is already defined in this part, clients will look there for server-specific information.