1 Scope

This part of the OPC UA Standard provides a definition of AliasNames functionality. AliasNames provide a manner of configuring and exposing an alternate well-defined name for any Node in the system. This is analogous to the way domain names are used as an alias to IP addresses in IP networks. Like a DNS Server, an OPC UA Server that supports AliasNames provides a lookup Method that will translate an AliasName to a NodeId of the related Node on a Server. An aggregating Server can collect these AliasNames from multiple Servers and provide a lookup Method to allow Client applications to discover NodeIds on a system wide basis. An aggregating Server could also define AliasNames for Nodes in other Servers that do not support AliasNames. A GDS may be constructed that would automatically aggregate all AliasNames that are defined on any Server that has registered with the GDS. In this case the GDS also provides the lookup mechanism for Clients at a well-known endpoint and address. Examples for the use of AliasNames are in Annex A. The GDS functionality for AliasNames is formally defined in Annex C.

2 Normative references

The following referenced documents are indispensable for the application of this specification. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments and errata) applies.

OPC 10000-1, OPC Unified Architecture - Part 1: Overview and Concepts

3 Terms, definitions and abbreviated terms

3.1 Terms and definitions

For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, OPC 10000-4, OPC 10000-5, OPC 10000-7,OPC 10000-12, and OPC 10000-14 apply.

All used terms are italicized in the specification.

3.1.1 AliasName

alternate well-defined name for any Node in the system

3.2 Abbreviated terms

4 Use cases

4.1 Complex configuration

For systems that are large and complex, engineering is often done in multiple tools and by multiple individuals. The separate configurations are required to work together, but resolving the references between these different configurations can be a significant task. A common solution to simplify this task is a naming convention for the items that are being referenced. Providing an automatic lookup capability for these names would greatly simplify configuration. Each system can specify its own names and configurations can be built to just use the names, without having to know the exact address of the items. The exact address would include the address of the Server, the address of the tag in the Server, the required protocol for connecting to the Server, security settings etc. OPC UA defines a GDS that can provide information about what Servers are available in a system and how to connect to them, but it does not currently provide information about the tags that are available in a given Server.

4.2 Automatic reconfiguration

In a system where many smaller Servers exist and these Servers could be dynamic, in that new Servers can appear and disappear. Configuration could move between Servers. The ability to detect the new configurations and the automatic resolution of where a specific piece of information is located would greatly simplify these systems.

4.3 Cloud based system

Much like the previous use case, a cloud-based system, where Servers can be spun up in a new cloud system or adjusted and split based on loading to multiple Servers. The ability to detect the new configurations and the automatic resolution of where a specific piece of information is located would greatly simplify these systems.

4.4 Aggregated systems

In systems where many simple devices exist, any given simple device could not have the ability to provide name resolution, yet these systems can be much like systems in one of the previous use cases. In a system such as this, an aggregating Server could exist, where the aggregating Server would provide the names as well as the lookup for the underlying Server. This aggregating Server could also provide other functionality such as aggregation of values, but it could only provide the name definitions and resolutions. The underlying Server could have no knowledge of the AliasName.

4.5 Device replacement

In systems where devices are replaced, the replacement device often needs to be configured, where the configuration can include the addition of an AliasName. An interface for adding AliasNames and AliasNameCategories would allow a standard configuration to setup the device. In the case where a device is moved and reconfigured, it may be required to first delete the AliasNames and AliasNameCategories in the device.

5 AliasNames Information Model overview

The AliasNames functionality (illustrated in Figure 1) defines a number of ObjectTypes, Methods, DataTypes and References. Figure 2 illustrates an example of the Object model defined for AliasNames.

The model also includes some well-known fixed instances. The key functionality of AliasNames is to reference the information that an AliasName is assigned to. These can be any Node. The AliasNames can be grouped according to types of functionality. The OPC Foundation defines some initial groups, but the groups can be extended by companion specifications, vendors or end users to meet their needs.

Examples for the use of AliasNames are in Annex A. Aggregating AliasNames is formally defined in Annex B. The GDS functionality for AliasNames is formally defined in Annex C. The PubSub Alias Update header layout is formally defined in Annex D.

