From Manual Reading to Digital Asset History

Why this lesson matters

You have accepted that the walk stays and the record has to change. This lesson is the practical build: what an asset history is made of, how to structure it, and how to get one running on a real site without a six month data project.

The two object model

Almost everything useful reduces to two things.

The asset. A physical instrument or the thing it measures. It is long lived, it has properties, and it changes rarely. This is your register.

The reading. An observation of that asset at a moment in time. It is short lived, it is created constantly, and it should never be edited in place.

Keeping these separate is the whole trick. Sites that merge them, which is what a spreadsheet does, end up with asset properties repeated on every row and no reliable way to correct one without corrupting the other.

The asset register

A workable minimum for each instrument:

Field	Why it matters
Tag	Permanent key. Physically fixed to the instrument and legible.
Site and location	Where the reader has to stand. Include the route order.
Measured quantity	Pressure, volume, energy, temperature, flow, run hours.
Unit	Explicit and singular. Never "m3 or kWh".
Multiplier	Register gearing, x1, x10, x100.
Reading type	Cumulative register or instantaneous value. Drives every calculation.
Full scale and resolution	Defines honest precision and sane exception limits.
Expected operating range	Low and high bound for exception detection. Covered in a later lesson.
Reading frequency	The schedule that defines whether a reading is missing.
Verification or calibration date	Quality flag on everything the instrument produces.
Parent asset or system	Boiler, chiller, compressor, main incomer. Enables roll up.

Two fields deserve emphasis because they cause the most downstream damage when omitted: reading type and multiplier. Cumulative and instantaneous values require opposite treatment, and an ungeared reading of a x10 register is wrong by an order of magnitude in a way that looks entirely plausible.

The reading event

Each reading records:

• asset tag
• value as read
• unit
• capture timestamp, system generated
• captured by
• capture method (manual entry, photo assisted, automated)
• source image reference
• notes
• quality flag (verified, estimated, unreadable, suspect)

And critically: readings are append only. A wrong value is not overwritten. It is superseded by an adjustment that records the original value, the revised value, who changed it, when and why. This is the difference between a record and a working file, and it is what makes the data defensible when someone challenges a number two years later.

Handling meter exchange and rollover

Two events break naive cumulative arithmetic. Plan for both from day one.

Rollover. A six digit mechanical register passes 999999 and returns to 000000. The delta between consecutive readings is large and negative. The correct consumption is:

consumption = (10^digits - previous_index) + current_index

You need the digit count in the asset record to do this, which is one more reason the register properties belong there.

Meter exchange. When an instrument is replaced, record the closing index of the old meter and the opening index of the new one, both with the changeover date and both photographed. The consumption series then continues across the boundary. Without this, either you lose a period or you record an enormous phantom consumption or an enormous phantom credit.

Building the trend

Once you have clean events, the derived values are straightforward:

• Consumption over a period for cumulative assets: difference of the bounding indices, rollover adjusted, normalised to the actual elapsed time rather than the nominal period.
• Rate: consumption divided by elapsed hours or days. Always normalise, because a "weekly" reading is rarely exactly seven days apart and comparing un normalised periods creates fictional variation.
• Drift for instantaneous assets: the trend of the value itself, plus the trend of its variance. A pressure that is stable at a new level and a pressure that is oscillating are different conditions.
• Baseline: the overnight or non production minimum. On most sites this is the single most diagnostic derived figure available, because it reveals continuous consumption that should not exist.

Coverage: the metric that keeps the system honest

A trend built from an unknown number of missing readings is not trustworthy. Define coverage explicitly:

reading coverage = readings received / readings expected

Expected comes from the asset's reading frequency and the reporting period. Stating the denominator matters. "48 of 52 weekly readings, 92 percent coverage" is a defensible statement. "We monitor the gas meter" is not.

Track coverage per asset, per site and per period. A falling coverage figure is an early warning that a route is being skipped, that an instrument has become inaccessible, or that a reader has left.

A realistic rollout sequence

1. Pick one round. Not the whole site. One route, one reader, twenty to forty instruments.
2. Tag the instruments physically. Durable labels, legible, positioned so they can be photographed with the register.
3. Build the asset register for that round only, with the fields above complete.
4. Set the schedule to match the round you already run. Do not increase frequency at the same time as changing the process.
5. Capture at the instrument, with a photograph, from day one. Retrofitting evidence later is not possible.
6. Run parallel with the sheet for one cycle, then stop the sheet deliberately.
7. Review at four weeks: coverage, obvious data quality flags, any exceptions raised, and whether the reader finds the process faster or slower than the clipboard. Fix the process before extending.
8. Extend to the next round.

Expect the first month to surface asset register errors rather than plant problems. That is normal and it is the register doing its job.

What you can do at three months that you cannot do today

• Produce the twelve month series for any single instrument in seconds, with source images attached.
• State consumption for a period with an explicit coverage figure behind it.
• See overnight baseline and detect continuous loads that should be off.
• Detect an out of range value at the moment of capture instead of at quarterly review.
• Show who read what, when, and from which instrument.
• Hand a reporting request to somebody else and have them complete it without interviewing the operator.

Common mistakes at this stage

• Starting with the whole site. Register quality collapses and nobody trusts the output.
• Allowing free text asset names anywhere in the capture path.
• Editing readings in place. Once you do this the history becomes an opinion.
• Omitting the reading schedule, which makes "missing" undefinable and coverage uncomputable.
• Increasing reading frequency during the transition. Change one variable at a time.
• Importing legacy rows without a quality flag, so unverified history becomes indistinguishable from evidenced readings.