Now live BiseraDB — Onshore's own enterprise data engine is here. See what it can do →
Robotics & Manufacturing  /  Whitepaper
Technical Whitepaper

Clamp-On OEE: Measuring Machine Utilization Without Machine Integration

Manufacturing & Robotics practice · Onshore Technology Consultants · Rev. 2026.09

Overall Equipment Effectiveness is the standard yardstick for how well a machine is used, yet on most floors it is estimated, not measured — the data that would settle it sits behind a controller integration that never gets prioritised. This paper describes a method that skips the integration entirely: a low-cost wireless motion sensor is clamped to the machine, its accelerometer and onboard motion counter are decoded at the edge into a running / idle / off state, and those state intervals are rolled up into availability, performance, and a defensible OEE figure. We cover the signal, the classification state machine and its hysteresis, the arithmetic from state to OEE, the time-bucketed storage model that keeps every query a single indexed lookup, a reference deployment, and — importantly — where the method stops being trustworthy.

01The measurement gap

Ask a plant manager for the utilization of a given machine and the answer usually arrives as a range with a shrug attached: “seventy, maybe seventy-five percent.” The number that would replace the shrug — run time divided by available time, measured continuously — requires a data source on the machine. For a machine built in the last decade that means a PLC integration: mapping tags, standing up an OPC-UA server, and threading the data through the plant network. For a machine built before that, it means retrofitting a source that does not exist.

Both paths are real projects with real owners and real backlogs. The result is that the machines most in need of measurement — older assets, mixed brands, the lathe in the corner that runs one job a week — are the least likely to get it. The measurement gap is not a technology gap. It is a prioritisation gap, and it is closed by removing the integration, not by scheduling it.

02What a clamp-on sensor can observe

A machine that is doing work vibrates, and it moves. Those two facts are enough to distinguish work from no-work without any electrical connection to the machine. The sensor used here is a coin-cell Bluetooth Low Energy tag — the reference implementation uses a RuuviTag broadcasting the RAWv2 (data format 5) manufacturer payload1 — magnet-mounted to the spindle housing, motor, or frame.

Each advertisement carries, among other fields:

The tag advertises roughly once per second and is passive: it holds no connection, so any number of gateways can hear it, and losing one gateway loses no data. A fixed BLE gateway — a small single-board computer, or a phone in kiosk mode for a pilot — scans continuously and does the interpretation.

03Classification: the state machine

The gateway maintains a short rolling window of advertisements per tag (30 seconds in the reference build) and, on each evaluation, decodes that window into motion statistics and derives a state.

The running test

An asset is running when either condition holds over the window:

RMS test   σ( |a| ) > RUNNING_RMS_MG  — std-dev of acceleration magnitude, default 40 mg
Motion test   Δ(counter) / Δt > RUNNING_MOVE_RATE  — counter increments per minute, default 8
Two independent triggers. The RMS test catches continuous vibration; the motion-counter test catches intermittent, higher-energy events (a press cycle, a robot move) that a 1 Hz acceleration sample would alias past.

The counter difference is taken modulo 256 to absorb the 8-bit wrap. Thresholds are per-asset: a surface grinder and a stamping press live at different vibration floors, and the pilot sets each from a few hours of observed baseline.

Idle, off, and hysteresis

RUNNING → IDLE

Requires a debounce of continuous quiet (45 s default) before the state drops, so a pause between cycles or a tool change does not flap the record.

→ OFF

No advertisement heard from the tag for the off-timeout (120 s default). Off wins immediately — the machine is powered down or the tag is gone; nothing to debounce.

GAP ATTRIBUTION

If the gateway itself was down, the missing interval is charged to off, never to the last-seen state — an overnight outage must not inflate idle time.

The output is a stream of closed state intervals — {asset, state, start, end} — plus one open interval re-sent on every flush so the dashboard always shows the current state. Every interval id is deterministic, so a re-sent flush is idempotent and the server never re-aggregates.

04From state intervals to OEE

State intervals are accumulated into hourly buckets. Each bucket holds the seconds spent in each state, a cycle count where one is available, and per-metric summaries (max and mean of temperature, vibration RMS, battery). From the bucket:

