a configurable module for real-time complex alarming

Download the Brochure

What is AlarmMaster?

The AlarmMaster product has been built from the ground up to provide our customers with a tool powerful enough to combat their own bespoke alarm issues; such as, alarm flooding, disparate alarm servers, poor user interfaces (UI), Nusiance/sub-ordinate alarms and many more.

Feature Highlights:
Hierachical Assignment, Dynamic Occlusion, Normalisation, Rule-based Pattern Analysis, Enrichment & Dynamic Filtering

Hierarchal assignment

Add structure to alarm data, by assigning alarms to pre-configured asset hierarchies.  

AlarmMaster allows all received events to be allocated to a category (logical grouping mechanism to allocate individual events into individual groups) and a node in a hierarchy. Hierarchies can be fully built directly within AlarmMaster or can link to an external source, which provides the necessary information to build the hierarchy dynamically (e.g. AssetWorX64 or an existing Asset hierarchy database used within your organisation).

The hierarchy can be utilised to provide various aggregation rules to allow easy access to the information contained within the hierarchy such as counts of alarms or aggregated data based around specific fields from received events. Filtered views of alarms can also be created by subscribing to specific levels or nodes within the hierarchy. This can assist in helping operators receiving only those alarms that are allocated to their equipment, floors or areas of operation. 

Dynamic Occlusion

Configurable logic hides or occludes inconsequential alarms, allowing operators to focus on what matters

Based on user configurable logic, AlarmMaster auto-suppresses trivial alarms. Those inconsequential child alarms are  occluded from the primary view within the Graphical User Interface (GUI), to prevent distraction and reduce alarm flooding. 

Rule-based Pattern Analysis  

Create template rules, based on business-specific criteria to predict future incidents​

AlarmMaster comes with a customisable business rule engine that looks at underlying alarms and events, identifies correlated patterns in accordance with the respective rule, and raises a derived alarm. These business rules can scan multiple data sources and systems in real-time and inform operators of causes and effects that they might not be aware of.

Water Industry Example

A typical example from the water industry is to combine telemetry alarms and customer call events to raise an alarm when alarms and events from each respective system have been detected, such as: - Low pressure on X loggers in the same DMZ or WSZ - X amount of customer calls in a certain District Metering Zone (DMZ) or Water Supply Zone (WSZ) The result of the above would be a derived alarm with a probable cause associated with it: burst/leaking pipe in DMZ/WSZ area Y.

Learn More

Alarm Enrichment

Supplement basic alarm data, by adding additional information to the alarm, using a variety of data sources​

Alarm enrichment supplements alarms with key additional information from a variety of data sources. Utilising a dynamic lookup which can retrieve data from external sources such as a database or Web Service, AlarmMaster auto-contextualises the basic alarm information conventionally visualised inside the standard alarm grid/table viewer, with crucial tags and naming conventions known to the operational team. For example, users could enrich alarms with asset names and IDs from 3rd party asset systems, reducing the number of clicks and time it takes to identify what stakeholders an alarm could be affecting


Dynamic Filtering

Create logic-based, server-side filters to collate and organise alarm data

Once the data is enriched, operations can begin to filter that data for specific views. An operator who is dealing with a certain plant/floor/machine issue, could drag and drop a display filter to hide all the alarms not associated with that issue/zone. Likewise, alarms can be dynamically assigned to certain containers, such as a ‘monitored alarm container’ , i.e. a defined alarm group. This container would allow any alarm exposed by AlarmMaster to be added and flagged as ‘monitored’, regardless of the alarms inherited severity. This is especially helpful in providing shift handover support.