6 OPC UA ObjectTypes

6.1 Overview

An overview of this object model is provided in Clause 5. Figure 1 illustrates the overall AliasName Object Model

6.2 AliasNameType ObjectType Definition

Instances of the AliasNameType ObjectType provide alternate names for Nodes. The AliasNameType is formally defined in Table 1.

This ObjectType has no Properties or Variables. The BrowseName of the Object is used as the alias name. The string part of the BrowseName shall be the DisplayName with an empty locale id and no other locale shall be provided. This Object shall have at least one AliasFor Reference (or subtype of).

A Client shall always ignore the namespace associated with an AliasName for comparison with other AliasNames. AliasName can be defined in Namespace 1 (the local Server) or in some vendor defined namespace. See OPC 10000-3 for additional details on Namespaces.

The AliasName Object’s BrowseName shall not be modified once it is defined. If an AliasName is to be changed, it shall be a deletion of the old AliasName and the addition of the new AliasName. This requirement allows aggregating Servers to detect new AliasNames. The deletion and then addition of an AliasName results in a new NodeId for the AliasName.

6.3 AliasNameCategoryType ObjectType Definition

6.3.1 Definition

AliasNameCategoryType instances are used to organize the AliasNameType instances that a Server defines. They can also include instances of AliasNameCategoryType to allow hierarchical groupings of AliasNames. It includes a mandatory Method for finding instances of AliasNameType in the AliasName hierarchy, starting at this instance of AliasNameCategoryType. For example, if the Method call is made on the Aliases AliasNameCategoryType instance (see 9.2), it would apply the AliasNameSearchPattern to all AliasNames that are defined under TagVariables, Topics and any other AliasNameCategoryType instance in the hierarchy.

Well-known AliasNameCategories are defined in this document. Other documents may also define well-known AliasNameCategories. A well-known AliasNameCategory has a static NodeId allowing it to be aggregated. For details on aggregation of AliasName and AliasNameCategories see Annex B.

The AliasNameCategoryType is a subtype of FolderType and is formally defined in Table 2.

The list of AliasNames that an Object contains could be dynamic. For example, AliasNames could be added in an aggregating Server as underlying Servers become available or could be removed if a Server is no longer available.

<Alias> represents any number of instances of AliasNameType. Each instance shall have at least one AliasFor Reference to a Node. Multiple <Alias> instances can point to the same Node.

<SubAliasNameCategories> allows the nesting or structuring of AliasNames into hierarchical groupings.

An <Alias> can appear in more than one place in the hierarchy of AliasNameCategories.

LastChange is the most recent time for any of the following activities:

The last time an AliasName was added to or deleted from the AliasNameCategory,

The last time an AliasNameCategory was added or deleted,

The last time the referenced Nodes of an AliasName in the AliasNameCategory changed.

For AliasNameCategoryType instances that are nested, the value of LastChange shall always be the latest VersionTime of all Organized AliasNames and AliasNameCategories.

The LastChange shall be persisted. A Client that detects a LastChange that is older than what it has cached, shall clear all cached AliasNameCategories and related AliasNames.

6.3.2 FindAlias Method

The FindAlias Method allows a Client to obtain the list of Nodes that match the provided AliasName search string. The signature of this Method is specified below, the arguments are defined in Table 3.

Signature

	FindAlias(
	  [in]  String				AliasNameSearchPattern,
	  [in]  NodeId				ReferenceTypeFilter,
	  [out] AliasNameDataType[]	AliasNodeList
	);

Method result codes are defined in Table 4

The Method is formally defined in Table 5.

It is important to note that there could be more than one entry for every AliasName. Multiple Servers could provide a Node that represents an equivalent object (such as a temperature sensor). An aggregating Server could also provide the Node. This Method will return the AliasNames in order of preference. That is the Server will return what it recommends as the best match first followed by the next best match etc. The criteria for ordering are Server specific. The criteria could be based on the ServerStatus of the Server that contains the referenced Node, it could be load balancing of Servers, it could be for off-loading of small device Servers, or it could be some other algorithm.

Clients should use the first usable entry in the list.

6.3.3 FindAliasVerbose Method

