Hi,

Good Questions.

However this time I will only give a short answer now. Later me (or someone else) will probably give better one.

Alarms are a subtype of Conditions. Conditions are subtype of Events.

Basic Events do not have a “state” so to say. Conditions and Alarms have states (enabled, acknowledged etc.).

Subtypes of ConditionType are Conditions. Subtypes of AlarmConditionType are “Alarms”. Usually there are not that many Conditions that are not also Alarms, but there is e.g. a DialogConditionType that is not a subtype of the AlarmConditionType and such is not an Alarm, only a Condition. All other types are “basic events”, unless something says otherwise.

Condition state is represented by a node in the address space, for basic events there are no nodes (but you can think of a virtual node right at the moment when it is sent).

All events are is a snapshot of a Node’s sub-structure with the selected fields (and the node must be of course an Event type node). Thus state is also in node values.

So:

1) Yes, since MonitoredEventItem monitors events and all data given by those is events

2) The only thing an Alarm is technically is a series of Events via MonitoredItems + Method Calls from the client to modify the state

3) e.g. the DialogConditionType, not sure if they have been used in practice…

4) The event filter is very complicated and very versatile. However the data is always only the EventType in question with it’s sub-structure. But nothing prevents you from modeling such types that would have a sub-node-structures that have nodes with NodeId DataType and thus Value.

For demo see the SampleConsoleServer, other than that, no.

Also you might need to read the actual specification in order to understand the whole picture, as this is like ~500 pages of information (Part 3,4,5,9).