Predictive maintenance assessment

Every failure in this fleet announced itself first.

We analysed 24,042 sensor readings from 20 machines over 14 days. There were 38 failures costing USD 222,426 — and in 84% of them, the machine had been signalling distress for a median of 22 hours before it stopped. None of that warning was acted on, because nothing was watching for it.

24,042 readings 20 machines · CNC, pump, compressor, robotic arm 14-day window 6 sensor channels

M-07 · PUMP · bearing failure · repair cost USD 4,994 —

Actual recorded telemetry. The line is the largest deviation across four sensors, measured against that machine's own healthy baseline for its current operating mode — so it reflects degradation, not workload. The machine crossed the alert threshold 22.6 hours before it failed.

Failures in 14 days

$222k

Repair cost

41.5%

Cost from 5 machines

50%

Missed by weekly PM

84%

Detectable in advance

22.1h

Median warning

What this assessment answers

Three questions, answered with your own fields.

Most maintenance teams already hold everything needed to see failures coming. What is missing is the path from a reading crossed a line to a technician is on site with the right part and the right procedure.

What is failing, and what does it cost?

Not incident counts. Cost concentration by asset and by failure mode — so budget follows evidence.

Can a calendar schedule catch it?

Tested directly against every observed failure, rather than assumed. The answer is unambiguous.

Is the existing data good enough to predict?

How much warning it gives, what accuracy is achievable, and which three data problems must be fixed first.

About this dataset. These findings come from a representative industrial telemetry set, not from your own machines. We use it to show exactly what OpteraOne extracts from data in this shape — the same fields your systems already record. The natural next step is to run this identical analysis against your own export, which we do before any commitment.

Discovery — what the data revealed

Four findings, and none of them needed new sensors.

Everything below was derived from fields already present in the export: six sensor channels, operating mode, hours since maintenance, and repair cost.

Finding 01 — Cost concentration

Failure cost is not spread evenly. Five machines carry 41.5% of it.

A counting note that matters: the raw data contains 3,560 rows flagged failure within 24 hours. Those are not 3,560 failures — they are individual readings taken inside a warning window. Collapsed into distinct events per machine, the real figure is 38 failures, roughly one per machine every seven days.

Motor overheat and bearing failures occur at identical frequency, but overheat costs 60% more per event. A programme that treats every failure mode as equally urgent is misallocating both attention and spares.

Machine	Type	Events	Cost (USD)
M-19	Robotic Arm	3	19,772
M-07	Pump	3	18,956
M-13	Compressor	3	18,868
M-04	CNC	3	18,759
M-10	Pump	3	15,937
Top 5 of 20 machines		15	92,292 · 41.5%

Failure mode	Events	Total	Avg
Motor overheat	12	95,251	7,938
Bearing	12	59,561	4,963
Electrical	6	35,757	5,960
Hydraulic	8	31,857	3,982
All modes	38	222,426	5,853

Action. Asset criticality becomes measurable rather than a matter of opinion. Monitoring, spares holding and technician attention concentrate on the five assets that consume 41.5% of the repair budget.

Finding 02 — The calendar cannot work

Failures happened anywhere between 26 and 576 hours after service.

Every machine records hours since maintenance. Reading that field at the moment each failure occurred gives a spread of more than twenty to one — shortest 26.6 hours after service, longest 575.6 hours, median 168.

Test any fixed preventive interval against the 38 real failures and the same thing happens: the machines that fail early are missed, and the machines that would have run fine are stripped down anyway.

There is no interval that works. A machine that failed at 26 hours and a machine that ran 576 hours clean cannot be served by the same schedule. The variable that predicts failure is not elapsed time — it is condition.

Failures occurring before service is due

3 days23.7%

5 days36.8%

7 days50.0%

10 days60.5%

14 days65.8%

A weekly service cycle misses half the failures. Tightening to three days still misses nearly a quarter — while more than doubling labour cost and taking machines offline for servicing they did not need.

Finding 03 — Each failure mode has a fingerprint

Four failure modes. Four different sensors raise the alarm.