The FindAliasVerbose Method extends the FindAlias Method, by providing additional information in the returned data, all other aspects of the Method are identical to FindAlias. The signature of this Method is specified below; the arguments are defined in Table 6.

Signature

	FindAliasVerbose(
	  [in]  String					AliasNameSearchPattern,
	  [in]  NodeId					ReferenceTypeFilter,
	  [out] AliasNameVerboseDataType[]	AliasNodeList
	);

Method result codes are defined in Table 7.

The Method is formally defined inTable 8.

The FindAliasVerbose Method provides additional information in the AliasNameVerboseDataType, including AliasNameCategory information and ServerUri Information, see 7.3 for details.

6.3.4 AddAliasesToCategory Method

The AddAliasesToCategory Method allows a Client to add an AliasName to the AliasNameCategory. The signature of this Method is specified below, the arguments are defined in Table 9.

Signature

	AddAliasesToCategory( 
	  [in] String[]		AliasNames,	
	  [in] ExpandedNodeId[]	TargetNodes,
	  [in] String[]		TargetServers,
	  [in] NodeId			TargetReferenceType,
	  [out] StatusCode[]	ErrorCodes
	);

The generated AliasName Nodes are assigned a Server specific NodeId.

If the same AliasName is to reference multiple TargetNodes then the AliasName shall be listed in the AliasNames array multiple times, one for each TargetNode.

It is not required for an AliasName Server to check the existence of external Nodes (i.e. Nodes that are not on the Server hosting the AliasName). If a Server does check for external Nodes, it shall not fail the addition if the Server or Node on the external Server is not available, it shall return Uncertain_ReferenceOutOfServer. If the Server does not check for the external Node’s existence, it shall return Uncertain_ReferenceOutOfServer.

If an entry in the parallel arrays duplicates an existing AliasName entry (exact same AliasName, TargetNode and TargetServer) or it appears more than once in the array it shall be ignored and no error shall be generated.

The list of StatusCodes that could be returned in ErrorCodes is defined in Table 10.

Method result codes are defined in Table 11.

The Method is formally defined in Table 12.

6.3.5 DeleteAliasesFromCategory Method

The DeleteAliasesFromCategory Method allows a Client to remove AliasNames from the AliasNameCategory. The signature of this Method is specified below; the arguments are defined in Table 13.

This Method shall only delete AliasName instances that are defined on the Server exposing this Method. I.e. an aggregating Server that has pulled AliasName instances from an aggregated Server cannot delete AliasName instances that are from the aggregated Server.

Signature

	DeleteAliasesFromCategory  
	(
	  [in] String[]		AliasNames,
	  [in] ExpandedNodeId []	TargetNodes,
	  [out] StatusCode[]	ErrorCodes
	);

The length of each of the arrays shall be the same.

If the TargetNodes array entry is null or empty, all AliasNames with the provided name are deleted from the AliasNameCategory. If all targets for an AliasNames array entry cannot be deleted, then none of the targets are deleted.

The list of StatusCodes that could be returned in ErrorCodes is defined in Table 14

Method result codes are defined in Table 15

The Method is formally defined in Table 16.

7 OPC UA DataTypes

7.1 Overview

The following DataTypes are defined for the AliasNames model.

7.2 AliasNameDataType

This DataType defines a structure that can contain an array of ExpandedNodeId for a single AliasName. Its elements are defined in Table 17. It will always have at least one entry in the ReferencedNodes array.

Its representation in the AddressSpace is defined in Table 18.

7.3 AliasNameVerboseDataType

This DataType defines a structure that can contain an array of ExpandedNodeId for a single AliasName. Its elements are defined in Table 19. It will always have at least one entry in the ReferencedNodes array.

Its representation in the AddressSpace is defined in Table 20.

8 Reference Types

8.1 Overview

The following References are defined for the AliasNames model.

8.2 AliasFor ReferenceType

This reference is a subtype of NonHierarchicalReferences.

The semantic of this ReferenceType is to link AliasNameType instances to the Nodes they represent. The inverse reference is not required, i.e. the Nodes might not have a reference back to instance of AliasNameType.

