A flow computer's quantity records tell you how much flowed, but they say nothing about how the number was produced or whether anyone changed the setup underneath it. That is the job of two other logs it keeps: the configuration log, which captures the constants and parameters the calculation depends on, and the event log, which timestamps every change and alarm. This page explains what these logs contain, why a single edited constant can shift every volume, why auditors insist on them, and how a SCADA system polls, versions, and retains them.
Flow Computer Config & Event Log in one line: A flow computer's configuration log records the constants and parameters it uses to calculate volume, such as meter geometry, gas or liquid properties, and input ranges, while its event log timestamps every change to those parameters and every alarm. Together they form the tamper-evident audit trail that lets an auditor see exactly how a volume was computed and whether anything was altered, separate from the quantity records that store the volumes themselves.
A flow computer maintains several kinds of records, and it helps to separate them. The quantity records, the hourly and daily volumes, are the measured output. The configuration and event logs are different: they document the machine's setup and its history rather than its results. The configuration log holds the constants and parameters that drive the flow calculation, things like the meter's physical dimensions, the properties of the gas or liquid, the ranges assigned to the inputs, and the equation selections. It is, in effect, a snapshot of how the device is set to turn raw inputs into a volume.
The event log is the running history of what happened to that setup and to the device. It timestamps every change to a configuration parameter, recording that a constant was altered, when it happened, and ideally who did it and what the old and new values were. It also captures alarms and significant operating events, so that a power loss, an input going out of range, or a diagnostic condition is recorded with its time. Where the configuration log says how the device is set now, the event log says how it got there and what has occurred along the way.
The reason these are kept apart from the quantity records is that the volume alone is not self-explaining. Two identical volume figures could have been produced under completely different configurations, and a volume that looks fine could be wrong because a constant was mis-entered. The configuration and event logs supply the context the bare quantity number lacks, which is exactly why they are treated as first-class records rather than incidental device housekeeping.
A flow computer's output is highly sensitive to its constants, so a single wrong parameter can bias every volume it produces. If the entered meter geometry, a gas property, or an input range is off, the calculation applies that error consistently, and the meter can report clean, plausible-looking volumes that are all systematically wrong. Because the error is in the setup rather than the measurement, nothing about the quantity records themselves reveals it; the numbers look normal while being incorrect throughout the period the bad constant was in place.
This is precisely why the event log's timestamping of constant changes is so valuable. When an error is later found, the event log shows when the offending constant was changed and to what, which lets an analyst determine exactly which intervals were affected and by how much. That timeline is what turns a vague suspicion that volumes were wrong into a bounded, correctable problem, and it is often the basis for a prior period adjustment that restates the affected span. Without the log, the extent of the error would be a matter of guesswork.
The logs are also tamper evidence. Because every change to a constant is recorded with its time and, where supported, its author and old and new values, the configuration cannot be quietly altered without leaving a trace. This is central to trust in custody measurement, where a counterparty has to believe the setup was not manipulated to favor one side. The event log makes the configuration's history transparent, so a legitimate change and an improper one both show up, and the difference can be examined.
Like the quantity records, the configuration and event logs live in the flow computer's finite memory and will eventually be overwritten, so they have to be collected and kept elsewhere to be useful over time. A SCADA and EFM system polls each flow computer to retrieve these logs on a schedule, capturing new events and the current configuration before old entries roll off. A cloud platform such as Merobix can gather them from many meters into central storage, so the setup history and event record of an entire system are retained together rather than trapped on individual devices in the field.
Central collection lets the platform version the configuration over time, keeping successive snapshots so an analyst can see what the device was set to during any past period, not just how it is set today. Paired with the timestamped event log, this gives a reconstructable history: for any interval, the operator can show the configuration in effect and the events that touched it. That is what allows a volume to be defended or a past error to be pinpointed, because the state of the device at the relevant time is a matter of retained record rather than of memory.
The logs also feed live oversight, not just after-the-fact audits. Because the SCADA system sees configuration changes and alarms as it polls, a measurement team can be alerted when a constant is edited or an alarm fires at a remote site, and review whether the change was expected. This turns the configuration and event logs from passive compliance artifacts into an active monitoring signal, letting an operator catch an unplanned edit or a developing fault early. Complementing the quantity records rather than duplicating them, these logs are what make an electronic measurement point both auditable and watchable from the office.
A configuration log records the constants and parameters a flow computer uses to calculate volume, such as meter geometry, fluid properties, and input ranges, which is essentially a snapshot of how the device is set up. An event log timestamps every change to those parameters and every alarm, recording when something was altered and what happened. The configuration log says how the device is set, and the event log says how it got there and what has occurred.
The flow calculation applies its constants consistently, so a single wrong parameter, such as a mis-entered meter dimension or fluid property, biases every volume produced while it is in place. The quantity records still look plausible because the error is in the setup, not the measurement. The event log's timestamp of when the constant changed is what lets an analyst identify exactly which intervals were affected and correct them.
The volume figure alone does not show how it was produced or whether the setup was altered, so auditors need the configuration log to see how the calculation was set and the event log to see every change and alarm. Because each constant change is timestamped and traceable, the logs act as tamper evidence, letting an auditor confirm the setup was not quietly manipulated. They provide the context and integrity assurance the bare quantity records lack.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.