1.

1 Alarm and Event

1.1.1 Overview
Figure 1 below is a overview of the Alarm & Event Functional Subsystem.

Figure 1 Alarm & Event Static Overview

External Alarm
The External Alarm service subscribes to alarm lists and set output
signals if there are alarms in the corresponding lists.
Alarm Logger
The alarm logger subscribes to alarm lists and prints the events to an
associated printer.
Alarm Manager
The Alarm Manager handles all alarms for the system and all events are
handled by the server. The Alarm Manager run on aspect servers.
Event Storage
The Event Storage handles persistent storage of all type of events.
Storage size can be configured on category basis in the Event Storage
Service Definition aspect (on the Special Configuration tab). The event
storage server runs on aspect servers, and maximum two providers are
allowed.
Event Collector
The Event Collector collects events from a OPC AE server that it has
been configured to collect from. Event Collector is distributed to run where
the OPC AE server run, and can run on both aspect and connectivity
servers.
System Message
The System Message server handles system messages as well as audit
events. System Alarms can also be generated for important events. The
system message server only persist events until successfully stored in the
Event Storage.
Soft Alarm
The Soft Alarm server handles Alarm Expressions and also handles
alarms set by client applications such as the System Status Server and
the Asset Optimization services.
Figure 2 below shows the processes for Alarm & Event.

Figure 2 Alarm & Event Processes

1.1.2 Alarm/Event Dynamics Overview
Figure 3 below shows the dynamics for the generation of an alarm/event.

Figure 3 Alarm/Event Dynamics Overview

The following is happening after an object disturbance in a controller:

1. Disturbance on object in controller, the Alarm & Event OPC Server for
the connectivity gets notified.
2. The Event Collector Server gets an alarm/event notification. The
alarm/event is queued if needed.
3. The alarm/event is sent further to the Alarm Manager Server.
4. The alarm/event is propagated to all alarm/event lists and all 3rd party
clients.
5. The event is stored into the Event Storage (if Alarm Manager is
configured to store the specific type of event).
1.1.2.1 AC800 Alarm/Event Dynamics
Figure 4 below shows the Alarm/Event dynamics for the AC800
Connectivity.

Figure 4 AC800 Alarm/Event Dynamics

The following is happening when an Alarm/Event is generated in the

Controller:
1. A Condition State Change is sent from the IEC61131 Program to the
Alarm Condition Handler (the program has been compiled and
downloaded by the Control Builder application).
2. An Update of the Alarm Condition List (i.e. a list of all defined Alarm
Conditions) is performed.
3. The program is updated with the new condition.
4. The event notification is queued in the Intermediate Queue. This
queue holds event notifications for all Collectors communicating with
the Controller.
5. The event notification is queued in the EventEnrollmentQueue which
holds all event notifications for the actual Collector.
6. The event notification is queued for sending on the MMS-bus.
 7. The Alarm & Event OPC Server receives the event notification.
Embedded in this OPC Server is the system module Alarm and Event
Gateway, which acts as a client.

1.1.2.2 Alarm Acknowledge Dynamics Overview

Figure 5 below shows the dynamics of the acknowledge of an alarm.

Figure 5 Alarm Acknowledge Dynamics

The following is happening when the Operator acknowledges an alarm:

1–4 An alarm acknowledge is propagated from the Alarm List to the
Controller.
5–9 An alarm acknowledge confirmation is propagated from the
Controller to the Alarm List (view is updated) and to all 3rd party
clients.
10 The acknowledge event is stored to the Event Storage, but only if
the Alarm Manager Server is configured to log acknowledge
events.
1.1.2.3 Alarm Logger Dynamics Overview
Figure 6 below shows the dynamics for logging an alarm/event to a
connected printer through Alarm Logger functionality.

Figure 6 Alarm/Event Dynamics Overview

The following is happening after an object disturbance in a controller:

1. The Alarm & Event OPC Server for the connectivity sends an
alarm/event notification to the PPA Event Collector Server.
2. The Event Collector Server sends the alarm/event further to the Alarm
Manager Server.
3. The Alarm Logger service will set up a subscription for alarm/events
(the configuration to use is given on the Alarm Logger Service Group
object) when it starts. If the alarm/event matches the filter for the
subscription the alarm/event will be sent to the Alarm Logger service.
4. The Alarm Logger service will print out the alarm/event on the printer
that is configured on the Alarm Logger provider object.
1.1.2.4 Alarm Expressions Dynamic Overview
Figure 7 below shows the dynamics for how Alarm Expressions are used
in PPA. When the Soft Alarms service is started it will go through all
defined Alarm Expression aspects and activate subscriptions for the
properties used in the Alarm Expressions. One Event Collector service
group is connected to the Soft Alarms service and the soft alarms service
will act as an OPC AE server to this Event Collector service.