The SourceNode of References of this type shall be an Object of type AliasNameType.

The TargetNode of this ReferenceType can be of any NodeClass.

Figure 2 provides an illustration of how this ReferenceType is used. It is defined in Table 21.

9 Instances

9.1 Overview

The following standard Objects are defined for maintaining the hierarchical structure of AliasNameCategories in a Server. Server vendors are free to add additional instances of AliasNameCategoryType under this hierarchy.

9.2 Aliases

The Aliases Node is formally defined in Table 22.

This is the root folder for all alias related Objects. It can contain instances of AliasNameType Objects and / or instances of AliasNameCategoryType Objects.

The LastChange Property, which is optional in the AliasNameCategoryType, shall be present for the root Aliases instance. This property shall reflect the last time any changes to AliasName occurred (see 6.3).

9.3 TagVariables

TagVariables is an instance of AliasNameCategoryType. TagVariables shall restrict instances of AliasNameType to those that have an AliasFor References that point to Variables. The TagVariables instance is formally defined in Table 23.

This is the root folder for AliasNameType instances that contain an AliasFor reference to Variables. It can contain additional AliasNameCategoryType Objects, which could be used to create a hierarchy. A single instance of AliasNameType can exist in more than one location in the Alias hierarchy.

9.4 Topics

Topics is an instance of AliasNameCategoryType. Topics shall restrict instances of AliasNameType to only have AliasFor References that point to PublishedDataSetType (or subtypes) instances (PublishedDataSetType is defined in OPC 10000-14). The Topics Node instance is formally defined in Table 24.

It can contain additional AliasNameCategoryType Objects, which could be used to create a hierarchy or other structure. A single instance of AliasNameType can exist in more than one location in the hierarchy, but all instances in the Topics hierarchy must point to an instance of a PublishedDataSetType.

Annex A Examples (Informative)

A.1 Overview

A number of examples are provided to help illustrate how AliasNames function. This includes a Client using an AliasName Server, inside of a Server, in an aggregating Server and in a GDS.

A.2 AliasNames used within a single Server

Figure A.1 illustrates how this model can be used inside of a Server. This sample includes multiple instances of AliasNameCategoryType. The figure illustrates that Objects could be referenced by more than one instance of AliasNameType.

The figure describes an information model for a well. This model contains a number of other Objects, which have Variables that are to be available via a standardized naming scheme. The model also includes a configuration for a PubSub DataSet (see OPC 10000-14) that provides the Variables defined in the well.

The AliasName model includes the standard organization items that are required in this document. In addition, the model also defines an extra organizational item for grouping the well information. The example illustrates AliasNames that are both TagVariables and Topics.

A.3 AliasNames in an aggregating Server

An aggregating Server would have much the same structure as the Server in the first example, with the exception that in the aggregating Server the target Nodes referenced by the AliasFor Reference could be in other Servers. Figure A.2 provides an illustration of an example aggregating Server. The Server could have a much more complex AddressSpace than provided in the example.

The aggregating Server has a choice in that it could just provide the link to the underlying Node (blue lines) or it could provide a link to the replicated Node in the aggregated Server’s AddressSpace (red lines).

A.4 Standalone AliasNames Server

The standalone AliasNames Server illustrated in Figure A.3 provides a list of AliasNames that reference Nodes in multiple separate Servers. This type of configuration could be used for Servers that do not have the resources to manage AliasNames on their own. It could also be used in a system where the configuration of AliasNames occurs after the devices that are represented by the Servers have already been deployed or if a Server just does not have support for AliasNames. The standalone AliasNames Server can function as a lookup Server for all of the AliasNames defined in the system. It is the responsibility of the standalone AliasNames Server to ensure that the mapping of AliasNames to actual Nodes is correct.

A.5 Client use of an AliasName Server

AliasNames allow a Client to find TagVariables or Topics easily. Many industrial systems assign tags to specific measurement or sensors. These tags follow established nomenclatures. An example tag is TI101, which is a temperature indicator at a specific location in a plant. The example nomenclature is defined in ANSI/ISA-S5.1-1984 (R 1992), but this specification does not provide or even suggest any nomenclature. A Client could be configured to display or use the information provided by the sensor TI101, but the actual address/location of this sensor is often not known when the Client is configured. AliasNames can be used to resolve this tag to the actual sensor in the system.