Comparing the 24 hours before failure against healthy readings from the same machine in the same operating mode — so the comparison is not simply "the machine was working harder" — produces clean separation. Across all modes, vibration rises 51%, temperature 25% and current 27%. But the leading indicator changes with the fault.

Bearing

12 events · $59,561

+125%Vibration RMS

Temperature +22%
Current +22%
Warning: 23.6h

Motor overheat

12 events · $95,251

+45%Motor temperature

Current +24%
RPM −21%
Warning: 22.2h

Electrical

6 events · $35,757

+72%Phase current

Pressure +18%
Temperature +15%
Warning: 7.1h

Hydraulic

8 events · $31,857

−9%Pressure level

RPM −14%
Vibration +29%
Warning: 13.1h

Action. A single vibration alarm — the most common approach on the market — catches bearing failures well and electrical failures badly. Predicting all four modes requires multi-sensor logic evaluated against a per-mode baseline. That is a configuration decision, not a research project.

Finding 04 — Data readiness

The data is good enough to act on. It is not yet good enough to act on automatically.

Three issues stand between this data and an automated work order. All three are fixable, and all three are scoped in section 03.

Remaining-useful-life conflicts with the failure flag

36.6% of records — 8,800 rows — show remaining useful life under 24 hours while the failure flag reads zero, failure type reads "none", and repair cost is zero.

The likely explanation is that this field counts down to a scheduled cycle boundary rather than to a failure, and only some boundaries are failures. Either way, it cannot currently trigger work orders — it would raise false jobs on more than a third of all readings.

Missing values are worse measured by row than by cell

The export reports 4,022 missing values — 1.12% of all cells, which sounds negligible. Measured by row, 14.0% of readings are missing at least one sensor value.

For a rule that evaluates four sensors together, one reading in seven is degraded.

Telemetry gaps create real blind periods

There are 41 gaps longer than two hours, the longest running 19.4 hours on M-02. Total unmonitored time is 353.7 machine-hours — 5.26% of fleet operating time. Sampling is irregular throughout: median 16 minutes, ranging from 2 minutes to 19.4 hours.

Given that median warning time is 22 hours, a 19-hour gap can consume almost an entire warning window.

Setup — what we would configure

The rule, the fixes, and the work it generates.

We tested detection rules against all 38 events. This is the configuration we would deploy, why we rejected the more sensitive alternative, and the three data items that must be closed before automation is switched on.

Setup 01 — Detection rule

Recommended configuration

Raise an alert when any sensor exceeds 2.5σ above its healthy baseline for that machine's current operating mode, sustained across two consecutive readings.

The per-mode baseline is what separates degradation from workload — a pump running hot at peak load is not the same as a pump running hot at idle. The two-reading persistence requirement suppresses single-sample noise without meaningfully delaying detection.

Performance across 38 events

Measure	Result
Failures detected	32 of 38 · 84%
Median warning time	22.1 hours
Repair cost covered (≥4h warning)	83% · USD 184,614
Alert volume	5.5 per machine / week
Events missed	6 · USD 25,931

Why not the more sensitive rule? A 2.0σ threshold with no persistence detects 92% of events — but generates 12.5 alerts per machine per week. That is a volume which guarantees alerts are ignored within a month. We trade eight points of detection for less than half the alert load, because an alert nobody actions is worth nothing.

Warning time by failure mode

Mode	Detected	Median warning
Bearing	10	23.6h
Motor overheat	12	22.2h
Hydraulic	4	13.1h
Electrical	6	7.1h

Where this is weakest

We would rather state these now than discover them in a pilot. Robotic arm assets are hard to predict — only 4 of 9 events detected, median warning 6.7 hours; they likely need a dedicated baseline or an extra sensor channel. Electrical faults develop fast — 7 hours is enough to schedule a controlled shutdown, but not to source a part that is not already on the shelf. And six events gave no usable warning at all. This reduces unplanned failure; it does not eliminate it.

Setup 02 — Data actions before go-live

Three items, closed in the first phase.

Reconcile the remaining-useful-life definition

