Key takeaways
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.
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.
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.
| Level | What it is |
|---|---|
| Asset | The pump, fan or gearbox that fails |
| Point | A named physical place and direction on it |
| Definition | What is measured there, how, how often |
| Reading | One value at one moment, kept forever |
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.
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.
A point is a physical location, not a label on a report. It outlives sensors, technicians and software.
| Field | Type | Req. |
|---|---|---|
| point_ | key | Yes |
| asset_ | ref | Yes |
| point_ | text | Yes |
| component | enum | Yes |
| axis | enum | Yes |
| position_ | text | Yes |
| mounting | enum | Yes |
| mount_ | text | No |
| speed_ | enum | Yes |
| access_ | enum | Yes |
| route_ | ref | No |
| photo_ | ref | No |
| is_ | bool | Yes |
| superseded_ | ref | No |
Four of these carry the weight.
| Field | Why it exists |
|---|---|
| axis | Horizontal, vertical and axial are three different points |
| mounting | A magnet and a stud do not read the same above 1 kHz |
| position_ | Lets a new technician stand where the last one stood |
| speed_ | A pump at half flow is a different machine |
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 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.
| Field | Type | Req. |
|---|---|---|
| definition_ | key | Yes |
| point_ | ref | Yes |
| technique | enum | Yes |
| quantity | enum | Yes |
| unit | enum | Yes |
| detection | enum | Yes |
| filter_ | num | Cond. |
| filter_ | num | Cond. |
| averages | int | No |
| interval_ | int | Yes |
| tolerance_ | int | Yes |
| decimals | int | Yes |
| baseline_ | num | No |
| baseline_ | ts | No |
| limit_ | ref | Yes |
| is_ | bool | Yes |
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.
The same physical motion has several correct numbers, and they are not versions of each other.
| Technique | Unit | Senses |
|---|---|---|
| Overall velocity | mm/s RMS | Unbalance, misalignment, looseness |
| Overall acceleration | g RMS | Bearing and gear defects |
| Shaft displacement | µm p-p | Journal bearing clearance |
| Temperature | °C | Friction, lubrication, load |
| Oil cleanliness | ISO 4406 code | Particles per mL |
| Ultrasound | dB | Leaks, friction, early wear |
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.
| Read as | Value |
|---|---|
| Velocity RMS | 4.0 mm/s |
| Acceleration RMS | 0.077 g |
| Displacement p-p | 60.0 µm |
| Same 4.0 mm/s at 3,000 Hz | 7.69 g |
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).
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.
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 defence is a derived comparison key: two readings may be trended together only when every part of it matches exactly.
| Part | Example |
|---|---|
| point_ | MP-3A |
| quantity | Velocity |
| unit | mm/s |
| detection | RMS |
| filter_ | 10 |
| filter_ | 1,000 |
| mounting | Stud |
| speed_ | Nominal |
Compute the key when the reading is written, store it on the row, and refuse to chart two different keys on one axis.
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.
| Field | Type | Req. |
|---|---|---|
| reading_ | key | Yes |
| definition_ | ref | Yes |
| reading_ | num | Yes |
| unit | enum | Yes |
| reading_ | ts | Yes |
| recorded_ | ts | Yes |
| recorded_ | ref | Yes |
| sensor_ | ref | Yes |
| entry_ | enum | Yes |
| reading_ | enum | Yes |
| machine_ | enum | Yes |
| speed_ | num | No |
| load_ | num | No |
| ambient_ | num | Cond. |
| limit_ | ref | Yes |
| limit_ | int | Yes |
| alarm_ | enum | Derived |
| delta_ | num | Derived |
| status | enum | Yes |
| supersedes_ | ref | No |
| note | text | No |
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.
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.
| Field | Type | Req. |
|---|---|---|
| limit_ | key | Yes |
| point_ | ref | Yes |
| definition_ | ref | Yes |
| version | int | Yes |
| basis | enum | Yes |
| direction | enum | Yes |
| alert_ | num | Yes |
| danger_ | num | Yes |
| zone_ | num | No |
| zone_ | num | No |
| zone_ | num | No |
| deadband_ | num | Yes |
| consecutive_ | int | Yes |
| source | enum | Yes |
| standard_ | text | No |
| set_ | ref | Yes |
| set_ | ts | Yes |
| effective_ | ts | Yes |
| effective_ | ts | No |
| approved_ | ref | No |
| reason | text | Yes |
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.
A limit set has a basis, and the three bases answer three different questions.
| Basis | Comes from |
|---|---|
| Absolute | A standard or the maker's number |
| Relative | A multiple of this point's baseline |
| Statistical | Spread of this point's own history |
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.
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 | Rule |
|---|---|
| 1 | Find the set whose effective period covers reading_ |
| 2 | Stamp limit_ |
| 3 | Compare by direction, not by a fixed operator |
| 4 | Danger first, then alert, then normal |
| 5 | Apply deadband_ |
| 6 | Apply consecutive_ |
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.
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.
| Rule | Raises in 12 h |
|---|---|
| No deadband | 6 |
| Deadband 10%, clear below 2.52 | 1 |
| Two consecutive above 2.80 | 0 |
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.
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.
| Date | mm/s | Change |
|---|---|---|
| 2026-02-12 | 1.8 | baseline |
| 2026-03-12 | 1.9 | +0.1 |
| 2026-04-12 | 2.1 | +0.2 |
| 2026-05-12 | 2.4 | +0.3 |
| 2026-05-18 | 2.5 | old sensor |
| 2026-05-18 | 2.6 | new sensor |
| 2026-06-12 | 3.6 | +1.2 |
| 2026-07-12 | 4.1 | +0.5 |
| 2026-08-12 | 4.6 | +0.5 |
| 2026-09-12 | 5.1 | +0.5 |
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.
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.
Two routes to the same total, which is how you catch a dropped row.
| Check | mm/s |
|---|---|
| First route reading | 1.8 |
| Sum of the seven changes | 3.3 |
| First plus the sum | 5.1 |
| Last route reading | 5.1 |
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.
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.
Now judge the eight route readings three ways and watch the count move without one value changing.
| Judged against | In alarm | First |
|---|---|---|
| LS-118 for all eight | 2 | 08-12 |
| LS-204 for all eight | 4 | 06-12 |
| As actually judged | 3 | 07-12 |
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.
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).
Ask for a demonstration in the product, not an answer in a slide.
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.
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.
reading_id, definition_id, reading_value, unit, reading_at, recorded_at, recorded_by, sensor_id, entry_method, reading_purpose, machine_state, limit_set_id, limit_set_version and status. alarm_state and delta_vs_baseline are derived and should never be typed by a person.
A measurement point is a named, permanent physical location and direction on an asset, such as the drive end bearing read axially, with a fixed mounting method. It is the level that makes two readings comparable, and editing one instead of superseding it destroys the trend behind it.
On the point, in a versioned set carrying an author, a date and an effective period. Healthy values at two points on one skid can differ by a factor of two, so a single machine level threshold is always too tight for one of them and too loose for the other.
It is derived when the row is written: find the limit set whose effective period covers the reading, stamp its identifier and version on the row, compare in the direction the limit declares, then apply the deadband before any notification. Nobody should be able to type it.
Because the band changes the number with nothing mechanical changing. In the example above the same signal reads 4.8 mm/s RMS filtered from 10 Hz and 6.0 mm/s RMS filtered from 2 Hz, a difference of 25.0%.
Connexion
Blog