The Client, on start-up or when it wants to access the tag, would call FindAlias on a local Server, aggregating Server or GDS depending on how a system is configured. A Client could select which AliasName source to call via a configuration setting. The FindAlias Method call returns a list of all ExpandedNodeIds that the AliasName has a Reference to. It is important to note that there could be more than one Node referenced by an AliasName and that the Client must be prepared for this. The first Node in the list of referenced Nodes returned by the FindAlias Method is the Node that the Server feels is the best match for the requested tag. The returned list could also return more than one instance of AliasNameType and each could have their own list of referenced Nodes. If the Method call was on a GDS or aggregating Server, the Client reads the ServerArray to resolve which Server the ExpandedNodeId was referencing. This is the last piece of information that a Client requires to be able to follow a normal connection pattern to obtain values from the Node.

AliasName could also be configured to provide other information, such as PubSub information, but again it is only the information that is required to initially subscribe to or configure an item.

Annex B Aggregating AliasNames (Normative)

B.1 Aggregating Server with a collection of Aggregates

An aggregating Server as shown in Figure B.1 could also collect all of the AliasNames defined in underlying Servers and just build a composite list of these AliasNames. Since all of the AliasNames are required to exist under the mandatory Aliases Object, it is simple for an aggregating Server to browse the AddressSpace and build a list. The aggregating Server shall merge all AliasNames listed under the well-known AliasNameCategoryType instances. Some information models could define their own well-known AliasNameCategoryType Objects, which then also shall be merged. An aggregating Server could expose the same AliasName referencing multiple NodeIds. For example as shown in Figure B.1, if a temperature sensor were to be connected to two Servers for redundancy, the same AliasName TI101 could exist in both Servers. The aggregating Server simply reports two ExpandedNodeIds to any Client that requested TI101.

In the above example, if the Temperatures AliasNameCategoryType instance were defined locally in the Server and not defined in a standard namespace then two instances of the Temperatures AliasNameCategoryType will exist in the aggregating Server with different namespaces.

B.2 GDS

The GDS could include additional optional behaviour which this example illustrates. What is required is the availability of all AliasNames in the mandatory TagVariables folder and Topics folder, but a GDS could also choose to replicate or even merge the additional AliasNameCategoryType instances from the Servers that have registered. Figure B.2 provides an illustration of a GDS that merged the AliasNameCategory instance into a tree. A GDS shall aggregate AliasNameCategories, but the structure of these categories is not defined.

For additional information about a GDS and AliasNames see Annex C.

Annex C GDS functionality (Normative)

C.1 Overview

A Global Discovery Server (GDS) that supports AliasNames, provides AliasNames functionality, but the target Nodes referenced are in other Servers. The AliasNames are aggregated from the Servers that have registered with the GDS that expose the “Alias" capability (for information on capabilities see OPC 10000-12). Additional examples on aggregating AliasNames can be found in the aggregating Server section (B.1). A GDS implementation also requires additional behaviour.

Annex C describes automatic behaviour that is required by all implementations of a GDS that supports AliasNames. An example of a GDS that supports AliasNames is illustrated in Figure C.1.

Clauses in C.2, C.3 and C.4 describe this required behaviour:

When a Server registers with the GDS, the GDS shall merge the AliasNames of the registering Server into a master AliasNames list on the GDS.

Pull all AliasNameCategory instances, merge any that have identical Name part of the BrowseNames.

The GDS will provide the ExpandedNodeId of all of the referenced NodeIds and the ServerUri of the Server containing the NodeId.

The details of the expected behaviour of a GDS that supports AliasNames is described in clauses C.2, C.3 and C.4.

C.2 Register a Server