Figure 7 Alarm Expressions overview

The following happens when a property that is used in an Alarm

Expression is changed:
1. OPC DA will send a notification with the new value of the changed
property,
2. The Property Expression manager will compute the Alarm Expression
statement to see if it changes its state. If the Alarm Expression either
becomes active or inactive a notification is sent to the Soft Alarms
server.
3. The Soft Alarms server will update the current state for the alarm
condition and send the state change to the Alarm Manager server via
the connected Event Collector server.
4. The Alarm Manager server will update the current alarm state and
send the new state to all its clients, i.e. Alarm List.
1.1.2.5 External Alarm Dynamics Overview
Figure 8 below shows the dynamics for the External Alarm functionality.

Figure 8 External Alarm Dynamics Overview

The following is happening when an External Alarm is set:

1. An active unacknowledged alarm or an alarm acknowledge is received
as described in other chapters.
2. The alarm/acknowledge is propagated to an Alarm List.
3. The External Alarm Configuration, which is configured to get
alarms/events as filtered by the Alarm List, also receives the
alarm/acknowledge.
4. The External Alarm destination (OPC DA Boolean property) is set to
TRUE(1) if an active unacknowledged alarm was received, and
FALSE(0) if an alarm acknowledge was received and all alarms in the
list are acknowledged (if the External Alarm Configuration is set to
Auto Silence).

The following is happening when silencing an External Alarm:

s1. The operator silences the External Alarm from the External Alarm
Silence aspect (which lists all External Alarm Configurations who’s Alarm
Lists the operator is allowed to acknowledge), resulting in that the
External Alarm Silence aspect sends a Silence request to the External
Alarm Server.
 s2. The External Alarm Server sends a Silence request to the
corresponding External Alarm Configuration aspect (which is kept alive in
the server process).
s3. The External Alarm destination (OPC DA Boolean property) is set to
FALSE (0).

1.1.2.6 System Message Dynamics

Figure 9 below shows the dynamics for submitting and fetching system
messages.

Figure 9 System Message Dynamics

The following happens when a system message is submitted:

1. A message is submitted to the system message server. This can be a
system message or an an audit trail message.
2. The server treats the incoming message and generates a
corresponding simple OPC event. If the message is configured to
 generate an alarm a condition event is generated as well for the
System Alarm category. The system message server keeps the
message in a persisted cache until its reception has been
acknowledged.
3. The event collector forwards the event notification to the Alarm
Manager. If the operation was successful an acknowledge that it has
received and handled the event is sent back to the System Message
server
4. The Alarm Manager sends the event to the Event Storage for storage
of the event.
5. The Alarm Manager sends the event to subscribing clients. That is the
Event List and other clients subscribing for simple events. In case a
system alarm was generated for the message the alarm will be sent to
subscribing alarm lists and alarm bands as well.

1.1.3 Alarm & Event redundancy

Both Event Collector (EC), Alarm Manager (AM) and Soft Alarms (SA) are
redundant services. Redundancy is achieved by creating a service group
in the service structure and then creating two or more service provider
objects in that group. The service providers should run on different nodes.
When a client is connected to a service group containing at least two ser-
vice providers (servers) the CSlib takes care of switching the clients
between the servers if one server stops working. This is done on the fly,
without any restart of the clients.
The Alarm Manager uses Service-Service scenario (all providers in a
group are in service state Service) thus enabling e.g. load balancing. The
AM service runs on Aspect Servers.
Soft Alarms uses Service-Service scenario like the Alarm Manager. The
SA service runs on Aspect Servers.
The Event Collector uses Service-Standby scenario (only one provider in
a group is service state Service and the others are in Standby. This is
chosen for EC to eliminate the need for synchronization among them) in
the normal case, but there are exceptions, such as Batch where the OPC
servers uses return codes to the Event Collector making the EC service
group for Batch using Service-Synchronizing scenario. The EC service
normally runs on Connectivity Servers, but the EC providers dedicated to
Soft Alarms are programmatically created to run on the same Aspect
Server as corresponding Soft Alarms provider in order to reduce network
traffic.
System Message Server service is also redundant and uses a Service-
Standby schema, and runs on all aspect servers.
Event Storage is redundant and runs a service-service schema. In this
version two redundant Event Storage services are supported. That means
that the service group for Event Storage Service should not contain more
than two providers. The providers should be configured to run on Aspect
Servers.