Learn
A chart shows a line. A record shows the line together with the exact configuration that produced it, frozen at the moment it was recorded.
Every regulated plant already has a way to prove a process ran within limits. Usually it is a chart. Somebody loads the recorder, starts it, watches it, pulls the chart at the end, signs it, and files it. That chart is evidence in the sense that an auditor will accept it, and it is evidence in almost no other sense.
An automatic, immutable record is a different object, and the difference matters more the longer the record has to survive. Digital Process Records in the documentation covers how the feature is configured and read.
A printed and signed chart is a claim, and the claim rests on a chain of human actions that nobody records. Somebody had to remember to load it before the run started. Somebody had to label it with the right batch. Somebody had to file it where it can be found in three years.
Each of those is a place a record goes missing, and they do not fail randomly. They fail on the shifts where people were busiest, which are exactly the shifts an investigation is most likely to ask about. A body of evidence assembled by hand is systematically thinnest where it is needed most.
The chart also cannot answer questions about itself. A reviewer looking at it a year later has to take the signature’s word for what was being measured, in what unit, from which sensor, at what interval. If a probe was swapped in the meantime, the chart does not know.
The run lifecycle is driven entirely by asset state. No operator starts a run and no operator stops one.
Shifting the trigger from a person to the asset changes the shape of the evidence, not just the effort of producing it. The record now exists because the machine ran, so the set of runs on file is the set of runs that happened. Under the paper model those are two different sets, and the gap between them is invisible until somebody goes looking for a specific run and it is not there.
This is also the reason the asset state signal covered in the OEE chapter earns more attention than it usually gets. A machine that does not report a trustworthy state does not produce trustworthy record boundaries.
This is the part that makes a run a compliance record rather than a chart with better graphics.
Each run stores an immutable snapshot of the channel configuration exactly as it stood at run time: the channel names, the units, the tag paths and the sampling rates in force at that moment. Change a channel next month and the runs already recorded do not change with it.
Consider what that removes. Under a configuration that can be edited in place, every historical record silently inherits the current setup, and a reviewer has no way to know whether the settings they are looking at are the settings that produced the readings. Answering that question means digging through change logs, if change logs exist. Freezing the configuration into the run means last month’s evidence describes last month, and it keeps describing last month regardless of what anyone does to the asset afterwards.
A run reviewed a year later still says what it was measuring, in what unit, from which tag path, at what interval. It answers those questions from inside itself, with no dependence on anybody’s memory or on a system that has moved on since.
Opened, a run also gives the minimum, average and maximum for each channel across the run, and an interactive trend chart with a line per channel. The list view carries the Job Order ID where one is linked, which is the join between the physical evidence and the work it belongs to. That link is the one a paper chart depends on a handwritten label for.
A channel is one temperature signal, and it takes four fields: a descriptive Channel Name, unique on the asset; a Unit of Celsius, Fahrenheit or Kelvin, which has to match the unit SCADA is sending; an MQTT Tag Path that is an exact match to the topic carrying the reading; and a Sampling Rate in milliseconds, default 1000, typically between 100 and 5000.
Immutability cuts both ways, and this is where it bites. Because the configuration is frozen into every run, a wrong unit is frozen with it. A run recorded against a mislabelled channel is a permanent record of a mislabelled channel. That is the correct behaviour for a compliance record and it is a strong argument for treating channel setup as a checked step rather than a form somebody fills in quickly.
The sampling rate carries the trade-off worth thinking about before the first run. A lower rate captures more points and consumes more storage per run. That decision is easiest to make deliberately at the start and awkward to revisit once a body of runs exists under the old setting, because the old runs keep the old rate.
A run ended by a fault is kept, with what it captured, marked ABORTED.
Under the paper model that same event produces a chart that stops partway with no explanation on it, and the explanation lives in somebody’s recollection or in a separate log. Here the interruption has a name and a status attached to the evidence itself. Absence is recorded rather than merely present, which is what a reviewer actually needs.
Readings are downsampled to a maximum of 1000 points per chart. That is a display limit only, and the run keeps every reading it captured.
The feature is flagged at organization level by an administrator, requires assets already reporting over MQTT and temperature sensors configured with valid tag paths, and is governed by two permissions: one to configure it, one to read the runs. Whether it is available on a given deployment is a question for the implementation team rather than something to read off a page.
We use cookies to understand how the site is used and to connect form submissions to earlier visits. No analytics or marketing cookies are set until you choose. Privacy Policy