Condition Reading Data Model: Points, Limits and Alarm State

Key takeaways

• A condition reading is comparable to the one before it only when it shares the same measurement point, direction, technique, unit and filter band. Four levels carry that: asset, point, definition, reading.
• The number is worthless without its unit and band. Worked below: one 30.0 Hz component is honestly 4.0 mm/s RMS, 0.077 g RMS and 60.0 micrometres peak to peak.
• Limits belong to the point, not the machine, in versioned sets carrying an author and a date. A limit relative to a baseline travels with the machine, an absolute one does not.
• Alarm state is derived, never typed. Worked below: twelve hourly readings around a 2.8 mm/s threshold raise the state 6 times with no deadband and once with a 10% one.
• Worked below: the same eight readings on pump PMP‑04 put 2 readings in alarm against the old limit set, 4 against the new one and 3 as they were actually judged. The limit set moved the count, not the pump.

The record a condition reading produces

A machine hands you two kinds of number. One says what it has done, the other says what state it is in.

The first is a meter: hours, cycles, kilometres. That record, its rollover arithmetic and its usage based due dates live in the meter reading data model.

A condition reading is its sibling and behaves nothing like it. A meter only climbs and its arithmetic is subtraction, while a condition reading moves both ways and its arithmetic is comparison against a limit.

What this page covers, and what it deliberately does not

We already publish a dozen pages on condition monitoring as a subject: what vibration analysis senses, what a vibration spectrum shows, how continuous sensing differs from periodic inspection, and what the ISO 20816 severity zones mean.

Not one of them specifies the record. This page does only that: the measurement point, the measurement definition, the reading, the limit set and the derived alarm state.

Four levels, and why they are not one

Most plants that struggle with condition data have collapsed these four into two: a machine, and a pile of numbers attached to it.

That model cannot answer the only question that matters, which is whether today's number and last month's describe the same thing.

Hang the point off the same tree as your work orders and failures (see the asset hierarchy data model). The middle two levels are the ones plants skip, and skipping them is the single most common defect in real condition data.

Why a reading without a fixed point is not a reading

Vibration amplitude on a bearing housing changes with where the sensor sits and which way it faces. Move a handheld probe eighty millimetres along the same housing and the overall velocity can shift by a third.

So a trend built from readings taken wherever the technician could reach is not a trend. It is a record of where people stood.

A fixed point needs three things: a permanent mark on the machine, a recorded direction, and a mounting that repeats. A stud or a glued pad repeats, a hand held probe on a curved surface does not.

The measurement point record

A point is a physical location, not a label on a report. It outlives sensors, technicians and software.

Four of these carry the weight.

Never move a point. If the pad falls off and is refitted somewhere else, close the old point with superseded_by and open a new one.

The measurement definition record

The definition says what is measured at a point, by what technique, in what unit and how often. One point can carry several definitions, and they are not interchangeable.

detection is the field nobody remembers and everybody needs. RMS, true peak and peak to peak of one signal are three different numbers, and a sheet that mixes them shows a machine going bad.

Units and technique matter more than the number

The same physical motion has several correct numbers, and they are not versions of each other.

One motion, three honest numbers

Pump PMP‑04 runs at 1,800 rpm, so its first order component sits at 30.0 Hz. Say that component measures 4.0 mm/s RMS.

Acceleration is velocity times 2 times pi times frequency, and displacement is velocity divided by the same quantity.

Check the first two: 4.0 times 2 times pi times 30.0 gives 754.0 mm per second squared, and 754.0 divided by 9,810 is 0.077 g.

The displacement is 4.0 times 1,000 divided by 188.50, which is 21.2 micrometres RMS, and multiplying by 2 times the square root of 2 gives 60.0 micrometres peak to peak.

Now the punchline. The same 4.0 mm/s at 3,000 Hz instead of 30.0 Hz is 7.69 g, exactly 100 times the acceleration, because the frequency ratio is 100.

In displacement that same component is 0.60 micrometres peak to peak, which no displacement probe on that machine would resolve. Each quantity goes blind at a different end of the spectrum, which is why bearing defects are hunted in acceleration and unbalance in velocity (see bearing defect frequencies).

The filter band is a number in its own right

Fan FAN‑11 has one accelerometer on point MP‑7B, and two definitions reading it in the same minute.

Definition A filters 10 to 1,000 Hz and returns 4.8 mm/s RMS. Definition B filters 2 to 1,000 Hz and returns 6.0 mm/s RMS.

Nothing mechanical differs. A structural component at 6 Hz worth 3.6 mm/s RMS is inside B and outside A.

RMS values combine in quadrature, so the check is the square root of 4.8 squared plus 3.6 squared, which is the square root of 23.04 plus 12.96, which is the square root of 36.00, which is 6.0.

The two readings differ by 25.0% from a filter setting. Put them in one column of one trend and you have manufactured a fault.