A GDS that includes support for AliasNames shall automatically aggregate all instances of AliasNameType that are available in any Server that has registered with the GDS. If the same AliasName is registered from different Servers, the GDS shall combine the AliasName within its Alias structure. The GDS shall add the ServerUri of the registered Server into its ServerArray Property. It shall provide a single merged tree list for any of the well-known AliasNameCategoryType Objects defined in 9.3 (i.e. TagVariables or Topics). The organization of the actual structure of the AliasNameCategoryType hierarchy is specific to the GDS vendor and/or the configuration of the GDS, but all AliasNameCategoryType instances shall be aggregated into the GDS. This hierarchy allows for a single instance of the AliasNameType to appear in more than one location in the tree. Figure C.2 illustrates the process a GDS that supports AliasNames would follow.

[Note: a GDS could encounter a large list of AliasNames and it is important that an efficient storage of AliasName is provided to allow for fast AliasName resolution (FindAlias).]

C.3 Unregister a Server

The GDS should automatically remove any instances of AliasNameType and AliasNameCategoryType that are associated with an unregistered Server. However, the AliasName instance or AliasNameCategory instance could be from multiple Servers and should only be removed if all of the Servers that referenced it have been removed. The GDS shall remove any AliasFor References that point to the unregistered Server. The GDS shall delete the ServerUri of the unregistered Server from the ServerArray Property. Figure C.3 illustrate the unregister process in a GDS.

C.4 Disconnect between a Client and an AliasName Server

When a Client that uses aliased Nodes detects a communication problem with the Server, the Client can return to the GDS and request a new AliasNodeList for the AliasName. The original Server could recover and again be listed in the GDS, but the Client is not required to switch back. Figure C.4provides an overview of this process.

It is important to remember that the FindAlias Method will return a list of NodeIds (and Servers) that meet the requested AliasName search string. It is up to the Client to determine if the NodeId that is returned is the same Server or on a different Server or if the next NodeId should be used instead of the first.

Annex D PubSub Alias Update Header Layout (Normative)

Editors Note: This Annex has limited implementation to validate the design. Subsequent implementations and interoperability testing may result in breaking changes in future versions of this Annex.

D.1 AliasName PubSub Notifications

D.1.1 Overview

An aggregating Server or GDS, needs to be able to discover the Servers that support AliasNames. Furthermore, the aggregating Server or GDS needs to be able to detect if a Server that contains AliasNames has had updates to the AliasName definitions. An aggregating Server or GDS could Subscribe for the LastChange Variable on AliasNameCategoryType instances to detect when a value is changed, but for systems with a large number of Servers the ClientServer connection might be difficult to manage. This section describes an extension for determining that a Server has had updates to the AliasName definitions. This extension to a Server that supports AliasNames, provides a Publisher capability for the Server (see OPC 10000-14). This extension also provides a simple way to determine if a Server has stopped or started.

D.1.2 PubSub multicast messages

With this optional extension, the Server shall be configured to be a Publisher with a fixed DataSet message sent to a multicast address. The DataSet shall consist of a single instance that has a DataType of AliasUpdateDataType (see D.2.2 for details). This Structure contains the ApplicationUri, and an array of a AliasCategoryUpdateDataType that consist of AliasNameCategoryId and the LastChange Variable (see D.2.1 for details). The value shall be published only when there is a change, i.e. either the LastChange Variable is updated (new timestamp) or an AliasNameCategory is add or removed, resulting in a change in the size of the AliasNameCategory array.

This Publisher shall provide a fixed DataSet with a pre-defined DataSetClassId. This Publisher shall generate messages as defined in D.3. These messages are similar to a data key frame / data delta frame type messages defined in OPC 10000-14. A data key frame message for the Publisher shall include an array with all AliasNameCatagory instances in the Server. A data delta frame message for the Publisher shall include an array with only AliasNameCatagory instances that have a changed LastChange timestamp. For Publisher configuration related information see D.1.3.

The DataSetClassId defined in OPC 10000-14 shall be used by all applications supporting this optional extension. Subscribers will create a subscription to the provided multicast address for the DataSetClassId. Subscribers can filter on the PublisherId to further restrict records to those from a subset of Servers publishing on the same multicast address.

A Subscriber when it is subscribed to the multicast address receives three types of messages, a data key frame message, a data delta frame message and a keep alive message. The following illustrates the process a Subscriber could follow including what each of the message types provides:

