Every distributed control system has to remember its recent past so operators can trend a value, investigate an upset, or check how a loop behaved overnight. The component that does this at the control layer is the history module. It is the node inside the DCS that continuously collects process values, stores them with a retention scheme, and serves them to trend displays. This guide explains what a history module is, how it collects and compresses data, how it differs from a plant or enterprise historian sitting above the control system, and what its retention role really covers.
History module in one line: A history module is the part of a DCS that collects, stores, and trends process data at the control layer, so operators can pull up recent history for any tag from the operator stations. It runs close to the controllers, keeps a relatively short-to-medium retention of high-resolution data, and feeds the system's trend displays, which distinguishes it from an enterprise or plant historian that aggregates data from many systems for longer-term storage and business use.
A history module lives inside the DCS itself, typically as a dedicated node or a function running on a station, and its job is to continuously capture the values flowing through the control system. It subscribes to the process variables, controller outputs, setpoints, and status points that the operators need to see over time, and it writes them to its store on a regular cycle. Because it sits at the control layer, it has direct, fast access to the data and does not depend on any link out of the control network, so the recent history an operator relies on during a shift is always available locally.
The module organises what it collects into a set of collection groups, each with its own sampling rate. Fast-moving values that matter for loop analysis might be logged every second or few seconds, while slow, stable values might be logged far less often, because storing them at a high rate would waste space without adding information. The engineer configures which tags belong to which group, and the module records them accordingly, building a rolling archive that the trend displays draw from whenever an operator opens a trend or scrolls back in time.
The store itself is usually a purpose-built, time-series structure rather than a general database, because the access pattern is overwhelmingly about pulling a range of one or more tags over a span of time. That specialisation is what lets the module answer a trend request quickly even when it holds a large amount of data. From the operator's point of view the history module is invisible; it simply means that any point on their screen has a past they can look at without leaving the control system.
A history module is not meant to remember everything forever. Its retention is generally sized for operational needs, keeping enough high-resolution history that operators and engineers can investigate recent events, tune loops, and review a shift or a few weeks of behaviour. Older data is rolled off as new data arrives, either discarded or, more commonly, handed up to a longer-term store. To make the most of its capacity, the module often applies compression, keeping full resolution while a value is moving meaningfully and thinning out long stretches where a value barely changes, so it stores the shape of the data without every redundant sample.
Above the history module sits the plant or enterprise historian, and the two are easy to confuse because both store process history. The difference is scope and purpose. The history module is part of the control system, close to the controllers, tuned for operator trends and shorter retention. The plant historian is a separate, larger system that collects from the DCS, from other control systems, and from lab and business sources, keeps years of data, and serves reporting, analytics, and enterprise users. The history module is frequently a feeder to that historian rather than a competitor to it.
This layering means data often flows upward: values are first captured by the history module at the control layer, and a collector then forwards them to the plant historian for long-term keeping and wider use. The history module gives operators fast, local, recent trends, and the historian gives the plant and the business a durable, consolidated record. Understanding which one you are querying matters, because they can differ in resolution, retention, and even in the compression applied along the way.
The role a history module plays inside a DCS maps closely onto what a cloud SCADA platform provides for a distributed operation. In both cases the goal is that any value an operator can see live also has a stored past they can trend and investigate. Where a DCS history module keeps that past on a node inside the control network, a cloud SCADA system keeps it centrally, so a value from a remote wellpad, tank battery, or compressor station carries its own history in the same place the live value appears.
For operations spread across many sites, having history collected and retained centrally solves a problem that a per-site history module cannot. Instead of each location holding its own separate store that someone must connect to individually, a platform such as Merobix collects the history from all sites into one place, so an engineer can trend any tag from any site, compare sites side by side, and look back over long spans without hopping between systems. The recent, high-resolution view an operator wants during a shift and the longer record an analyst wants for a report are both served from the same central store.
The two ideas also work together rather than in competition. A site running a DCS with its own history module can still forward its history to a cloud platform, which then plays the aggregating, long-retention role that a plant historian plays on-premises. Operators keep the fast local trends the history module gives them, and the wider team gains a consolidated, remotely accessible record across the whole footprint. The principle is the same at every level: a value is only fully useful when its history travels with it.
A history module is part of the DCS, sits at the control layer near the controllers, and is tuned for operator trends with shorter, high-resolution retention. A plant or enterprise historian is a separate, larger system that aggregates data from the DCS and other sources, keeps years of history, and serves reporting and analytics. The history module often feeds the historian rather than replacing it.
There is no fixed figure; retention is a configuration choice sized for operational needs and the available storage. It commonly keeps enough recent history for operators and engineers to investigate events, tune loops, and review a shift or several weeks, with older data rolled off or handed up to a longer-term historian. High-resolution data is usually kept for a shorter span than compressed or aggregated data.
Compression lets the module store the meaningful shape of a value's history without keeping every redundant sample. When a value is steady, storing it many times per minute adds no information, so compression algorithms keep full detail during real movement and thin out flat stretches. This stretches the module's retention window and speeds up trend queries, at the small cost of some precision on unchanging data.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.