Codes and decibels are not quantities

An ISO 4406 oil cleanliness code such as 18/16/13 is three ordinal codes, not three measurements. Each step up is roughly a doubling of the particle count in that size band, so 19/17/14 is not one worse, it is about twice as dirty at every size.

The same holds for airborne ultrasound in decibels, which is logarithmic and relative to an instrument reference. A rise from 28 dB to 40 dB is about four times the amplitude, and a number from a different reference cannot be subtracted from it at all.

Temperature has a quieter version. A bearing housing at 65 °C is a 45 kelvin rise in a 20 °C hall and a 25 kelvin rise in a 40 °C one, so thermography readings need the ambient stored beside them.

The fields that make an accidental comparison impossible

The defence is a derived comparison key: two readings may be trended together only when every part of it matches exactly.

Compute the key when the reading is written, store it on the row, and refuse to chart two different keys on one axis.

The reading record

One row per value, written once, corrected only by a later row that supersedes it. These columns are the minimum for defending a number two years later.

unit is copied onto the reading, not looked up from the definition later. If somebody edits the definition in 2028, every stored row still says what it meant in 2026.

machine_state keeps out the worst kind of false alarm. A reading taken while the pump ran on recirculation is not wrong, it simply answers a different question.

reading_purpose separates a route reading from a verification reading, a post repair check and an acceptance test. Only route readings belong in the trend, and all four belong in the history.

sensor_id is what answers, later, whether a step change came from the machine or the kit. Without it a swap and a developing fault look identical.

Limits are per point, not per machine

This is where most implementations go wrong, and the wrongness is invisible for about a year.

A limit stored on a machine record averages several very different points. The motor non drive end and the pump drive end on one skid routinely differ by a factor of two in normal health.

set_by, set_at and reason are not bureaucracy. A limit with no author is a limit nobody dares change, which is how a plant ends up ignoring one alarm for three years.

direction matters more than it looks. Vibration and temperature alarm when they rise, oil level and flow alarm when they fall, and one hard coded comparison operator gets half of them wrong.

Absolute, relative and statistical

A limit set has a basis, and the three bases answer three different questions.

An absolute limit says whether the machine is acceptable against the outside world. The zone boundaries in ISO 10816-3 and its successor are the usual source, read from the machine's power and support class.

A relative limit says whether this machine has changed, and it is the one that catches a fault early.

Take sister pump PMP‑05, baseline 1.2 mm/s, now reading 1.9 mm/s. Against an absolute alert of 2.8 mm/s it is quiet, sitting at 67.9% of the threshold.

Against a relative alert of 1.5 times its own baseline, which is 1.8 mm/s, it is already in alert. It has risen 58.3% above its own normal, and that is the signal.

So run both, and store baseline_at beside the baseline. One captured before a 2023 overhaul describes a machine that no longer exists.

Alarm state is derived, never typed by a person

If a human can set a reading to normal, the field is an opinion and your alarm counts record who was on shift.

The derivation is short and belongs in the specification in exactly this order.

Step 2 is the one that saves your history. Stamping the set and its version on the reading means a limit change in June cannot silently rewrite what May looked like.

The oscillation problem

A value sitting near a threshold is the commonest source of alarm noise in a monitored plant. It is not a fault, it is arithmetic.

Compressor CMP‑02 has a fixed sensor on point MP‑5H with an alert at 2.8 mm/s. Twelve consecutive hourly readings run 2.74, 2.83, 2.77, 2.86, 2.75, 2.81, 2.79, 2.88, 2.76, 2.84, 2.78 and 2.90.

Six of the twelve sit at or above 2.80, and every one of them follows a reading below it. A naive comparison makes that six separate alarm raises in twelve hours.

With deadband_pct at 10 the state is raised at 2.80 and cleared only below 2.80 times 0.90, which is 2.52 mm/s. No reading goes that low, so the state is raised once and stays raised.

Six notifications become one, a reduction of 83.3%, and the underlying data is untouched.

The consecutive rule does a different job and would be wrong here. No two adjacent readings are above 2.80, so it produces 0 raises and hides a point sitting on its limit.

Worked example: one pump, eight months, one limit change

Pump PMP‑04, point MP‑3A, drive end bearing, axial, stud mounted, overall velocity in mm/s RMS filtered 10 to 1,000 Hz. Read on a monthly route.

1. The series

Ten rows, of which eight are route readings and two are the verification pair taken when accelerometer SEN‑2291 was replaced by SEN‑2347.

That pair carries reading_purpose of verification, so it is stored, visible and excluded from the trend arithmetic.

2. Proving the sensor swap was not the step

The swap happened on 2026-05-18 and the next route reading jumped 1.2 mm/s. Without the verification pair that jump has two equally plausible explanations.

The pair settles it: 2.5 with the old sensor and 2.6 with the new one at the same point in the same hour, a difference of 0.1 mm/s, which is 4.0% of 2.5.

