Flow Data Quality: Keep Empty-Pipe Events Separate from Zero Consumption
Updated: 5 hours ago
A daily water report shows a neat period of zero consumption. During the same interval, the flow transmitter recorded an empty-pipe condition. Those two observations do not establish the same thing: one is a numerical value, while the other questions whether the measurement was usable. Before accepting the saving, trace how the fault travelled from the instrument to the report.
The practical answer is to preserve measurement status alongside the flow value and timestamp. Report an interval with unverified measurement conditions as incomplete or invalid under an approved data policy, rather than silently treating it as proven zero use. This guide addresses reporting and integration; it does not prescribe changes to a live control or safety system.
Why the number alone is insufficient
For a conventional full-pipe electromagnetic meter, an empty measuring tube is not a valid zero-flow reference. Endress+Hauser explains that exposed measuring electrodes cannot detect the required measurement voltage; partial filling can also introduce error even while electrodes remain wetted. Its electromagnetic measuring principle guide describes these limitations.
KROHNE's Principles of Electromagnetic Flow Measurement, section 8.6, explains why an empty tube may produce erroneous indications and how empty-pipe functions can suppress outputs and totalisation. The relevant settings and response depend on the instrument. Consequently, an output represented as zero during a diagnostic condition should not automatically become a valid consumption result.
The electromagnetic flow meter shown below is a catalogue example of the field instrument feeding such a data chain. Confirm the exact supplied converter, firmware, diagnostics and output behaviour from its applicable documentation. This photograph does not establish that a particular diagnostic interface is fitted.
Define a data record that carries its meaning
For an integration review, specify more than a flow-rate tag. Retain the engineering units, point identity, observation time, communication freshness and the available device diagnostic state. Document which source establishes each field. Where the interface exposes no relevant diagnostic, record that limitation instead of inventing a healthy status.
If OPC UA forms part of the architecture, its DataValue structure provides a useful concrete example. The OPC Foundation specification associates the value with status and timestamps, and requires clients to check status severity before using the result. A Bad status identifies an unusable value. This does not mean the pictured meter supports OPC UA or that a gateway automatically maps its device diagnostics correctly.
Ask the integrator to distinguish communication success from measurement validity. Successfully reading a numeric register proves that transaction succeeded; the project still needs a documented interpretation of any instrument status supplied separately. Do not mark every transport-successful value as suitable for consumption calculations without that review.
A hypothetical daily-total example
Consider a reporting system that integrates rate samples into volume. For 23 hours it has valid readings at a constant 6 m³/h. For the remaining hour, a diagnostic makes the measurement unusable and the numerical input is represented as zero. The valid intervals contribute 138 m³.
Reporting 138 m³ as the complete day's measured consumption hides the missing evidence. A clearer result is: 138 m³ accounted for during 23 valid hours; one hour invalid; daily total incomplete. Coverage is 23/24, or approximately 95.8%. These figures illustrate reporting logic, not an actual installation or a measurement guarantee.
An approved estimation method might calculate a separate replacement volume, but the estimate needs its own label, assumptions and authorisation. Keeping it separate preserves the distinction between measured and estimated totals. Do not describe an inferred figure as recovered meter data.
Review rate integration and device totals separately
A report derived from sampled rate values has a different evidence path from one using differences between device totaliser readings. Identify which method the report actually uses before diagnosing a discrepancy. Preserve original cumulative readings and any diagnostic history; do not reset the totaliser to make the figures agree.
If the instrument suppresses totalisation during an invalid condition, a later cumulative reading alone cannot prove what volume passed during that interval. Conversely, a communication interruption does not itself prove the instrument stopped measuring. Investigate device behaviour and reporting behaviour separately, then document what the available evidence supports.
Validate the mapping away from the live process
Use an approved test environment or controlled commissioning plan to exercise the reporting chain. Do not drain process pipework, force PLC inputs or disable protection simply to demonstrate a dashboard state. Competent people must assess application-specific control responses and any installation work.
Record the exact instrument and interface documents, units, status mapping and report calculation method.
Test a valid zero value and confirm that it remains distinguishable from an invalid measurement interval.
Test diagnostic and communication-loss cases using the approved simulation method. Check the display, historian, export and final report rather than only the PLC screen.
Confirm that summaries retain invalid-duration or coverage information and that any estimates remain identifiable.
Retain the test observations and configuration revision so the mapping can be checked after later software changes.
Common mistakes include replacing missing values with zero during spreadsheet import, carrying a last value forward without marking it stale, and stripping quality fields from exports. Review the whole path before changing calibration or replacing the meter. The next useful step is an instrument-to-report mapping review with a small set of representative test records.
Need help with your application?
For instruments and product selection, visit ProSense Instruments, email sales@prosenseinstruments.com.au or call 1800 560 854.
For complete monitoring and automation projects, visit ProSense Solutions or email sales@prosense.com.au.
For software enquiries, visit ProSight Software or email info@prosightsoftware.com. Confirm the exact device integration and reporting requirements before selecting an architecture.
Comments