Establish with your engineering team what the field counts down to, and whether a cycle boundary and a failure can be distinguished in the source system.

Outcome A field that can safely trigger a work order, or a documented decision to exclude it from the rule set.

Define behaviour on partial readings

Decide explicitly how the rule behaves when a channel is absent: carry the last value forward, evaluate on available channels only, or suppress the reading.

Outcome Deterministic handling of the 14% of readings that are incomplete — a decision, not a silent default.

Monitor for silence, not just for readings

A machine that stops reporting is as important as a machine reporting badly. Configure a heartbeat rule that raises a job when telemetry stops for longer than a defined interval.

Outcome The 5.26% blind time becomes visible and assignable instead of invisible.

Setup 03 — What the alert becomes in OpteraOne

The failure mode selects the work — so nobody receives "check machine 7".

OpteraOne structures work as Kategori Tugas → Alur Tugas → Checklist. Because each failure mode has a distinct leading sensor, the triggering channel determines which category, flow and checklist the technician receives.

Trigger	Inferred mode	Kategori Tugas	Alur Tugas	Checklist
Vibration >2.5σ	Bearing wear	Preventive — Rotating	Inspect → Measure → Replace → Verify	Bearing inspection (14 items)
Temperature >2.5σ	Motor overheat	Preventive — Thermal	Inspect → Clean → Test → Verify	Cooling & airflow (11 items)
Current >2.5σ	Electrical	Corrective — Electrical	Isolate → Test → Repair → Energise	Phase balance & insulation (9 items)
Pressure <2.5σ	Hydraulic	Preventive — Hydraulic	Inspect → Pressure test → Seal → Verify	Seal & line integrity (12 items)
No telemetry	Sensor / comms fault	Corrective — Instrumentation	Check → Restore → Confirm	Heartbeat restoration (6 items)

Assignment and acknowledgement. Workflow automation assigns by skill, zone and availability. The technician confirms on mobile — Menunggu Konfirmasi → Dikonfirmasi — so a supervisor knows within minutes whether a critical job has been picked up, instead of discovering at shift end that it was not.

Setup 04 — Connecting to your systems

If your historian does not speak to OpteraOne, we build the bridge.

Sensor data rarely arrives in a convenient form. It sits in a SCADA historian, a PLC gateway, an OPC UA server, a vendor cloud, or a nightly CSV drop — and it usually does not have an API anyone wants to depend on.

PT Akar Inti Teknologi is a software development and systems integration company. Building the middleware that normalises your telemetry, applies the baseline logic and calls OpteraOne is ordinary work for us, not an exception. That layer is where the per-mode baselines are computed and where the persistence rule is evaluated, so the platform receives a clean, already-qualified event rather than a raw firehose.

Ingest

OPC UA, Modbus, MQTT, REST, SQL or scheduled file drop — whatever the plant already emits.

Normalise & baseline

Per-machine, per-operating-mode baselines maintained on a rolling window; partial readings handled per A2.

Qualify

Threshold and persistence logic applied here, so only sustained breaches reach the platform.

Dispatch to OpteraOne

A qualified event creates the work order with machine, sensor, reading and inferred failure mode attached.

Outcomes — control before failure

The same machine. The same 22 hours. A different ending.

This is M-07 again — the pump from section 01, the one that failed with a USD 4,994 bearing repair. The recorded data is identical up to the alert. What changes is that something was watching, and the warning became an assigned job.

M-07 · PUMP · same event, under condition-based control —

Solid line: recorded telemetry up to the alert. Dashed line: the intervention path once a work order is raised, assigned and completed inside the warning window — a projection, not recorded data. The failure point is never reached because the machine is serviced at T−6h, on a planned stop.

T−22.6h

Threshold breached

T−22.5h

Work order raised

T−21h

Technician confirms

T−6h

Planned stop, bearing replaced

T−0h

Failure never occurs

Asset history enriched

The loop that makes it work

Detection alone changes nothing.

An alert that lands in an inbox and is not converted into an assigned, tracked job produces the same outcome as no alert at all. This is the gap OpteraOne closes.

