Ask for the history of a particular chiller and you will usually get two answers from two systems. The maintenance system gives you work orders, costs and parts. The BMS or the historian gives you alarms and trends. Both are about the same machine, neither references the other, and the question that actually matters, whether this asset is getting worse, cannot be answered from either alone because the pattern lives in the relationship between them.
The message up front: the join is an asset event record that both sides write to, keyed on the asset and ordered by time. Write detected faults into it as first-class events rather than only as work order descriptions, record what happened to each one including the ones that led nowhere, keep the event ordering reliable, and resist computing reliability statistics from alarm counts, because an alarm count measures detection and configuration as much as it measures the asset.
1. Why the two records drift apart
The separation is not an oversight. It is what happens when each system is implemented well for its own purpose.
- Different keys. The BMS organises by point and device; the maintenance system organises by asset and location. Nothing joins them unless somebody built the mapping, which is the work in point-to-asset mapping.
- Different granularity. An alarm is an occurrence lasting minutes; a work order is a piece of work lasting days. One work order can cover many alarms, and one alarm can produce none.
- Different lifetimes. Alarm history is bounded by whatever the head end retains; work order history is kept for years. The overlap window is often shorter than anybody assumes.
- Different owners. One record is maintained by controls, the other by maintenance, and neither has a reason to reference the other unless reliability analysis is somebody's job.
The consequence is specific. A technician opening an asset record sees the work that was done and not the conditions that were detected, so a job that is the fourth response to the same developing condition looks like the first.
2. The asset event record
What closes the gap is a single chronological record per asset that both sides write into. It is a modest structure and the discipline is in using it consistently.
| Field | Holds | Why it matters |
|---|---|---|
| Asset reference | The asset, at the level the hierarchy supports | The key everything groups by, per asset hierarchy design |
| Event time | When the thing happened, not when it was recorded | Ordering is the whole value of the record, so the distinction matters |
| Event kind | Detected fault, work order raised, attended, part replaced, inspection, configuration change | Lets one record hold both sides without ambiguity |
| Source identity | Point and device for detected events, work order number for maintenance events | Traceability back to the originating system |
| Disposition | What the event led to, including nothing | The field most often omitted and most often needed |
| Case reference | Grouping of related events | Ties recurrence together, as in repeated faults as one case |
Record the events that led nowhere
The strongest temptation in this design is to write only the detected faults that produced work. It is understandable, because the others feel like noise, and it destroys most of the record's value. A condition that appeared five times, cleared on its own each time, and was never attended is one of the most informative patterns an asset history can contain, and it is exactly the pattern that disappears if only actioned events are written. It is also the pattern behind the awkward case in faults that clear before a technician arrives. Write everything detected, with a disposition that says what happened, and let the reader decide what is noise.
3. Getting the level right
A detected fault arrives attached to a point, and the point is almost always at a finer level than the asset anybody wants history for. Attaching the event at the wrong level makes the record unreadable in one of two ways.
Attach too low and the history fragments. Events land on sub-components that nobody looks at, and the parent asset shows nothing, which is the most common failure because it is what a literal mapping produces.
Attach too high and the history floods. Every event from every point in a large plant room lands on one asset, and the record becomes a stream nobody reads.
The workable answer is to attach the event at the level the point genuinely describes, and to read history by rolling up the hierarchy rather than by writing up it. That keeps the record precise and still lets somebody ask for everything beneath an asset, which also means the roll-up follows whatever the hierarchy says today rather than freezing a decision made at integration time.
4. Keeping the ordering trustworthy
An event record whose order cannot be trusted is worse than none, because the sequence is what people reason from.
- Separate event time from recorded time and store both. A fault detected during an outage and delivered hours later must sort by when it happened, which is the behaviour described in late and out-of-order readings.
- Hold event times in a single reference, with the offset recorded. A multi-site estate comparing sequences across time zones needs this, and the mechanics are in timestamps and clock sync.
- Be explicit about clock reliability. If a controller's clock is known to be unsynchronised, events from it should carry that caveat rather than appearing with false precision.
- Make the record append-only. Corrections are new events referencing the old, not edits, which is the same reasoning as the audit trail in the alert audit trail.
5. What the joined record lets you see
The payoff is in questions that neither system answers alone, and they are ordinary operational questions rather than analytical exotica.
- Is this a first occurrence? The single most useful thing to show a technician on arrival, and currently the hardest to answer because the evidence is in a system they do not open.
- Did the last intervention work? Visible immediately as whether detected faults stopped after the work order closed, and invisible otherwise.
- Is the interval between occurrences shortening? A pattern question that needs both the detections and the interventions on one timeline.
- Which assets consume disproportionate attention? Including the attention that produced no work order, which is attention that currently appears nowhere in any cost figure.
- Was the recent change followed by anything? Configuration changes and sensor replacements in the same record make this answerable, which is the argument in sensor replacement and BMS history.
6. Where to stop short of statistics
There is a strong pull from here towards computing reliability measures directly from detected-fault counts. It is worth resisting, or at least qualifying heavily, for reasons that are about the data rather than about the mathematics.
An alarm count is a function of three things: the behaviour of the asset, the configuration of the alarms, and the health of the collection path. A quiet asset and an asset whose alarm was disabled last year look identical. An asset on a deteriorating network link looks like an asset in trouble. A limit tightened during a troubleshooting exercise and never relaxed produces a step change in fault frequency with no change in the plant at all.
What the joined record supports well is counting intervention events, which are human acts with a known provenance, and using detected faults as context rather than as the measure. If detected faults are to feed a reliability figure, the figure needs the configuration history and the collection completeness alongside it, from data completeness KPIs, and it needs a caveat that stays attached. Interval-based measures such as those discussed in MTBF depend on a consistent definition of what counts as a failure, and a detected alarm is not automatically one.
Limits
Nothing here asserts that any pattern of detected faults indicates a particular equipment condition, developing failure or remaining life. A shortening interval between occurrences is a reason to have somebody qualified look at the plant, not a diagnosis, and interpreting it is engineering work requiring validation against the equipment in question. Section six sets out why fault counts are unsafe as a reliability input without the configuration and collection history beside them. No thresholds, intervals or counts are given, because they would be read as meaningful independent of context. This is written from the data and systems side, which is where my experience lies.
The idea to walk away with
Detected faults and maintenance work are two accounts of one asset's life, and the questions people actually ask live in the relationship between them rather than in either.
Build one chronological event record per asset that both sides write to, include the detections that led nowhere, attach events at the level the point describes and roll up to read, keep event time separate from recorded time, and treat fault counts as context rather than as a reliability measure.
Final thoughts
Pick the asset that generated the most work last year and try to assemble its timeline by hand: every detected fault and every work order, in order, on one page.
How long that takes is the measure of the gap. If it is quick, you already have the join and should put it in front of technicians. If it takes an afternoon and two systems, that afternoon is also the business case, and the asset you chose is probably the one where the answer changes a decision.
Disclosure
Alongside advisory work I also build a CMMS and CAFM platform, so I have a commercial interest in this category. Nothing above is a recommendation for it, and no vendor named here has paid for inclusion or had any editorial input. Weigh the analysis accordingly.
Asset history in two systems?
Independent help building an asset event record that holds detected faults and maintenance work on one timeline, at a level people can read. 22+ years across CMMS, CAFM, EAM and ERP implementations.
Book a conversationRelated reading: Point-to-asset mapping, Repeated faults as one case, Alarm codes to fault categories, Sensor replacement and history, Asset hierarchy design, Point naming and cross-system joins.
Muhammad Abbas
CMMS / CAFM Manager & Independent Advisor · 22+ years across enterprise CMMS, EAM, CAFM and ERP implementations in utilities, oil and gas, manufacturing, government and facility operations.
Work with me