How predictive maintenance works on ships and where to begin
Predictive maintenance tracks how each machine is actually running against its own history and raises a job when the readings show a fault developing, instead of when the calendar or run-hour counter comes due. It runs alongside planned maintenance and does not replace it. On a fleet with engines, gensets and pumps from several manufacturers, it only works once the telemetry is comparable across makers and linked to maintenance history, manuals and warranty records.
What it means on a ship
Your planned maintenance system raises work orders by date or running hours, whatever state the machine is in. Predictive maintenance changes the trigger. Signals such as vibration and bearing temperature are watched continuously, and lube oil condition is sampled at intervals. A job appears when the pattern departs from that machine's normal behavior. The work itself, the spares and the crew are unchanged. Because only the moment the job gets raised moves, most fleets run both triggers side by side on the same work order system.
Which machinery goes predictive and which stays on the calendar
Move a machine to predictive triggers when three conditions hold:
- Its failure modes vary.
- Reliable sensor data already exists.
- You can build a baseline for that specific asset.
Well-instrumented engines, gensets and pumps tend to meet all three.
Leave an item on the calendar when a class survey or regulatory interval fixes the date. That requirement is set by the calendar, so a good reading won't push the job back. Our post on what decides condition-based versus planned maintenance shows how to sort a machinery list on this basis.
The baseline needs the most care. A model has to tell a developing fault from normal variation caused by load, weather or duty cycle. A genset running hard in a seaway has a different normal from the same genset idling alongside. If the baseline comes from a generic equipment profile, the model flags ordinary load changes and misses real drift on that particular unit.
Do you need new sensors to start?
In most cases, not at first. Most onboard equipment already has sensors and a point solution for reading them. Start by watching that data in real time instead of reviewing it weekly or monthly. Then set a baseline for each machine: the pattern of readings that shows its normal state. Once you have that, you can watch for deviation from it.
Buy hardware later, once you can name a machine whose failure matters and whose existing signals give no warning before it fails.
Running it across engines from several manufacturers
Each OEM platform names its signals its own way, uses its own units and identifiers, and keeps readings in its own portal. Two gensets from different makers can both report lube oil temperature, and software still can't compare them automatically.
You can test this in an afternoon. Take exports from two makers' gensets and plot lube oil temperature for both on one chart, with no manual unit conversion. If someone has to reconcile names and units by hand, anomaly detection built on that data will produce alerts the crew soon stops trusting. The mapping has to be done before any analysis runs. Our post on normalizing OEM telemetry across manufacturers covers how to do it.
From alert to repair: where each step pulls its data
Picture a chief engineer standing at a pump after an alert. To act on it, they need the last work orders, the relevant procedure and the parts record for that exact pump. If those sit in separate systems, acting on the alert turns into a research task. Each step of the loop draws on a different record:
| Step | Record it draws on | How it breaks on a mixed-OEM fleet |
|---|---|---|
| Reading collection | OEM telemetry | Each maker uses different signal names, units and identifiers |
| Baseline | OEM telemetry plus operating context | No per-asset normal that accounts for load and duty cycle |
| Anomaly flag | Normalized telemetry | Readings from different makers can't be compared |
| Diagnosis | CMMS history, manuals and procedures | History sits in free text, and the fix the last chief engineer made was never written down |
| Repair decision | Parts records, warranty and vendor terms | A repair goes ahead without using coverage the fleet already holds |
The first three steps depend on telemetry that agrees across makers. The last two depend on telemetry joined to maintenance, manual, parts and warranty records. When a rollout underdelivers, check these joins first, before looking at the analytics.
Manuals and procedures take separate work to become usable in this loop. Our guide on how to make maintenance manuals searchable on a fleet covers that part.
What results to expect, and how to see this on your own fleet
Treat published gains with caution. The figures most often quoted come from industrial companies in general, not ship fleets. Helin cites companies reporting 2–6% higher availability, 10–40% less reactive maintenance and 5–10% lower inventory costs, and notes that 80% of companies in industrial maintenance link using a computerized maintenance management system (CMMS) to greater productivity. These figures are self-reported, so don't plan a budget around them.
Your own result depends on two things. The first is how much of your machinery meets the three conditions for predictive triggers. The second is whether the data underneath is machine-readable or only digitized. At SailPlan we build a unified schema that works on top of your PdM software, historian, OEM platforms and CMMS and leaves all of them in place. A reading from one maker lands in the same field as the equivalent reading from another, and your maintenance, manual, procurement and warranty records link to the same piece of equipment. You can request a demo at sailplan.com/request-demo to see that model built from your own systems.
For a first test, pick the machine whose alerts your crew trusts least. Gaps between its telemetry, CMMS history and warranty terms are most likely to show up there first.
Related resources
SailPlan builds the machine-readable data model that makes every AI tool in your stack actually work. Request a demo to see it in action.