01 · AMS

Asset foundation

All 20 machines registered with type, location, criticality rank, service history and cumulative repair cost. The 41.5% concentration becomes a live ranked list.

02 · RULES

Condition thresholds

Configured per machine type and per operating mode, adjustable by your engineering team. Not hard-coded, not vendor-locked.

03 · FSM

Work order raised

A sustained breach creates a job automatically, carrying the machine, triggering sensor, reading and inferred failure mode.

04 · TASK

The right procedure

Kategori Tugas → Alur Tugas → Checklist selected by failure mode. A specific procedure, not a note saying "check machine 7".

05 · MOBILE

Assigned and acknowledged

Assignment by skill, zone and availability. Menunggu Konfirmasi → Dikonfirmasi, so supervisors know within minutes.

06 · CLOSE

Executed and fed back

Checklist worked on mobile, parts and photo evidence recorded. Completion writes back to the asset record and resets the maintenance clock.

The loop compounds. Every completed job enriches asset history, which sharpens the next threshold, which improves the next prediction. Detection accuracy rises the longer the system runs — which is precisely what a fixed calendar schedule can never do.

Outcome 01 — What changes operationally

Today	With OpteraOne
Fixed schedule — misses half the failures	Condition-triggered — catches 84%
Failure discovered when the machine stops	Median 22 hours of advance warning
Generic "inspect machine" instruction	Failure-mode-specific checklist
Verbal or WhatsApp dispatch	Assigned, timestamped, acknowledged
Repair history in spreadsheets or memory	Cost and history per asset, queryable
Unplanned stop, at the worst moment	Planned stop, inside the warning window
Maintenance judged by jobs completed	Judged by failures prevented

Outcome 02 — Value model

USD 184,614 per fortnight is addressable. How much converts is your input, not our claim.

The addressable figure is the repair cost attached to failures detected with at least four hours of warning — 83% of total failure cost.

Not all of it becomes savings. Detection creates an opportunity to intervene; value depends on how often intervention succeeds, and planned work still costs money. The model assumes planned intervention costs 30% of the equivalent unplanned failure, and leaves the conversion rate for your team to set.

Read the annualised column with care. It assumes the observed failure rate — roughly one failure per machine per week — holds across the year. That is a high rate. If your fleet's actual rate is lower, scale proportionally. We would re-run this against your own twelve-month history before it informs a budget.

Conversion rate	Per 14 days	Annualised
Conservative · 40%	$51,692	$1.34M
Moderate · 60%	$77,538	$2.02M
Optimistic · 75%	$96,922	$2.52M

Not included, and usually larger

Production output lost to unplanned downtime; expedited freight on unplanned parts; overtime for emergency callouts; and the knock-on cost of secondary damage when a failure is not caught early. Every one of these falls when the stop becomes planned.

Outcome 03 — How we get there

Data reconciliation

Resolve the RUL conflict, define partial-reading behaviour, close telemetry gaps, agree the failure-mode taxonomy.

A data foundation that can safely trigger automated action.

Asset foundation

Load assets into AMS with criticality ranking, import maintenance history, configure task categories, flows and checklists per failure mode.

Every asset has an owner, a history and a procedure. Delivers value even with no detection running.

Middleware & integration

AIT builds the ingestion and qualification layer against your historian, gateway or file drop.

Clean, qualified events reaching OpteraOne — not a raw sensor firehose.

Detection in monitor-only mode

Thresholds configured per mode, run without dispatching, alerts validated against real outcomes and tuned to target volume.

Confidence in the rules before they assign anyone to anything.

Automated dispatch, then tuning

Enable automatic work order generation and acceptance on the highest-criticality assets first. Review detection monthly, retune, extend.

Predicted failures become completed jobs. Detection rate rises as history accumulates.

Next step

Send us twelve months of your own telemetry.

We will run this identical analysis against your data and return your actual failure baseline, your cost concentration, your detection rates and your warning times — before any commitment is made. If the numbers do not hold up on your fleet, you will hear that from us first.