Why a historian is not enough
Historians are excellent at recording process data. The difficult part is connecting that data to equipment, events, and the decisions a crew must make.
Control Engineering
A process historian does one job exceptionally well: it stores timestamped values and returns them quickly. That makes it indispensable for compliance, performance analysis, and troubleshooting. It does not make it a complete operating environment.
The difference becomes obvious during a fault. An engineer investigating high bearing temperature does not search for “the answer.” They assemble context: motor current, vibration, lubricant pressure, ambient conditions, recent maintenance, active alarms, and the operating mode at the time. Only some of that lives in the historian, and the tag names rarely explain how the pieces fit together.
Tags record signals, not meaning
Consider a point named BLDG2_CWP03_MTR_I. A site engineer may immediately read that as the motor current for chilled-water pump 3 in Building 2. Software needs the same relationships stated explicitly:
- the point measures current in amperes;
- it belongs to a motor, which drives a particular pump;
- the pump serves a chilled-water loop;
- two other pumps can perform the same duty; and
- its expected range depends on whether the pump is starting, running, or stopped.
A historian may hold the point name, descriptor, engineering units, and years of samples. The asset hierarchy and operating relationships are often incomplete, split across spreadsheets, or encoded only in naming conventions. Before software can reason about the pump, someone has to resolve those semantics.
That mapping work is not glamorous, but it determines whether every later result is useful. A beautifully rendered trend against the wrong asset is worse than no trend at all.
A trend answers a question you already have
Trending suction pressure and motor current can confirm that both changed at the trip. It cannot, by itself, explain whether the event was caused by a process restriction, an electrical problem, or a deliberate control action.
To narrow the possibilities, the engineer needs facts from other systems:
- Alarm history: What occurred first, and which alarms were consequences?
- Work management: Was the transmitter recently replaced or calibrated?
- Procedures: What interlocks and permissives apply in this operating mode?
- Shift records: Was the plant being transferred, started, or tested?
- Asset context: Which equipment shares the same upstream source?
These are joins in the practical sense, even when there is no shared database key. Today, experienced staff perform them from memory.
Keep the historian; add the missing context
Millwright does not copy years of samples into a new system or ask a site to abandon its historian. It reads data where it already lives, resolves tags to assets, and places the relevant event window beside alarms, work, and procedures.
This separation is deliberate. The historian remains the system of record for telemetry. Millwright records the investigation: why those points were selected, what they showed, which competing explanations were considered, and what action followed.
The result is not “a smarter trend.” It is a traceable path from raw process data to an operational decision—and a record the next shift can use without knowing the exact tag name or who happened to be on duty.