When an alarm is raised in ClearSCADA, the Main ClearSCADA server allocates a unique number to the alarm. This number is called a ‘cookie’ and it is used when users respond to alarms via:
- SMS
- External applications that can be used to acknowledge an alarm, for example, the telephony system, Envox.
ClearSCADA can identify alarms from responses made from ViewX or WebX clients without the need for alarm cookies.
A ClearSCADA system can have a maximum of 250000 alarms raised simultaneously. So, the range of alarm cookies is 1-250000, where 1 is initially assigned to the first alarm raised on the Main server, 2 to the second alarm, 3 to the third alarm and so on. If the maximum limit of 250000 is reached, ClearSCADA will try to remove the oldest acknowledged alarm so that it can re-use the cookie of that alarm. If there are no acknowledged alarms, ClearSCADA will attempt to remove the oldest text alarm. If there are no acknowledged alarms or text alarms, ClearSCADA will remove the oldest active alarm.
For example, if the alarm cookie limit is reached and a new alarm is raised, ClearSCADA will attempt to remove an old alarm. Let’s assume that there are 5 acknowledged alarms which have the cookies 3, 7, 9, 11, and 12. Of these alarms, the alarm with cookie 7 is the oldest. So ClearSCADA removes the alarm with cookie 7 (as it is the oldest acknowledged alarm) and then uses cookie 7 for the new alarm.
On a single server system, the default Cookie Range of Lowest Cookie ID: 1, Highest Cookie ID: 250000 is appropriate and should not be changed.
However, you should define unique Cookie Ranges for each server if:
- Your system is a multi-server system which can have a Main-Main or Main-Main-Main situation (the servers do not have Go Isolated Standby as their Action on Isolated setting)
and
- You want users to respond to alarms via e-mail, SMS or external applications.
If both of the above points apply to your system, you should configure the Cookie Ranges so that they are unique and do not overlap.
By defining Cookie Ranges that do not overlap, you can:
- Stop user alarm responses (made via e-mail, SMS or external applications) from failing unnecessarily.
- Stop user alarm responses from being applied to the wrong alarms. When external applications are used to acknowledge alarms, it is possible that a user’s response could be applied to a different alarm than intended. This can only happen following a Main-Main or Main-Main-Main situation and can be avoided by defining unique Cookie Ranges.
(Examples of the situations described above are included at the end of this section).
When defining the Cookie Range for servers in a multi-server system, you should allocate a suitable portion of the entire Cookie Range to each server (excluding Permanent Standby servers). You do not have to configure the servers to have equal shares of the available cookies. In fact, it is usually preferable to allocate the largest portion of available cookies to the server that will run as the Main server more often. For example, if you have a triple server system, where Server A is the principal Main server, with Server B as the preferred back up and Server C as a third back up, you could allocate 1-150000 to Server A, 150001-200000 to Server B, and 200001-250000 to Server C.
Leave the default settings of Lowest Cookie ID: 1, Highest Cookie ID: 250000 in place for Permanent Standby servers. These servers only function as Standby servers and so cannot allocate cookies.
To define the cookie range for a server:
- Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
- Expand the System Configuration branch of the tree-structure.
- Select Alarms to display the Alarms section.
- Select the Alarms and Events Enabled check box so that ClearSCADA can raise alarms and log events.
- Define the cookie range:
- In the Lowest Cookie ID field, enter the lowest number that the server can allocate to an alarm. This number defines the start of the cookie range for the server you are configuring.
- In the Highest Cookie ID field, enter the highest number that the server can allocate to an alarm. This number defines the end of the cookie range for the server you are configuring.
The server can only allocate cookies that are numbered within the specified range. For example, if you defined the lowest cookie as 1 and the highest cookie as 200, the server could only allocate cookies numbered 1-200 inclusive and so there could be a maximum of 200 alarms raised when the server is Main.
- Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.
Example 1: Preventing E-mail Alarm Responses from Failing Unnecessarily
In this example, we will begin by showing what can happen if two servers use the same cookie range, and a user responds to an alarm via e-mail during a Main-Main situation. Then we will show how the resulting situation can be avoided by using unique Cookie Ranges.
On a Hot-Standby Pair system, both Server A and Server B have the default Cookie Range of 1-250000 in place. When the servers start, Server A becomes the Main server and Server B becomes the standby server. Both servers have Duty mode enabled so that if a Main-Main situation occurs, ClearSCADA will attempt to merge the data from the two servers when the Main-Standby relationship is re-established.
Alarm conditions are detected and so Server A generates alarms. Server A allocates a unique cookie to each alarm, starting with cookie 1 for the first alarm, cookie 2 for the second alarm and so on. During this time, Server B is in Standby mode and so does not allocate cookies.
A network failure occurs between Server A and Server B, which causes a Main-Main situation (Server A and Server B are both acting as isolated Main servers). Server A continues to allocate cookies to alarms that are raised on Server A. However, as Server B is now a Main too, Server B also allocates cookies - to the alarms that are raised on Server B.
An alarm on Server B has the cookie 5. It is redirected to a user in the form of an e-mail. The user receives an e-mail relating to the alarm and the e-mail contains the alarm cookie (cookie 5) and the Condition Name and Object ID of the database item in alarm. To acknowledge the alarm, the user has to use a defined Acknowledgment Keyword in their reply to the e-mail.
As the user is creating the e-mail, the Main-Main situation is resolved. Server A and Server B arbitrate to determine which server is Main. Server A ‘wins’ and becomes the Main. The servers use Duty mode, so ClearSCADA attempts to merge the alarm data on Server A with the alarm data on Server B. Both servers have different alarms that use the same cookies. To rectify this, ClearSCADA examines the cookies on the ‘losing’ server, which in this case is Server B. ClearSCADA creates new cookies for every alarm on Server B that uses a cookie that is already in use on Server A.
So the alarm with cookie 5 on Server A retains its cookie, whereas the alarm with cookie 5 on Server B loses its cookie (a new cookie is generated for the Server B alarm).
The user then sends their e-mail response to the alarm. The e-mail contains the Alarm Acknowledgment keyword, the alarm cookie (5), and the Condition Name and Object ID of the item in alarm.
ClearSCADA receives the e-mail and processes it. It tries to match the alarm details in the e-mail to an alarm on the server. While ClearSCADA can find an alarm that has the defined Condition Name and Object ID, the cookie for that alarm does not match (as ClearSCADA removed cookie 5 from the alarm and replaced it with a new cookie as part of the merge process during arbitration). As ClearSCADA cannot locate an alarm that has the Object ID, Condition Name and cookie defined in the e-mail, the user’s e-mail response fails (even though the alarm that the user was trying to acknowledge still exists on the system).
This situation could have been avoided by allocating a unique Cookie Range to Server A and Server B. Let’s say that Server A had been configured to use the Cookie Range 1-150000 and Server B to use the Cookie Range 150001-250000. With these unique Cookie Ranges in place, the alarms that were raised on Server B during the Main-Main situation would have been allocated cookies 150001 onwards. So when the Main-Main situation was resolved, and the alarm data from the two servers was merged, ClearSCADA would not have needed to remove the cookies from Server B’s alarms (as their cookies would not conflict with the cookies allocated by Server A).
ClearSCADA would have been able to match the alarm details in the user’s e-mail response, as the cookie would not have changed on the server.
Example 2: Preventing External Application Alarm Responses from Being Applied to Different Alarms
In this example, we will begin by showing what can happen if two servers use the same cookie range and a Main-Main situation occurs. Then we will show how the resulting situation can be avoided by using unique Cookie Ranges.
On a Hot-Standby Pair system, both Server A and Server B have the default Cookie Range of 1-250000 in place. When the servers start, Server A becomes the Main server and Server B becomes the standby server. Both servers have Duty mode enabled so that if a Main-Main situation occurs, ClearSCADA will attempt to merge the data from the two servers when the Main-Standby relationship is re-established.
Alarm conditions are detected and so Server A generates alarms. Server A allocates a unique cookie to each alarm, starting with cookie 1 for the first alarm, cookie 2 for the second alarm and so on. During this time, Server B is in Standby mode and so does not allocate cookies.
A network failure occurs between Server A and Server B, which causes a Main-Main situation (Server A and Server B are both acting as isolated Main servers). Server A continues to allocate cookies to alarms that are raised on Server A. However, as Server B is now a Main too, Server B also allocates cookies - to the alarms that are raised on Server B.
So Server B starts allocating cookies to its alarms. For the first alarm, it uses cookie 1, the second alarm, cookie 2 and so on. Of course, the same cookie numbers are already in use on Server A.
An alarm on Server B has the cookie 14. It is redirected to a user. The user receives an email relating to the alarm and the email contains the alarm cookie. The user responds via a tool specifically developed for their system (for example, a telephony system such as Envox). The tool calls the AcceptAlarmsByCookie method for the database item that has the alarm with cookie 14.
As the user is responding, the Main-Main situation is resolved. Server A and Server B arbitrate to determine which server is Main. Server A ‘wins’ and becomes the Main. The servers use Duty mode, so ClearSCADA attempts to merge the alarm data on Server A with the alarm data on Server B. Both servers have different alarms that use the same cookies. To rectify this, ClearSCADA examines the cookies on the ‘losing’ server, which in this case is Server B. ClearSCADA creates new cookies for every alarm on Server B that uses a cookie that is already in use on Server A.
So the alarm with cookie 14 on Server A retains its cookie, whereas the alarm with cookie 14 on Server B loses its cookie (a new cookie is generated for the Server B alarm).
The user response to the alarm is received by the Main ClearSCADA server. The AcceptAlarmByCookie method is called for the alarm with cookie 14. So ClearSCADA acknowledges the alarm with cookie 14, which is the alarm from Server A, not the alarm from Server B (which now has a new cookie). So as a result of the two servers using the same Cookie Range, the user has acknowledged a different alarm than intended.
This situation could have been avoided by allocating a unique Cookie Range to Server A and Server B. Let’s say that Server A had been configured to use the Cookie Range 1-150000 and Server B to use the Cookie Range 150001-250000. With these unique Cookie Ranges in place, the alarms that were raised on Server B during the Main-Main situation would have been allocated cookies 150001 onwards. So when the Main-Main situation was resolved, and the alarm data from the two servers was merged, ClearSCADA would not have needed to remove the cookies from Server B’s alarms (as their cookies would not conflict with the cookies allocated by Server A).
The user’s response to the alarm, made via an external application, would be applied to the intended alarm, as the cookie for the alarm would be unique. There would be no alarms on Server A with that cookie.
When you have finished defining the Cookie Range settings, you can either Define the Disable Alarms Settings or continue with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about E-Mail Settings.
Further Information
Duty Mode: see Enable or Disable Duty Mode.
Alarm Redirection: see Introduction to Alarm Redirection.
Acknowledging an Alarm via E-mail: see Use an E-Mail Action to Enable an Engineer to Acknowledge Alarms Remotely.
Acknowledging an Alarm By Cookie: see Trip Sequences Supported by Redirection Actions.