Condition Event instance records are stored locally within the A&E COM UA Proxy. Each record holds ONEVENTSTRUCT data for each EventSource/Condition instance. When the Condition instance transitions to the state INACTIVE|ACKED, where AckRequired = True or simply INACTIVE, where AckRequired = False, the local Condition record is deleted. When a Condition Event is received from the UA A & C Server and a record for this Event (identified by source/Condition pair) already exists in the proxy Condition Event store, the existing record is simply updated to reflect the new state or other change to the Condition, setting the change mask accordingly and producing an OnEvent callback to any subscribing Clients. In the case where the Client application acknowledges an Event which is currently unacknowledged (AckRequired = True), the UA A & C Server Acknowledge Method associated with the Condition is called and the subsequent Event produced by the UA A & C Server indicating the transition to acknowledged will result in an update to the current state of the local Condition record as well as an OnEvent Notification to any subscribing Clients.

The A&E COM UA Proxy maintains the mapping of Attributes on an Event category basis. An Event category inherits its Attributes from the Properties defined on all supertypes in the UA Event Type hierarchy. New Attributes are added for any Properties defined on the direct UA Event type to A&E category mapping. The A&E COM UA Proxy adds two Attributes to each category: AckComment and Areas. Figure D.4 shows an example of this mapping.

Figure D.4 – Example mapping of UA Event Types to A&E categories with attributes

Events of any subtype of ConditionType are designated COM Condition Events and are subject to additional processing due to the stateful nature of Condition Events. COM Condition Events transition between states composed of the triplet ENABLED|ACTIVE|ACKNOWLEDGED. In UA A & C, Event subtypes of ConditionType only carry a value which can be mapped to ENABLED (DISABLED) and optionally, depending on further sub typing, may carry additional information which can be mapped to ACTIVE (INACTIVE) or ACKNOWLEDGED (UNACKNOWLEDGED). Condition Event processing proceeds as described in Table D.5 (see A&E ONEVENTSTRUCT “Attribute” rows: OPC_CONDITION_ACTIVE, OPC_CONDITION_ENABLED and OPC_CONDITION_ACKED).

A&E COM browsing yields a hierarchy of areas and sources. Areas can contain both sources and other areas in tree fashion where areas are the branches and sources are the leaves. The A&E COM UA Proxy relies on the "HasNotifier" Reference to assemble a hierarchy of branches/areas such that each Object Node which contains a HasNotifier Reference and whose EventNotifier Attribute is set to SubscribeToEvents is considered an area. The root for the HasNotifier hierarchy is the Server Object. Starting at the Server Object, HasNotifier References are followed and each HasNotifier target whose EventNotifier Attribute is set to SubscribeToEvents becomes a nested COM area within the hierarchy.

Note that the HasNotifier target can also be a HasNotifier source. Further, any Node which is a HasEventSource source and whose EventNotifier Attribute is set to SubscribeToEvents is also considered a COM Area. The target Node of any HasEventSource Reference is considered an A&E COM “source” or leaf in the A&E COM browse tree.

In general, Nodes which are the source Nodes of the HasEventSource Reference and/or are the source Nodes of the HasNotifier Reference are always A&ECOM Areas. Nodes which are the target Nodes of the HasEventSource Reference are always A&E COM Sources. Note however that targets of HasEventSource which cannot be found by following the HasNotifier References from the Server Object are ignored.

Given the above logic, the A&E COM UA Proxy browsing will have the following limitations: Only those Nodes in the UA A & C Server’s address space which are connected by the HasNotifier Reference (with exception of those contained within the top level Objects folder) are considered for area designation. Only those Nodes in the UA A & C Server’s address space which are connected by the HasEventSource Reference (with exception of those contained within the top level Objects folder) are considered for area or source designation. To be an area, a Node shall contain a HasNotifier Reference and its EventNotifier Attribute shall be set to SubscribeToEvents. To be a source, a Node shall be the target Node of a HasEventSource Reference and shall have been found by following HasNotifier References from the Server Object.

From the root of any sub tree in the address space of the UA A & C Server, the A&E COM Client may request the list of areas and/or sources contained within that level. The resultant list of area names or source names will consist of the set of browse names belonging to those Nodes which meet the criteria for area or source designation as described above. These names are "short" names meaning that they are not fully qualified. The A&E COM Client may request the fully qualified representation of any of the short area or source names. In the case of sources, the fully qualified source name returned to the A&E COM Client will be the string encoded value of the NodeId as defined in 10000-6 (e.g., “ns=10;i=859“). In the case of areas, the fully qualified area name returned to the COM Client will be the relative path to the notifier Node as defined in 10000-4 (e.g., “/6:Boiler1/6:Pipe100X/1:Input/2:Measurement“). Relative path indices refer to the namespace table described below.