For a keep alive message, the following process could be followed: A keep alive message has no payload, it only has the network header, including a PublisherId. This message only indicates that the Publisher is still alive and publishing data. The Subscriber can update the status of the Server that is related to the PublisherId, indicating that it is still alive.

For a data key frame message, the following process could be followed: The Subscriber would have to compare the LastChange value for the first entry in the array to the time stored for the Server with the matching ApplicationUri for the Aliases AliasNameCategory. The first index in the array is always the Aliases AliasNameCategory. If this value is different, then some of the AliasNameCatagories had changes. The Subscriber would then iterate through the entire array of AliasNameCategoryUpdateDataType records and for any that have a LastChange value that does not match the cached value, the AliasNameCaregoryId is added to the list for processing. The following steps describe the processing:

First the Subscriber looks up the ApplicationId and connects to the appropriate Server (if it does not already have a connection).

For the AliasNameCategory NodeId(s) in the list:

The Subscriber would issue a Browse for the provided NodeIds of the AliasNameCategories. Note: The Browse could contain all NodeIds in the list.

The Subscriber compares the browse results, to the list it has from the Server. There could be new AliasNameCategories, new AliasName Nodes, there could also be deleted AliasName Nodes or AliasNameCategories. For new AliasName Nodes, a Browse of the AliasName node would be required. Any updates would be stored.

For a data delta frame message the following process could be followed: The Subscriber would add all of the AliasNameCategories that are returned in the message (only AliasNameCategories that have change would be returned) to a list for processing. Once the list of NodeId is obtained then the same processing as listed above for data key frame message would occur.

The aggregating Server or GDS can remove all AliasName Nodes and AliasNameCategories associated with a Server if no messages of any form are received from a Server for some configurable period of time.

It is important that an aggregating Server or GDS does not rely only on data delta frames, PubSub is not a guaranteed delivery system, so a data delta frame message could be missed, but data key frames would indicate the changes.

The published messages could also be used by an aggregating Server or GDS to detect a new Server that came on-line. If a published message includes an ApplicationUri that the Server did not have, it would indicate the message is from a new Server. The new Server could be added to the aggregating Server or GDS.

Note: it is important to understand that multicast address might require network setup, depending on the configuration of the network and type of switches/bridges use (see OPC 10000-14).

D.1.3 PubSub AliasName Notification Configuration

The setting for a PubSub AliasName Publisher are fixed as defined in D.2. Only the following items can be changed as part of configuring the Publisher.

See OPC 10000-14 for additional details on data key frames, data delta frame,PublishingIntervals and security settings.

PublishingInterval that is defined for the published messages.

The KeyFrameCount that is defined for the published messages. It is the multiplier of the PublishingInterval that defines the maximum number of times the PublishingInterval expires before a data key frame message is sent.

The KeepAliveTime that is defined for the published messages. It is the rate at which an empty message is sent, if no data messages are published.

The SecurityMode that is associated with the published messages. It is the type of security (None, Sign, SignAndEncrypt) assigned to the messages.

The SecurityGroupId that is associated with the published messages. It is the unique identifier for a SecurityGroup within an SKS.

The SecurityKeyServices that is associated with the published messages.

The Address that is associated with the published messages. It defines a multi-cast address to which all publish messages shall be directed. This can be configured to allow subsets of Servers to direct the notification message to a specific GDS or aggregating Server.

The Enabled that is associated with the PubSubConnection for the published messages. This flag can be used to enable the Servers AliasName PubSub Notifications feature.

A Server that supports this feature would typically have this feature pre-configured, allowing notification to begin on startup of the Server.

D.2 DataTypes for AliasName DataSetClass

D.2.1 AliasCategoryUpdateDataType

This structure is used to indicate that an AliasName category has an updated AliasName(s). Its elements are defined in Table D.1.

Its representation in the AddressSpace is defined in Table D.2 .

D.2.2 AliasUpdateDataType

This structure is used to define a DataSet. This DataSet is used to indicate a Server has had changes to one or more AliasNameCategories, where an AliasName was added or deleted. Its fields are defined in Table D.3.

Its representation in the AddressSpace is defined in Table D.4.

D.3 Alias Update Header Layout

