Real-time process monitoring means continuously collecting process data, such as temperatures, pressures, flows, levels and analyzer readings, and presenting it as it happens: live values on process screens, trends, and alarms when a value leaves its safe or expected range. Behind it, a data historian stores every value with a timestamp so engineers can investigate events, compare runs and report on performance.
This article supports our guide to industrial process control. Monitoring is the layer operators and engineers look at every day; the control loops underneath are covered in the guide.
Many monitoring applications are built in LabVIEW, which handles acquisition, display and logging in one environment.
What a process monitoring system includes
| Part | What it does |
|---|---|
| Data collection | Reads values from controllers, PLCs, data acquisition hardware and analyzers |
| Process screens (HMI) | Shows the process laid out like the P&ID, with live values and equipment states |
| Trends | Plots values over time, live and historical, so changes and drifts are visible |
| Alarms | Notifies operators when a value or state needs action, with priority and acknowledgment |
| Historian | Stores time-stamped values, alarms and events for later analysis |
| Reports and exports | Run summaries, batch records, shift reports and data exports for engineering |
| Remote access and notifications | Web views, email or text alerts for unattended sites |
Real-time vs near real-time
“Real-time” means different things at different layers. The control loop needs deterministic timing, measured in milliseconds, and should run in the controller. Monitoring screens are usually fine updating every 0.5–2 seconds, and a historian may store most values once a second. What matters is that the monitoring layer never sits inside the control loop: if a screen freezes or the network drops, control continues.
Monitoring architecture
- Field and controller layer: sensors, transmitters, PLCs, real-time controllers and data acquisition hardware.
- Collection layer: drivers and protocols such as OPC UA, Modbus TCP and EtherNet/IP, buffering data if the link drops.
- Storage layer: the historian or database, with compression and retention rules.
- Presentation layer: operator screens, engineering trends, dashboards and reports.
Buffering at the collection layer is easy to overlook and important: without it, a network outage leaves a permanent hole in the record.
How much data does a historian store?
Worked example: historian sizing
Raw. 500 tags sampled once a second is 500 × 86,400 = 43.2 million values a day. At 16 bytes per value (8-byte timestamp, 4-byte value, 4-byte quality), that is 43.2 million × 16 = 691 MB a day, about 252 GB a year.
With deadband compression. A new value is stored only when it changes by more than a set amount. Steady process values compress well; if 10% of samples are kept, storage falls to about 69 MB a day, roughly 25 GB a year.
The trade-off. Set deadbands from each instrument’s accuracy, not arbitrarily. Too wide and real changes vanish; too narrow and noise is stored as if it were data.
Alarm management
More alarms do not mean better monitoring. When everything alarms, operators learn to acknowledge without reading, and the important alarm gets lost. ISA-18.2 and EEMUA 191 set out good practice; an average of around one alarm per 10 minutes per operator is widely treated as manageable.
- Every alarm should require an operator action. If no action is needed, it is an event, not an alarm.
- Assign priorities by consequence and time to respond.
- Use deadbands and delays so noisy values do not chatter in and out of alarm.
- Suppress consequential alarms, for example low flow alarms after a pump is deliberately stopped.
- Review the most frequent alarms regularly and fix the causes.
Trends that help engineers
- Overlay setpoint, PV and controller output on one trend; the output often explains the PV.
- Align runs or batches on the same time base to compare them.
- Show alarm and operator events on the trend so cause and effect are visible.
- Allow export to CSV or analysis tools without needing a programmer.
Monitoring remote and unattended sites
Remote monitoring applies the same ideas over slower or intermittent links: local logging and buffering, store-and-forward when the link returns, and alarms that reach people by email, text or phone. We built a disaster prevention monitoring system that logs environmental values at mission-critical remote facilities and triggers alarm protocols when values leave tolerance.
Data integrity
- Synchronize clocks across controllers and servers so timestamps can be trusted.
- Store quality flags, so a value from a failed sensor is not mistaken for real data.
- Log setpoint changes, overrides and alarm acknowledgments with the user who made them.
- Back up the historian and test restores.
In a pilot plant, monitoring data is often the main product of each run; see pilot plant control systems for how to plan logging rates.
Need better visibility of your process?
Sciotex builds process monitoring, trending, alarm and data logging systems for pilot plants, production processes and remote sites, designed and supported in the US since 1997.
Frequently asked questions
It is continuous collection and display of process data, such as temperatures, pressures and flows, as it happens, with trends and alarms that let operators and engineers see and react to changes immediately.
A historian is a database designed to store large volumes of time-stamped process values, alarms and events efficiently, usually with compression, so they can be trended and analyzed later.
Most process values are logged about once a second. Fast signals may be logged at higher rates around events, and slow values such as tank inventory can be logged less often.
Guidance from ISA-18.2 and EEMUA 191 treats around one alarm per 10 minutes per operator as a manageable average. Floods of many alarms in a few minutes after an upset are a sign the alarm system needs rationalization.
No. Monitoring displays and records the process; control acts on it. Control loops should run in controllers so they continue even if the monitoring system or network fails.
