SCADA raises an alarm when a measured value passes a configured limit. Yet around 30% of those alarms receive no operator action during the next hour. That does not usually mean operators are overlooking alerts. Many alarms, including valid ones, provide no actionable meaning by themselves. A value crossed a boundary. What does that crossing indicate in light of everything else occurring in the process? That is the synthesis problem, and SCADA alerting was not built to answer it.
What SCADA alerting does well
SCADA and DCS alarm systems perform one important task very well: they watch configured measurement points against configured limits and quickly report a crossing. Their architecture prioritizes reliability and deterministic behaviour. A limit is crossed, an alarm appears, the operator is notified, and the event is recorded. That supports process safety compliance, regulatory reporting, and detection of the first sign that conditions have moved outside their normal range.
The limitation is that this design is both point-in-time and single-variable. It answers "is this measurement currently outside its configured limit?" It does not answer "what does this measurement, combined with these six other measurements over the past 40 minutes, suggest about the current state of this process unit?" Those questions are not equivalent. The latter is what an experienced operator works out while judging a developing condition. SCADA presents the inputs; the operator supplies the synthesis.
Where threshold alerting reaches its limit
Incident reviews in process operations repeatedly expose two situations where threshold alerting falls short.
One is a slowly developing deviation that crosses no single limit until the issue is already established. Heat exchanger fouling may appear as a gradual outlet temperature rise, a declining temperature difference, and a growing approach temperature. For weeks, every measurement can remain inside its configured range. Taken together, however, the three trends, compared with the exchanger's design parameters, have been pointing to trouble. Detecting it early requires watching all three at once and manually working out the approach temperature trend. Operators overseeing dozens of units rarely do that continuously. They inspect trends when another event gives them a reason.
The other is an alarm cascade caused by one upstream event. A sudden feed rate change may produce downstream temperature, level, pressure, and flow alarms within a minute. Every alarm is technically valid because its measurement crossed a limit. Yet the complete cascade contains less diagnostic value than the upstream cause that produced it. An operator who spots the feed rate change can correct one issue; someone handling each alarm in sequence is mainly working through noise.
Synthesis is a data architecture problem
The synthesis challenge is often treated as a display issue: improve trend views, process graphics, or contextual overlays. Those changes help somewhat, but the deeper constraint is architectural. SCADA and DCS historians retain time-series records for separate measurement points. They were not built to reason across streams at once, preserve calculations informed by a process model, or expose patterns that arise from several variables changing together.
Adding synthesis to an existing SCADA setup requires either an analytical layer that reads the historian and performs cross-stream calculations, or a major change to how the control room consumes data. For most operating sites, the separate layer is the practical route. SCADA keeps performing its dependable control and alarm functions while another system turns historian data into the combined view SCADA does not provide natively.
The concept is established. Process historians have handled advanced analytical queries for years. What has remained difficult is making synthesis continuous, aware of operating context, and available in an actionable form during routine work rather than only after an incident. Historical analysis can reveal recurring patterns; it cannot explain what those patterns mean to the operator on the current shift.
What synthesis looks like in practice
At one site we have worked with, the control room oversees a continuous reaction section with four interacting temperature loops, two recycle streams, and catalyst activity that declines along a known profile. During normal operation, its SCADA system produces 80 alarms per shift. Most are accurate but lack meaning in isolation. Operators must read them against the catalyst cycle stage, changes in recycle composition, and the current production rate target.
The useful output there is neither fewer alarms nor a redesigned view of the same alarms. It is one synthesized assessment for each process unit: the unit's current position within the expected operating envelope for its catalyst-cycle stage, the two measurements furthest from expected behaviour under present conditions, and a recommended first check. Operators respond most directly to that final item. They can often form the diagnosis once attention is directed to the right location, but knowing where to look first cuts the investigation time that currently delays decisions.
Where synthesis meets decision-making
Synthesis is not a substitute for operator judgment. It may show that two measurements are moving in a pattern consistent with known fouling on a particular heat exchanger. It cannot know that this week's production rate was increased to meet a customer delivery commitment, a fact that changes the choice between accepting operating risk and scheduling early cleaning. Operators hold context absent from process data. Synthesis identifies where to look and what the readings suggest; the operator decides after weighing the wider situation.
This distinction should shape the system. A layer issuing an unqualified "take action X" recommendation assumes responsibility for a process decision it cannot fully understand. A layer stating "the data is consistent with pattern Y, confidence 78%, here are the measurements driving that assessment" gives the operator evidence for a rapid judgment. It may sound like a technical difference, but it strongly affects whether operators trust the system or learn to ignore it.
What continuous synthesis changes
Shift handover makes the benefit of continuous synthesis especially clear. An outgoing operator who has observed a slow trend for eight hours carries context that is difficult to convey in a 15-minute handover conversation. The incoming operator begins without that accumulated pattern recognition and must manage from a baseline view rather than eight hours of observation.
A continuous synthesis layer that tracks each unit's deviation from expected behaviour over the past 24 hours gives the incoming operator an objective account of what the outgoing operator has been following. The conversation can move from "I've been watching that level trend, it's been creeping up slowly, probably worth an eye on it" to "here is what the synthesis shows about how that trend has developed, and here is where it sits relative to historical patterns." Information once held in one operator's memory becomes available in a form that supports quicker, more dependable situational assessment.
Moving knowledge from individual operators into a persistent system is the practical long-term case for synthesis in process operations. Expertise remains essential, but it does not transfer cleanly at shift changes, scale across an entire site at once, or remain available when experienced people retire. Synthesis does not remove that expertise; it gives the knowledge a durable place to accumulate and remain useful.