Insights Automation · Feature story
Designing a practical equipment monitoring system
How data collection, control logic and visualization combine into one coherent operational picture, and why the design starts with the decisions an operator has to make, not with the sensors.
This story is based on an internal demonstration on test equipment, not a client installation. Tags, set-points and timings in the figures are illustrative.
01The context
Monitoring is useful only when the system makes important conditions visible and supports a real response. Collecting every available measurement is not the goal. A pump skid can expose dozens of values, from motor current and winding temperature to discharge pressure and run hours, and it is tempting to put all of them on a screen because the data is there.
The result is familiar: a dense dashboard that looks thorough, alarms that fire often enough to be ignored, and an operator who still walks to the panel to find out whether anything is actually wrong. This story walks through a different order of work, using a single transfer pump as the example.
02Start from the operating decisions
Before choosing a sensor or a chart, list the questions the people running the equipment have to answer, and what they do with each answer. For a transfer pump, the list is short:
- Is the pump delivering, or is it running against a closed valve?
- Is the motor at risk, and should it be stopped before it is damaged?
- Is the strainer blocking, so that maintenance should be planned this week?
- Can we trust what the screen is telling us right now?
Each question implies a response: check the line-up, trip the motor, raise a work order, or send a technician to the instrument. A signal that does not support one of these responses does not need to be on the first screen. It may still be logged for diagnosis later.
03Map the minimum signals
With the decisions written down, the signal list follows. Discharge pressure from a transmitter (PT-101) answers the delivery question. Motor current (IT-101) and a run-feedback contact answer the protection question. A slow trend of the same discharge pressure answers the strainer question. Three field signals cover four decisions.
The next step is to trace each signal end to end and give every hop a named interface and an owner. Figure 1 shows the path for one measurement.
Swipe sideways to read the full diagram →
Writing the path down this way exposes questions that otherwise surface during commissioning: who scales the raw milliamps, where the alarm logic lives, and what happens to readings when the network between the panel and the server is down. In this design, alarms and interlocks stay in the PLC, so protection never depends on the network, and the gateway buffers data so that the historian can be filled in after an outage.
04Define failure states before screens
The approach is to define what “wrong” looks like for each decision, as a condition the logic can evaluate, before designing any view. A useful format is a decision table: one row per question, with the signal, the condition and the response. It becomes the shared reference between the people writing the control logic and the people building the software.
| Decision | Signal | Failure state | Response |
|---|---|---|---|
| Is the pump delivering? | PT-101 + M-101 RUN | Pressure below 2.0 bar for 20 s while the motor runs | Alarm. Operator checks valve line-up. |
| Is the motor at risk? | IT-101 | Current above set-point for 10 s | Trip by PLC interlock, then alarm. |
| Is the strainer blocking? | PT-101 daily trend | Pressure above 5.0 bar for 30 s, or rising day on day | Maintenance work order this week. |
| Can we trust the reading? | Loop current, PT-101 | Outside 3.8–20.5 mA (NAMUR NE 43 range) INSTRUMENT FAULT | Flag as sensor fault, not process alarm. Send a technician. |
The last row matters more than it looks. A broken transmitter cable reads as zero pressure, which, without a quality check, would raise a “pump not delivering” alarm and send the operator to the wrong place. Separating instrument faults from process alarms is one of the cheapest ways to keep alarms credible.
05Sampling, deadbands and delays
Once the conditions are defined, they need timing. Three settings decide whether an alarm is useful or noise: how often the signal is sampled, how long a condition must persist before it counts, and how far the value must recover before the alarm clears. Figure 3 shows all three on a single pressure trace.
Swipe sideways to read the full chart →
The trace also shows why sampling is a design decision and not a storage setting. If the gateway only forwards one-minute averages, the spike at (A) never reaches the historian. That may be acceptable for a strainer trend, and unacceptable if the spike is the first sign of water hammer. Decide per signal, and record the decision next to the tag.
06Design views around the response
Only now does the screen design start, and it has a simple brief: the first view answers “does anything need me?”. For the pump, that is one status line per question in the decision table, with the active alarm on top and a link to the trend that explains it. Detailed charts sit one level down, for diagnosis.
A few clear status views, useful alerts and traceable events are worth more than a dense dashboard with no hierarchy.
From the lessons of this demonstration
Every alarm should also leave a trace: when it was raised, the value at the time, who acknowledged it and what was done. That event history is what turns monitoring into maintenance planning, and it is usually more valuable after six months than any individual chart.
07Lessons
The demonstration confirmed an order of work more than any specific technology choice. Each step constrains the next, and skipping ahead, usually straight to the dashboard, is what produces systems that collect a great deal and explain very little.