Utilization = running_sec ÷ ( running + idle + off )

OEE = Availability × Performance × Quality
  Availability = utilization
  Performance = min( 1, cycles × ideal_cycle_seconds ÷ running_sec )
  Quality   = 1.0  (assumed — see below)
The performance term needs a cycle target and a cycle count. Without a target, the method reports utilization only and is explicit that it is not reporting OEE.

This is deliberately conservative about what it claims to have measured:

TermSourceStatus
AvailabilityMeasured — state intervals from the sensorDirect
PerformanceCycle count (a controller output wired to one gateway input, or an operator entry) against a set ideal cycle timeMeasured where configured
QualityScrap / rework countsAssumed 1.0 until a count source exists

A utilization figure that is correct is more useful than an OEE figure that is complete but partly guessed. The dashboard shows the OEE number only when its inputs are real, and labels the rest as availability.

05Data architecture

The backend is BiseraDB, Onshore’s document data engine. Two design choices keep it fast and cleanly multi-tenant:

A namespace per site

Each customer site gets its own namespace (mfg_<site>). No collection ever holds more than one shop’s data, so a query is scoped by construction and a tenant can be exported or deleted as a unit.

Time-bucketed documents

Readings are not stored one row per sample. One document holds one sensor’s data for one hour — the minute-level samples as an array, the hour’s state totals and rollup as fields, keyed <sensor>:<YYYYMMDDHH>. A year of a 25-machine shop is on the order of tens of thousands of documents, not millions of rows.

Every dashboard read is then a single indexed equality plus a sort and a limit — “this sensor’s last 168 hourly documents, newest first.” On a real collection an indexed query of this shape returns in roughly 13 ms; the same query without the index, as a full scan, takes ten to seventeen seconds. The bucketing is what makes the difference structural rather than incidental.

Ingest is a single keyed HTTPS POST of already-aggregated hour documents, state intervals, and downtime events. There is no inbound connection to the plant and no long-lived socket; a gateway behind a restrictive firewall or on a cellular link works unchanged.

06A reference deployment

The method runs continuously on Onshore’s own infrastructure. A RuuviTag is mounted in the server room; a gateway on a nearby machine scans it, classifies, buckets, and flushes to the production ingest endpoint every 60 seconds; the data lands in a dedicated namespace and is visible on the same dashboard a customer would use.

Nothing in the path is specific to the reference site. A pilot swaps the tag onto a real machine, sets that machine’s thresholds from a short baseline, and points the gateway at the same endpoint.

07Limits of the method

An honest account of where a clamp-on sensor stops being enough:

08Conclusion

The reason most floors estimate utilization instead of measuring it is not that the measurement is hard — it is that the usual way in costs an integration project per machine. Reading the machine from the outside removes that cost. A thirty-dollar sensor, a state machine with sensible hysteresis, and a storage model that keeps every query cheap produce a utilization number that is defensible, an OEE number where the inputs are real, and a mixed-brand, mixed-age floor on a single screen — in an afternoon rather than a fiscal quarter.

The method is deliberately modest about its claims. It measures availability directly, measures performance where a cycle target exists, and does not pretend to measure quality it cannot see. Within those bounds it turns the machines that were invisible into a signal — which is the part that was actually missing.

Notes

  1. RuuviTag RAWv2 / data format 5, manufacturer ID 0x0499. The decoder in the reference gateway is validated against the vendor’s published valid / maximum / minimum / invalid test vectors. Any BLE sensor tag that broadcasts triaxial acceleration and a motion or activity counter can substitute; the classification logic is not tied to one vendor.
  2. Default thresholds (RUNNING_RMS_MG 40, RUNNING_MOVE_RATE 8, OFF_AFTER_S 120, IDLE_DEBOUNCE_S 45, 30 s window, 60 s flush) are starting points, tuned per asset during a pilot.
  3. Query latency figures are from an indexed equality-plus-sort-plus-limit against a real multi-thousand-row collection versus the same query as an unindexed full scan; they are properties of the bucketed data model, not a benchmark of specific hardware.
← Back to Robotics & Manufacturing