Why it's time to change the way control centers manage alarms

The world of emergency call centers has changed dramatically in recent years. Most emergency control centers operate above their capacity limits: There are too many alarms, they stay longer in queues, workflows are poorly implemented, and in addition, the conversions of the European standards frameworks during the pandemic brought another challenge to the operators: One that is permanently aggravated by the existing staff shortage. For the end customer and the responsible specialist installer, these are serious problems that control centers must address to remain competitive.

This article breaks down 5 of the most common problems of control centers and shows what impact they have on security businesses' efficiency, how they can be measured, and solved.

1. Too many alarms

Having too many alarms is most likely the most widespread problem of alarm systems in control centers. But how many alarms are too many, and how can you measure if your control center needs to take action?

When are alarms too many?

While this depends on the nature of the processes and the complexity of the operator response required, a common rule of thumb says that 12 alarms per hour should be considered the maximum.

Methods of measurement:

  • The best measurement for this problem is the average alarm rate: The number of alarms incoming per operator console (an operator's span of control or area of responsibility) in a certain time unit (e.g., per operator, per hour, over a month time), then averaged over the reporting period.
  • To determine if they have too many alarms, security operation centers can alternatively look at the number of standing alarms and the percentage time in flood.

What if each alarm was a real indicator of an abnormal condition, each requiring a response? With too many of them, it becomes almost impossible for the operator to respond to each of them adequately. And even if false alarms are among them, the operator becomes desensitized to alarms in general because he simply gets used to receiving (too) many alarms, which then, in turn, has a negative effect when a real alarm occurs.


2. Chattering alarms

This phenomenon is often fueled by so-called chattering alarms, which are nothing else than nuisance alarms: Alarms that repeat excessively in a short time interval. Chattering alarms desensitize the operator and are the epitome of nuisance alarms. Therefore, according to industrial alarm standards, no chattering is acceptable. Chattering alarms are often caused by poor alarm design, but device maintenance is also a common cause.

How do you measure chattering alarms?

Chattering alarms are defined by the number of times an alarm is reported to the operator twice within a specified time interval (usually 60 seconds).


3. Alarms that do not require a response

Alarms are audible and/or visible means of indicating to the operator that a piece of equipment is malfunctioning, a process is derivative, or another abnormal condition is requiring a response. However, if alarms are also used to only notify the operator of situations, this results in further desensitization of the operator to alarms. The problem behind this widespread practice is the erroneous assumption that the alarm function is the only method of communication between the automation system and the operator.

How do you measure real alarms?

It's important to distinguish between alarms and alerts. Alerts are audible and/or visible means of indicating to the operator an equipment or process condition that requires awareness and does not meet the criteria for an alarm. Often, they are important but not urgent and important (as alarms).

The process of distinguishing between alarms and alerts is called alarm rationalization. With the ultimate goal of determining the most efficient number of alarms, this is done by reviewing, validating, and justifying alarms that meet the criteria of an alarm. During this often time-consuming rationalization, it is not uncommon for up to 50 percent of alarms to be eliminated because they do not require a response. However, this does not mean that the goal of rationalization is to eliminate alarms. Instead, it is to ensure that the right alarms are in place with the right threshold, priority, and documentation for operator training.


4. Alarms that stay alarms

Even after they stale. These are alarms that do not require a response (anymore): They once might have, but the response is no longer needed. Measuring stale alarms is easy: It's the number of reported alarms older than 24 hours. Alarms like these clutter the alarm summary and, again, desensitize the operator.

In practice, there are two common causes for stale alarms:

  • Control system configuration practices
  • Poor management of change

One study on that subject revealed that almost 30 percent of stale alarms were due to equipment that was not operating because it wasn't needed at the time. For example, the basic configuration practices created an alarm that a pump was not running – even when the pump was intentionally not running. That's why it is so important to have good basic configuration practices set up in the first place to prevent many alarms.

The second cause of obsolete alarms is the lax handling of changes. When devices are removed from operations, the alarms should be removed from the control system as well – or at least taken out of service. It is not uncommon to find alarms at the bottom of the alarm summary for devices that were removed years ago.


5. Alarms with the wrong priority

Alarm priority is the ranking of alarms by severity and response time.

Although the alarm priorities should be based on how urgently the operator needs to take action, many alarms are assigned the wrong priority. Prioritization also includes consideration of consequences that the operator can avoid: The difference between scenarios in which the operator responds and those in which he does not. Having many alarms that have the wrong priority makes priority less meaningful and possibly even meaningless to the operator. This can then lead to the operator responding with an inappropriate action when multiple alarms occur. A consistent method of prioritization based on the severity of consequences and response time can radically change alarm priorities. In some cases, 80 percent of alarm priorities have been changed, mainly to lower priorities.

Crystal-clear answers through a change of perspective

Why must there be so many organizational interfaces in a safety chain?

It is a common misconception that practically all procedures in the alarm service are "prefabricated." For each criterion and, if necessary, time of day and week, there are clear instructions on what must be done after an alarm is raised. The installer and/or the control center determine this in detail with the customer during the safety analysis. But in current processes, some contradictions remain: 

  • Every alarm is routed through the hands of a dispatcher first instead of directly forwarding it to the place/person carrying out the emergency response. 
  • After an intervention, operators often wait a long time until they receive the alarm report. Instead, it could already be created by the intervention force with the DKG (digital communication device according to VdS 3138/2172) and directly imported into the integrated IT of the security chain. 
  • NSL specialists have to call hundreds/thousands of customers in the evening because their intrusion detection systems have not yet been activated at the specified time. They could still use an automated workflow that handles this in the background. 


So, what is the solution?

The good news about common problems is that there are usually common solutions to them. Many control centers across all industries have already taken action to control their alarm systems to minimize common problems and negative effects. In these control centers, alarm systems are an important help for the operators, as they indicate the right time to take the right action and thereby prevent undesirable consequences.

The answers to the addressed challenges in the safety chain of security businesses repeatedly all come to a unanimous conclusion: The technical implementation of the security chain is in excellent hands with the cloud. All units entrusted with security can be optimally supplied with information from there. The connection to the security chain for specialist installers must be fast, simple, and transparent. They want to set up the transmission independently without the involvement of third parties, preferably already pre-assembled. All high-security protocols/security categories, such as SecurIP, must function without problems. How does this service work? The customer expects a well-founded analysis of his security needs, which is documented immediately. In addition to the structure of the alarm system, and the selection of components, the performance of the safety chain is now also mapped. After all, this is an integral part of the performance promise. The relevant data is uploaded directly to the cloud, where it is linked to standardized or customized procedures. Ideally, the processes are automated as much as possible, and the customer himself is involved, e.g., in verifying alarm images or alarm sounds.

Customers expect more than just a suitable alarm system from installers. They expect an end-to-end security service from consultation to intervention, regardless of whether it is the police, fire brigade, or private security service provider. If customers can contribute to an efficient process themselves, e.g., by analyzing an alarm image on their smartphone, they are most likely happy to do so. But if they are prevented from doing so, they need an automatic backup function that performs this task in their place. However, this bypass must only last seconds and delay the processes for danger prevention as little as possible.

Yes, the intervention is ultimately the biggest challenge in complete automation. Unfortunately, police and fire brigades cannot be activated by automatic calls; a security center had to be integrated. With Sitasys chosen as the system supplier for cloud-based alarm transmission, alarm management, and automated alarm service, a powerful partner had to be found for the "last mile." With some support, a powerful call center of a well-known provider could be won for these tasks. Of course, with bidirectional, automated reporting. All time-critical alarms need to run fully automatically through the system until they are processed all around. This is both very safe and very fast. Nowadays, there is no reason for unnecessary manual interventions that slow down the data flow. More so, many control centers suffer from dramatic staffing problems. 

Not to be underestimated is the typical installer's wish to receive system data of the alarm systems in real-time and process them to the complete satisfaction of the customers within the scope of maintenance and emergency service, also remotely. This is increasingly becoming an intellectual challenge because customers are increasingly operating smart building technology systems with a high degree of automation. Logically, they expect the system performance of the smart devices to be used optimally in the security chain.


Changing perspectives and asking WHY: It's how change starts. 

Simply because old processes no longer work. The cloud is the right and sustainable environment for the operation of alarm transmission systems and hazard management systems. IT/server/network and data center specialists take care of the technical processes and ensure continuous operation. Neither installers nor customers want to take care of this themselves. Many smaller control centers are hopelessly overburdened with this. Only the integration of third-party systems, e.g., for intervention control across company boundaries, can be set up quickly and securely on this basis. For security experts, the critical question is no longer whether other security chains will also move into the cloud, but only when.