Events, alarms and conditions

Unlike a value change, an event reports that something happened: an equipment fault, a limit violation, an operator action. Part 3 and Part 5 define the event model; Part 9 defines Alarms and Conditions.

Events

Every event type derives from BaseEventType (i=2041). Its main fields:

Field	Description
EventId	A unique byte string the server creates for each event
EventType	NodeId of the event type
SourceNode, SourceName	The node where the event happened and its name
Time	When the event happened
Message	A human-readable description
Severity	Severity from 1 to 1000; higher is more severe

Events aren’t stored in nodes. You receive them by subscribing to an event notifier: an object whose EventNotifier attribute has the SubscribeToEvents bit set. The Server object (i=2253) is the top-level notifier for events from the whole server.

Event subscriptions and EventFilter

You receive events by adding a monitored item to a subscription. The item watches the notifier’s EventNotifier attribute (AttributeId 12) and uses an EventFilter:

• Select clauses list the fields to put in each notification. Each field names a type definition and a browse path; AckedState/Id, for example, is the Id property of the AckedState variable.
• The where clause filters which events you receive. Leave it empty to receive all events.

Field values arrive in an EventFieldList, in the order of the select clauses.

Alarms and conditions

A condition is an event source with state. Each state change produces a new event with a new EventId. The type hierarchy:

BaseEventType (i=2041)
└── ConditionType (i=2782)                    EnabledState, Retain, Comment
    └── AcknowledgeableConditionType (i=2881)  AckedState, ConfirmedState
        └── AlarmConditionType (i=2915)        ActiveState
            └── ... OffNormalAlarmType (i=10637)

State	Meaning
EnabledState	Whether the condition is in service. A disabled condition sends no events.
ActiveState	Whether the alarm condition currently holds
AckedState	Whether an operator acknowledged the alarm
ConfirmedState	Whether the corrective action was confirmed
Retain	Whether clients should keep showing the condition

You call condition methods with Call, passing the condition node as the object and a standard method NodeId as the method:

Method	NodeId	Input arguments
Acknowledge	i=9111	EventId of the event to acknowledge, a comment (LocalizedText)
Confirm	i=9113	EventId of the event to confirm, a comment
AddComment	i=9029	EventId, a comment
Enable, Disable	i=9027, i=9028	None
ConditionRefresh	i=3875	SubscriptionId; called on ConditionType (i=2782) as the object

Acknowledge and Confirm refer to a specific event, so pass the EventId of the latest state. An unknown EventId gives BadEventIdUnknown; acknowledging a state that is already acknowledged gives BadConditionBranchAlreadyAcked.

Refreshing conditions

A client that has just created a subscription doesn’t know about alarms that are already active. When it calls ConditionRefresh, the server sends a RefreshStartEvent (i=2787), the current state of every condition with Retain set, and a RefreshEndEvent (i=2788) on that subscription.

Alarms in the PDComm simulator

The simulator’s server has one alarm condition:

Item	Value
Condition node	ns=2;s=Simulator.Alarm (OffNormalAlarmType)
Source variable	ns=2;s=Simulator.AlarmSource (Boolean); the alarm becomes active when it turns true.
Notifier	The Server object (i=2253)
Severity	700 while active, 100 when cleared

One alarm goes through these states. The values come from events the simulator actually sent:

Occurrence	ActiveState	AckedState	ConfirmedState	Retain
Alarm activated	true	false	true	true
Acknowledge	true	true	false	true
Confirm	true	true	true	true
Alarm cleared	false	true	true	false

The simulator’s event_subscribe action selects the EventId, EventType, SourceNode, SourceName, Time, Message, Severity, ConditionId, Retain, ActiveState/Id, AckedState/Id and ConfirmedState/Id fields. Try it in the events and alarms tutorial.

The PDComm SDK client passes event subscriptions and condition method calls through unchanged; the SDK in-memory server has no events or conditions.

Next steps

Historical access explains how to read past values.