Filtering on Event Transitions|OPC UA Standard|Forum|OPC Foundation

We in Kongsberg Maritime has om question about OPC UA Alarms and Events i.e. Part 9 and Part 4. Not sure if you are the right destination for these questions but expect that you can find someone that can give us some advice.

As you might know we are using OPC UA as a front end in our new Server implementation. We are struggling with the functionality of the OPC UA Alarms and Condition functionality. Currently we send to much information to our clients and perform extra filtering on the client side. The event management on the clients then becomes a bottleneck.

Our intention:

We would like to use the server side OPC UA Event filter to create an Event stream for the Clients. The Client should then just show the stream of events provided by the server and spend less processing time creating an Alam/Event list.

Of cause a Condition Refresh on a client shall give the same content in the alarm as the other clients with the same filter living on the live stream.   

Part 9 OPC UA Alarms and Condition example B.1.4:

B.1.4 Server current-State Model with Suppression

This example adds additional fields to the model illustrated in B.1.2. This example does not use acknowledge or confirm – it assumes that the alarm is automatically acknowledged (and does not support confirm). It does add OutOfServiceState and SuppressedState.

Figure B.3 shows an Alarm as it becomes active, is suppressed or is placed out of service and then inactive. Table B.1 lists the values of the state Variables. All Events are coming from the same Condition instance and therefore have the same ConditionId. The Client subscription includes an event filter that excludes suppressed or out of service conditions (i.e. SuppressedState = True or OutOfServiceState = True). The events shown in green are delivered to the Client.

Figure B.3 – SuppressedState and OutOfServiceState example

Table B.3 – Example of a Condition that is Suppressed / OutOfService

We think that the information in the filter will not produce this table and the if a Condition Refresh is applied at different times the Event list will not be equal to the one that just uses the live stream.

The first challenge is Event ID 2, since the filter act on OutOfService this event will never be sent. To solve this, we need to consider the Event transitions.

How shall Event Transitions be solved?:

Since most of the states are modeled as TwoStateVariableType there is no Transition information available.

Should the Time stamp of the State be compared with the Time stamp of the Event record (from the BaseEventType defined in part 5).

EventID 2 might be fund using this filter:

(OutOfServiceState=True) OR (OutOfServiceState/TransitionsTime = Time)

Is this the intended way of finding transitions or is the intention to include Transitions Information for each State in the Event record also for the variables modeled with TwoStateVariableType?

Lot of information to come to a simple question, but we would like to know the idea behind before we make any decisions.

We think that example B 1.4 need to be corrected to show the intended strategy here.