Synapse Group
Industrial alerting and event management
Only what demands action should reach the operator.
Deduplication, grouping by event, causal correlation and severity that depends on plant state. Every alert answers what happened, how serious it is, the probable cause and what to do.
Get in touchWhen it shows up
If this is happening, this is the problem.
A single disturbance fires dozens of alarms and the operator cannot read them all.
There are alarms that have been active for months and nobody looks at any more.
The same condition repeats every week and the root cause was never addressed.
Nobody can say what share of the shift's alarms ended in an action.
How we approach it
What gets installed and how detection works.
- 01
Rationalisation
First measure how many alarms per operator per shift there are today, which repeat and which are never acted on. Automating management without pruning first is automating the noise.
- 02
Event engine
Deduplication, suppression of those that are consequences of another, grouping by event and causal correlation. Rules where the physics is known, models where it is not.
- 03
Severity with context
The same variable does not mean the same thing at start-up, in steady state or during planned shutdown. Severity depends on plant state, not only on the threshold crossed.
- 04
Escalation and traceability
Acknowledgement, escalation if nobody takes the alert, and a record of what was done with each one. Without that trace there is no way to know whether the system is working.
Where it applies
The industries where this problem weighs most.
The same work changes scale and standard by front, not nature. These are the pages with the context for each one.
What it is measured against
The indicators are set before anything is installed.
A pilot without a baseline is no basis for a scale-up decision. These are the indicators the work is designed against, measured before starting so there is something to compare with.
- Alarms per operator per shift
- The indicator that says whether the control room is operable. Measured before anything is changed.
- Percentage of alerts acted on
- How many ended in a recorded action, the only proof the alert was worth sending.
- Recurring alarms
- Those that repeat period after period, because each one is a root cause left unaddressed.
- Acknowledgement time
- How long somebody takes to pick up a critical alert.
Frequently asked
What we get asked before the first meeting.
What is the difference between an alarm and an alert?
A classic alarm is deterministic: if pressure exceeds the limit, it sounds. A contextual alert crosses that variable with vibration, temperature, operating regime and history to say how serious it is, the probable cause and what to do. The first informs; the second lets you prioritise.
How do you cut alarm overload without losing coverage?
With deduplication, grouping by event, suppression of those that are consequences of another, and severity that depends on plant state. No condition stops being watched: what changes is how many notifications one disturbance generates. Recurrence analysis is then used to attack the ones that keep repeating.
Can it be done on the SCADA we already have?
Yes. The event layer feeds on what the SCADA and historian already publish, over OPC UA or MQTT, and returns the alert to that same SCADA, to email, to the app or to the CMMS depending on each shift's workflow. It does not require replacing the existing supervisory layer.
How long before the control room notices a change?
Alarm rationalisation usually shows an effect within weeks, because much of the noise comes from a handful of badly configured tags. Correlation and probable-cause models need more history; that is why the work is ordered that way and not the reverse.
Contact
Let's talk.
If you have an operational challenge, an innovation project in mind or a question about applying technology to your industry, get in touch.
proyectos@synapsegroup.techWe reply within 48 business hours.