That is inside normal repeatability for a stud mounted overall reading, so the scale did not move. The 1.2 mm/s that arrived four weeks later is the machine.

3. Reconciling the series

Two routes to the same total, which is how you catch a dropped row.

The seven changes are 0.1, 0.2, 0.3, 1.2, 0.5, 0.5 and 0.5, and they add to 3.3. So delta_vs_baseline is 3.3 mm/s and the point sits at 2.83 times its own baseline.

The last three intervals are the useful rate: 3.6 to 5.1 is 1.5 mm/s across three months, or 0.50 mm/s a month.

At that rate the gap from 5.1 to the 7.1 mm/s boundary is 2.0 mm/s, which is 4.0 months, landing on 2027-01-12. That is a straight line projection, not a forecast.

4. The limit change in the middle

Until 2026-06-20 the point carried limit set LS‑118: alert 4.5 mm/s, danger 7.1 mm/s, taken from the boundaries for a large machine on a rigid support.

On 2026-06-20 a reliability engineer found the classification wrong. PMP‑04 is a 45 kW pump, which is the medium machine class, so LS‑204 replaced it with alert 2.8 mm/s and danger 4.5 mm/s.

LS‑118 was closed with effective_to of 2026-06-20 and a reason. LS‑204 opened with effective_from of the same instant, a version of 1, and the engineer in set_by.

5. The same readings, three alarm counts

Now judge the eight route readings three ways and watch the count move without one value changing.

Against LS‑118 alone only 4.6 and 5.1 reach the 4.5 alert, so 2 readings are in alarm and the first is 2026-08-12.

Against LS‑204 alone, 3.6 and 4.1 are alerts and 4.6 and 5.1 are dangers, so 4 readings are in alarm and the first is 2026-06-12.

As they were actually judged, the five up to 2026-06-12 fell under LS‑118 and were normal, and 4.1, 4.6 and 5.1 fell under LS‑204. That is 3 in alarm, first on 2026-07-12.

The three first alarm dates span 61 days, from 2026-06-12 to 2026-08-12, on an identical set of numbers.

6. Which reading of history is correct

The third one, 3, is the only defensible answer to the question people actually ask, which is what the plant knew at the time.

The other two answer different questions. The 4 is a hindsight exercise, the 2 is what the old export said, and that is why the two reports disagree.

All three are computable only because limit_set_id and limit_set_version were stamped on every reading at evaluation time.

One thing the record must not do is decide. The reading says the machine has moved, and a person opens the work order against the asset with the reading attached (see the CMMS data model).

Five questions to ask a vendor about condition data

Ask for a demonstration in the product, not an answer in a slide.

1. Show me two points on one bearing. Create a horizontal and an axial point on one housing with different limits, and show that a reading cannot be filed against the wrong one.
2. Change a limit and rerun last quarter. Tighten a threshold, then show the alarm count for the previous quarter before and after. If it changes, the limit set is not stamped on the readings.
3. Put two units on one chart. Try to trend a velocity reading and an acceleration reading together. The product should refuse, not convert.
4. Swap a sensor in front of me. Record a verification pair with two sensor identifiers, and show both rows kept and excluded from the trend.
5. Export twelve months of one point. Ask for value, unit, detection, filter band, sensor, machine state, limit set and version as columns. A field that will not export is not really stored.

Before you shortlist, read what a CMMS is and equipment maintenance software, then the records either side of this one: the inspection result data model and the equipment failure record data model.

How Fabrico helps

Everything above is a specification to test a shortlist against, not one product's feature list. Fabrico covers part of it, so here is the split.

Fabrico is an OEE platform with a full CMMS built in. On the machine side it has PLC connectivity, IoT sensors and computer vision, with real-time OEE, downtime and micro-stop detection built on them (see machine monitoring system).

On the maintenance side: recurring templates, conditional tasks, an annual PM plan, approvals, work shifts and QR codes, in iOS, Android and web apps. Notifications with smart rules, an audit log, analytics with Excel export, a REST API, webhooks and SAP and ERP connectors are all there.

What Fabrico does not do: it does not perform vibration, spectrum, oil or thermography analysis, it does not hold alarm limit sets, and it does not judge a condition reading against a threshold.

Failure forecasting is on the roadmap and is not a standard feature, so treat condition triggered maintenance as something you specify elsewhere and act on here.

What it does give you is the other half: machine data arriving from the sensors and controllers you already have, a CMMS your team acts in, and an AI assistant that answers questions about one machine's history in plain language.

Work orders are raised and confirmed by your team, never by the system on its own, whatever the reading says.

Want your machine data, plans and work orders in one place? Book a 30 minute demo with a Fabrico consultant, no commitment, or contact us with your questions.

For the wider subject, our guides to condition based maintenance and the preventive maintenance plan data model pick up where this record stops.