D.3.1 Overview

This layout is specially configured for AliasName update messages. For additional detail on PubSub and header layouts see OPC 10000-14.

D.3.2 Header layout for NetworkMessages

A UADP NetworkMessage header shall consist of the following fields according to this header layout:

Version / Flags

ExtendedFlags1

PublisherId

DataSetClassId

Additional restrictions:

The datatype for the PublisherId shall be UInt64

The NetworkMessage header layout is shown in Figure D.2.

Table D.5 shows the configuration for the NetworkMessage header.

D.3.3 Header layout for NetworkMessages with integrity (signing)

UADP messages may be signed to ensure integrity. In this case a security header and a signature have to be added to the message.

This header layout is basically the same as the header layout defined in D.3.2 but with additional security level ‘Signing but no encryption’. The NetworkMessage header layout with signing is shown in Figure D.3

Table D.6 shows the configuration for the NetworkMessage header with signing. The table contains only the added or modified rows from Table D.5.

D.3.4 Header layout for DataSetMessages

A UADP DataSetMessage header shall consist of the following fields according to this header layout:

DataSetFlags1

DataSetFlags2

Additional remarks:

Field is encoded as a Variant

The following types of DataSetMessages (Data Key Frame, Data Delta Frame, Keep Alive, etc.) are supported

The DataSetMessage header layout is shown in Figure D.4.

Table D.7 shows the configuration for the DataSetMessage header.

For a description of Data KeyFrame, Data Delta Frames and Keep Alive see OPC 10000-14.

Bibliography

Agreement of Use

COPYRIGHT RESTRICTIONS

Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner.

OPC Foundation members and non-members are prohibited from copying and redistributing+ this specification. All copies must be obtained on an individual basis, directly from the OPC Foundation Web site: http://www.opcfoundation.org.

PATENTS

The attention of adopters is directed to the possibility that compliance with or adoption of OPC specifications may require use of an invention covered by patent rights. OPC shall not be responsible for identifying patents for which a license may be required by any OPC specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OPC specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents.

WARRANTY AND LIABILITY DISCLAIMERS

WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OPC FOUDATION MAKES NO WARRANTY OF ANY KIND, EXPRESSED OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OPC FOUNDATION BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The entire risk as to the quality and performance of software developed using this specification is borne by you.

RESTRICTED RIGHTS LEGEND

This Specification is provided with Restricted Rights. Use, duplication or disclosure by the U.S. government is subject to restrictions as set forth in (a) this Agreement pursuant to DFARs 227.7202-3(a); (b) subparagraph (c)(1)(i) of the Rights in Technical Data and Computer Software clause at DFARs 252.227-7013; or (c) the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 subdivision (c)(1) and (2), as applicable. Contractor / manufacturer are the OPC Foundation, 16101 N. 82nd Street, Suite 3B, Scottsdale, AZ, 85260-1830.

COMPLIANCE

The OPC Foundation shall at all times be the sole entity that may authorize developers, suppliers and sellers of hardware and software to use certification marks, trademarks or other special designations to indicate compliance with these materials. Products developed using this specification may claim compliance or conformance with this specification if and only if the software satisfactorily meets the certification requirements set by the OPC Foundation. Products that do not meet these requirements may claim only that the product was based on this specification and must not claim compliance or conformance with this specification.

Trademarks

Most computer and software brand names have trademarks or registered trademarks. The individual trademarks have not been listed here.

GENERAL PROVISIONS

Should any provision of this Agreement be held to be void, invalid, unenforceable or illegal by a court, the validity and enforceability of the other provisions shall not be affected thereby.

This Agreement shall be governed by and construed under the laws of the State of Minnesota, excluding its choice or law rules.

This Agreement embodies the entire understanding between the parties with respect to, and supersedes any prior understanding or agreement (oral or written) relating to, this specification.

ISSUE REPORTING

The OPC Foundation strives to maintain the highest quality standards for its published specifications; hence they undergo constant review and refinement. Readers are encouraged to report any issues and view any existing errata here: http://www.opcfoundation.org/errata

Revision 1.05.07 Highlights

The following table includes the Mantis issues resolved with this revision.