Sensor Replacement and Recalibration: Keeping BMS History Comparable

A maintenance team replaces a failed humidity element on a Tuesday. The job is closed, the point reports sensible values again, and everybody moves on. Eight months later somebody notices that a space looks drier than it used to and goes back through the trend, which shows a clear step change in the spring. Nobody can say whether that is a building that changed or an instrument that changed, because the only record of the replacement is a closed work order nobody thought to look at.

The message up front: a point is a channel, and the instrument on the end of it is a separate thing with its own identity and its own lifespan. Record instrument changes as dated events against the point, so that any later analysis can see a discontinuity instead of inferring a trend. Replacement, recalibration and re-siting all break comparability in different ways and all need recording. The mechanism is cheap, it belongs in the maintenance record you already produce, and the one thing it requires is that the maintenance system and the data platform can see each other.

1. The point is not the sensor

This distinction does most of the work. A point is a stable address in the control system, with a name, an identifier and a history. The sensor is a physical device, with a serial number, a calibration state, an installed date and eventually a removal date. Over a building's life one point may carry readings from several instruments.

Most data models collapse the two, holding only the point. That is why a replacement is invisible: nothing in the model has a place to say that the thing generating the numbers is now a different thing. The fix is to treat the instrument as an entity in its own right with an effective-dated relationship to the point, which is the same structural pattern used for the point-to-asset relationship in BMS point-to-asset mapping.

2. Three events, three kinds of discontinuity

Recalibration deserves attention because it is the one case where the historical data can genuinely be repaired. An engineer who records what the instrument read before adjustment and what it read after has given you the offset, and that offset applies backwards to some unknown point in the past. Without those two numbers, all you know is that a step occurred.

3. What to record, and where

The event belongs on the work order, because that is where the engineer already is, and it needs to reach the data platform, because that is where the question gets asked.

• The point affected, by structural identifier rather than name, so the record survives a rename.
• Event type: replacement, recalibration, re-siting, removal, from a controlled list rather than free text.
• Date and time of the change, as precisely as practical. A date alone is usually enough; a timestamp is better where the point samples frequently.
• Instrument out and instrument in: make, model, range and serial where available. A changed range is a changed scaling, which is the subject of sensor units and scaling in BMS analytics.
• As-found and as-left values for any calibration, with the reference used.
• Whether the configuration changed: scaling, range or units altered in the controller at the same time. This is the detail that turns a small step into a large one and is routinely not mentioned.

None of this is new data collection. It is the content of a competently written job record, structured so that something other than a human reader can use it. The connection between the two systems is the same path described in the BMS and CAFM integration reference architecture.

4. Annotating the series

A recorded event is only useful if it reaches the person looking at the chart.

• Mark the event on the trend. A vertical marker at the date, labelled with the event type, turns an unexplained step into a self-explaining one. This is the single most effective presentation change available.
• Warn on comparisons that span an event. Where a report compares two periods and an instrument change sits between them, say so in the output rather than leaving the reader to discover it.
• Carry the event into exports. Data leaving the platform for analysis elsewhere should carry its discontinuities with it, or the caveat is lost at the boundary.
• Do not silently splice. Adjusting historical values to line up across a replacement produces a smooth series that is partly invented. If a correction is applied it goes in its own field with the method recorded, the same discipline as in BACnet data quality flags.

5. Detecting changes nobody recorded

You will inherit years of history with no instrument events in it at all. Some of it can be reconstructed.

• Step detection on long series. A sustained level shift with no corresponding change in the building is a candidate instrument event. It is a candidate, not a conclusion.
• Change in noise character. A series that becomes markedly smoother or noisier at a date often indicates a different instrument rather than different conditions.
• Correlation breaks. Two points that normally track each other and stop doing so at a specific date point at one of them having changed.
• Cross-reference the maintenance history. Candidate dates matched against closed work orders on that asset will explain a good proportion of them, and this is where the exercise usually pays off.
• Record what you find as a reconstructed event, flagged as inferred rather than observed, so nobody later treats a guess as a record.

6. The by-product: evidence-based calibration intervals

Calibration frequencies are usually inherited, round numbers that nobody can justify. Accumulated as-found readings replace that with evidence.

Over several visits, the as-found deviation at each one describes how fast that instrument actually drifts in that location. Instruments that are consistently within tolerance are being over-serviced. Instruments consistently out are being under-serviced, and the interval should shorten. That analysis is only possible if the readings were recorded as values rather than as a pass mark, which is the argument in section 2, and it feeds directly into the programme design discussed in PM KPIs and schedule compliance.

This is also the honest answer to the question of what the recording discipline is for. The data quality benefit is real but diffuse. The maintenance programme benefit is specific and costed, and it is usually what gets the field added to the job.

7. What to require

• Instrument fields on the work order type used for sensor work, mandatory rather than optional.
• As-found and as-left as numeric fields, not free text, so they can be trended.
• A contractual requirement that contractors performing instrument work supply these, which is the usual sticking point and belongs in the terms discussed in BMS service contracts.
• The event reaching the data platform automatically, rather than depending on somebody copying it across.
• An update to the point register, since the instrument is part of what the point dictionary should hold.

The idea to walk away with

A trend line implies one continuous measurement, and in a real building it frequently is not. Separating the point from the instrument, and recording instrument changes as dated events, is what lets the data tell the truth about itself.

The information already exists in your maintenance records. What is missing is structure and a path to the data platform, and the as-found and as-left readings, which cost seconds to capture and are worth more than anything else on the job sheet.

Final thoughts

A quick way to see whether this matters on your estate: pick a point with a long history and a known sensor replacement, and look at the trend across that date without being told where it is. If you cannot spot it, the replacement was clean. If you can, that step has been silently present in every report covering the period.

Then try the reverse: find a step you cannot explain, and look for a work order near that date. The hit rate on that exercise is usually high enough to make the case for recording events properly from now on.

Related reading: BMS point dictionary, BMS point-to-asset mapping, BACnet data quality flags, Sensor units and scaling, BMS points lists and field devices, Condition monitoring techniques.