Standards such as IEC 61511 require regular proof testing of safety-related alarms. But most DCS alarms aren’t safety-related and most sites don’t routinely test these DCS alarms.
Some DCS alarms occur often enough (or are of relatively low value) that there’s insufficient justification for testing them. But other alarms may have a relatively high value and remain inactive for long periods of time — thus posing concerns about whether they will activate when required. Testing such alarms to prove they are operational clearly has value. EEMUA 191 includes recommendations for testing alarms. It’s generally impractical to test all alarms; so, it’s essential to identify and implement a realistic testing strategy based on the value of each alarm in terms of the potential consequences if it doesn’t activate when it should.
For example, a simple strategy might call for annual testing of all higher-priority alarms that haven’t been activated in the previous year. If the EEMUA recommendations for the proportion of the higher-priority alarms in the alarm system have been followed, this would mean that only around 15% to 20% of all configured alarms would require testing — and a large proportion of those might have been activated during the previous year, significantly reducing the number needing testing.
Given that most plants currently don’t systematically test alarms, there’s certainly some potential for performance improvement.
6. Alarm suppression technology. Use of suppression has often been advocated as a means for improving poorly performing alarm systems — with little or no consideration of other potential methods.
An event frequently quoted as a good opportunity for suppression is when large numbers of alarm activations occur when a compressor trips. Such events often generate 100 or more alarms in a short time. Apart from the first few alarms, most of these activations are of little or no value to operators — and are obvious candidates for suppression. To be effective, suppression of consequential alarms needs to be done quickly — often within a few seconds of the event causing the compressor trip.
In other situations, e.g., when a pump changeover occurs, there’s also value in suppressing a relatively small number of alarms for a period of time. The pump changeover will often have been operator-initiated and timing will depend on pump run-down or run-up dynamics. This clearly differs markedly from the requirements of suppression during a compressor trip.
There’ve been many attempts over the years to suppress or mask unwanted alarms. Many of these attempts have been costly and haven’t been very effective. In some cases the alarms being suppressed simply resulted from poor design; rationalization of those alarms often removes the need for suppression.
A key requirement for suppression schemes is to identify a pattern of plant or control-system conditions that must exist before initiation. Any alarm suppression scheme demands careful design, to avoid potentially dangerous situations where alarms remain suppressed when they should be operational.
One approach often used is to write custom code. While this offers maximum flexibility, it can also cause problems because the code can be difficult to test and maintain. A better approach is to use a standardized (and well-tested) suppression function based on tabulated suppression requirements. Tabulated data typically will need to include several different types of information:
• Required conditions for initiation of suppression, e.g., plant mode, values of process variables, digital states and other alarm conditions. The term “permissives” is sometimes used for such conditions. It’s sensible to employ (where possible) multiple permissives to reduce chances of failed or noisy signals initiating suppression;
• A set of alarms that need to be suppressed — and, in some cases, the order of suppression so that alarms expected to occur early during an event are suppressed first;