Condition Eventinstance records are stored locally within the A&E COM UA Proxy. Each record holds ONEVENTSTRUCT data for each EventSource/Conditioninstance. When the Conditioninstance transitions to the state INACTIVE|ACKED, where AckRequired = True or simply INACTIVE, where AckRequired = False, the local Conditionrecord is deleted. When a Condition Eventis received from the UA A & C Serverand a record for this Event(identified by source/Conditionpair) already exists in the proxy Condition Eventstore, 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 Clientapplication acknowledges an Eventwhich is currently unacknowledged (AckRequired = True), the UA A & C ServerAcknowledge Methodassociated with the Conditionis called and the subsequent Eventproduced by the UA A & C Serverindicating the transition to acknowledged will result in an update to the current state of the local Conditionrecord as well as an OnEvent Notificationto any subscribing Clients.

The A&E COM UA Proxy maintains the mapping of Attributes on an Eventcategory basis. An Eventcategory inherits its Attributes from the Propertiesdefined on all supertypes in the UA EventType hierarchy. New Attributes are added for any Propertiesdefined on the direct UA Eventtype to A&E category mapping. The A&E COM UA Proxy adds two Attributes to each category: AckComment and Areas. Figure D.4shows 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 ConditionTypeare 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, Eventsubtypes of ConditionTypeonly 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 Eventprocessing 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" Referenceto assemble a hierarchy of branches/areas such that each Object Nodewhich contains a HasNotifier Referenceand whose EventNotifier Attributeis set to SubscribeToEventsis considered an area. The root for the HasNotifierhierarchy is the Server Object. Starting at the Server Object, HasNotifier References are followed and each HasNotifiertarget whose EventNotifier Attributeis set to SubscribeToEvents becomes a nested COM area within the hierarchy.

Note that the HasNotifier target can also be a HasNotifier source. Further, any Nodewhich is a HasEventSource source and whose EventNotifier Attributeis set to SubscribeToEvents is also considered a COM Area. The target Nodeof any HasEventSource Referenceis 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 Referenceand/or are the source Nodes of the HasNotifier Referenceare always A&ECOM Areas. Nodes which are the target Nodes of the HasEventSource Referenceare always A&E COM Sources. Note however that targets of HasEventSource which cannot be found by following the HasNotifier References from the Server Objectare 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 Nodeshall contain a HasNotifier Referenceand its EventNotifier Attributeshall be set to SubscribeToEvents. To be a source, a Nodeshall be the target Nodeof a HasEventSource Referenceand 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 Clientmay 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 Clientmay 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 Clientwill be the string encoded value of the NodeIdas defined in 10000-6(e.g., “ns=10;i=859“). In the case of areas, the fully qualified area name returned to the COM Clientwill be the relative path to the notifier Nodeas 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 ServerNamespace 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 Clientcan 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 Nodeeven if the Server's namespace table changes over time.

To implement the relative path, the A&E COM UA Proxy maintains a stack of INodeinterfaces of all the Nodes browsed leading to the current level. When the A&E COM Clientcalls 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 Serverindex

the ServerMappingTableprovides the Clientnamespace index that corresponds to the Serverindex.

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 Eventfilters, the received Eventshall match the Eventtype(s) specified by the filter. For Category filters, the received Event’s category (as mapped from UA Eventtype) shall match the category or categories specified by the filter. For severity filters, the received Eventseverity shall be within the range specified by the Subscriptionfilter.

In the case of source filters, the UA A & C Serveris 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 Propertyof the Eventreturned by the UA A & C Server using string comparisons. Further, the A&E COM Clientmay 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 Propertyof an Eventas 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 Clientselects no area filter, the A&E COM UA Proxy will create a UA Subscriptionwhich contains just one MonitoredItem, the Server Object. In doing so, the A&E COM UA Proxy will receive Events from the entire Serveraddress space – that is, all Areas. The A&E COM Clientwill discover the areas associated with the UA Serveraddress space by browsing. The A&E COM Clientwill use GetQualifiedAreaName as usual in order to obtain area strings which can be used as filters. When the A&E COM Clientapplies one or more of these area strings to the COM Subscriptionfilter, the A&E COM UA Proxy will create MonitoredItems for each notifier Nodeidentified 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 Serviceto get the Nodeids of the fully qualified area names in the filter. The Nodeids are then added as MonitoredItems to the UA Subscriptionmaintained 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 Subscriptionapplying 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 MonitoredItemcorresponding to the area name is decremented. When the ref count goes to zero, the MonitoredItemis 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 Clientspecifies 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 Clientsupplied relative path containing the wildcard character. A MonitoredItemis created for each notifier Nodein 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 MonitoredItemadded 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 NodeId for this path using TranslateBrowsePathsToNodeIds
4. Browse the Nodefor all notifiers below it.
5. Using the ComUtils.Match() function match the browse names of these notifiers against the Clientsupplied string containing the wild card character.
6. Add the Nodeids of the notifiers that match as MonitoredItems to the UA Subscription.