UA Server Namespace table indices may vary over time. This represents a problem for those A&E COM Clients which cache and reuse fully qualified area names. One solution to this problem would be to use a qualified name syntax which includes the complete URIs for all referenced table indices. This however would result in fully qualified area names which are unwieldy and impractical for use by A&E COM Clients. As an alternative, the A&E COM UA Proxy will maintain an internal copy of the UA A & C Server's namespace table together with the locally cached endpoint description. The A&E COM UA Proxy will evaluate the UA A & C Server’s namespace table at connect time against the cached copy and automatically handle any re-mapping of indices if required. The A&E COM Client can continue to present cached fully qualified area names for filter purposes and the A&E COM UA Proxy will ensure these names continue to reference the same notifier Node even if the Server's namespace table changes over time.

To implement the relative path, the A&E COM UA Proxy maintains a stack of INode interfaces of all the Nodes browsed leading to the current level. When the A&E COM Client calls GetQualifiedAreaName, the A&E COM UA Proxy first validates that the area name provided is a valid area at the current level. Then looping through the stack, the A&E COM UA Proxy builds the relative path. Using the browse name of each Node, the A&E COM UA Proxy constructs the translated name as follows:

QualifiedName translatedName = new QualifiedName(Name,(ushort) ServerMappingTable[NamespaceIndex]) where

Name – the unqualified browse name of the Node

NamespaceIndex – the Server index

the ServerMappingTable provides the Client namespace index that corresponds to the Server index.

A ‘/’ is appended to the translated name and the A&E COM UA Proxy continues to loop through the stack until the relative path is fully constructed.

The A&E COM UA Proxy supports all of the defined A&E COM filter criteria.

These filter types are implemented using simple numeric comparisons. For Event filters, the received Event shall match the Event type(s) specified by the filter. For Category filters, the received Event’s category (as mapped from UA Event type) shall match the category or categories specified by the filter. For severity filters, the received Event severity shall be within the range specified by the Subscription filter.

In the case of source filters, the UA A & C Server is free to provide any appropriate, Server-specific value for SourceName. There is no expectation that source Nodes discovered via browsing can be matched to the SourceName Property of the Event returned by the UA A & C Server using string comparisons. Further, the A&E COM Client may receive Events from sources which are not discoverable by following only HasNotifier and/or HasEventSource References. Thus, source filters will only apply if the source string can be matched to the SourceName Property of an Event as received from the target UA A & C Server. Source filter logic will use the pattern matching rules documented in the A&E COM specification, including the use of wildcard characters.

The A&E COM UA Proxy implements Area filtering by adjusting the set of MonitoredItems associated with a Subscription. In the simple case where the Client selects no area filter, the A&E COM UA Proxy will create a UA Subscription which contains just one MonitoredItem, the Server Object. In doing so, the A&E COM UA Proxy will receive Events from the entire Server address space – that is, all Areas. The A&E COM Client will discover the areas associated with the UA Server address space by browsing. The A&E COM Client will use GetQualifiedAreaName as usual in order to obtain area strings which can be used as filters. When the A&E COM Client applies one or more of these area strings to the COM Subscription filter, the A&E COM UA Proxy will create MonitoredItems for each notifier Node identified by the area string(s). Recall that the fully qualified area name is in fact the namespace qualified relative path to the associated notifier Node.

The A&E COM UA Proxy calls the TranslateBrowsePathsToNodeIds Service to get the Node ids of the fully qualified area names in the filter. The Node ids are then added as MonitoredItems to the UA Subscription maintained by the A&E COM UA Proxy. The A&E COM UA Proxy also maintains a reference count for each of the areas added, to handle the case of multiple A&E COM Subscription applying the same area filter. When the A&E COM Subscriptions are removed or when the area name is removed from the filter, the ref count on the MonitoredItem corresponding to the area name is decremented. When the ref count goes to zero, the MonitoredItem is removed from the UA Subscription.

As with source filter strings, area filter strings can contain wildcard characters. Area filter strings which contain wildcard characters require more processing by the A&E COM UA Proxy. When the A&E COM Client specifies an area filter string containing wildcard characters, the A&E COM UA Proxy will scan the relative path for path elements that are completely specified. The partial path containing just those segments which are fully specified represents the root of the notifier sub tree of interest. From this sub tree root Node, the A&E COM UA Proxy will collect the list of notifier Nodes below this point. The relative path associated with each of the collected notifier Nodes in the sub tree will be matched against the Client supplied relative path containing the wildcard character. A MonitoredItem is created for each notifier Node in the sub tree whose relative path matches that of the supplied relative path using established pattern matching rules. An area filter string which contains wildcard characters may result in multiple MonitoredItems added to the UA Subscription. By contrast, an area filter string made up of fully specified path segments and no wildcard characters will result in one MonitoredItem added to the UA Subscription. So, the steps involved are:

1. Check if the filter string contains any of these wild card characters, '*', '?', '#', '[', ']', '!', '-'.
2. Scan the string for path elements that are completely specified by retrieving the substring up to the last occurrence of the ‘/’ character.
3. Obtain the Node Id for this path using TranslateBrowsePathsToNodeIds
4. Browse the Node for all notifiers below it.
5. Using the ComUtils.Match() function match the browse names of these notifiers against the Client supplied string containing the wild card character.
6. Add the Node ids of the notifiers that match as MonitoredItems to the UA Subscription.