Choosing predictive maintenance software for a mixed-OEM fleet
Predictive maintenance software watches how each machine is actually running, compares that with its past behaviour, and raises a job when the readings say one is due, not when the calendar or run-hour counter does. On a fleet running engines, gensets and pumps from several manufacturers, results depend on whether your telemetry, maintenance logs, manuals and warranty records sit in one machine-readable structure the software can query.
What the software does
Planned maintenance raises work orders by date or running hours, whatever state the machine is actually in. Condition-based and predictive approaches swap the schedule for a measurement. A signal such as vibration or bearing temperature is watched continuously, and lube oil condition is sampled at intervals. A work order goes out when a reading crosses a defined threshold, or when the trend shows it heading there.
Predictive maintenance software handles that monitoring, flagging and forecasting. When the data behind it is sound, work follows each machine's actual condition, and some scheduled jobs that weren't needed can come out of the plan. Our piece on condition-based versus planned maintenance for ships explains how much the choice between the two depends on the state of your data.
Why results stall on a fleet with several OEMs
When a PdM rollout underdelivers on a mixed fleet, look at the data underneath before blaming the analytics. Each OEM platform names its signals differently, uses its own units and identifiers, and keeps readings in its own portal. Maintenance history lives in the CMMS, sometimes as free text. Manuals are PDFs. Warranty terms and claims sit in yet another system.
Most of that data is digitized: it exists in a spreadsheet, an export or a vendor portal that a person can read. Little of it is machine-readable, meaning structured with consistent identifiers and defined relationships so software can query across sources directly. If an engineer has to map one maker's tag names onto another's before every comparison, the data is digitized, not machine-readable. A PdM tool fed digitized data can still draw a convincing dashboard. What it can't do reliably is tell you that a reading is out of line for one particular asset compared with its sister units from a different maker.
What each stage needs from your data
Condition-monitoring software can be described in six stages, from collecting readings to recommending action. Each stage draws on a different part of your records and fails in its own way when those records don't line up.
| Stage | What it does | Fleet data it depends on | Where fragmentation breaks it |
|---|---|---|---|
| Data acquisition | Collects sensor readings | OEM telemetry from each machine | Every OEM platform exports in its own format with its own identifiers |
| Data manipulation | Cleans readings, converts units, computes features | Telemetry plus signal and unit definitions | The same measurement arrives under different names and units, so features don't carry across makers |
| State detection | Compares readings with thresholds or baselines | Telemetry tied to a consistent asset identity | Without shared fields, the same asset type can't be compared across manufacturers |
| Health assessment | Judges degradation and likely cause | Maintenance logs and failure history for that asset | When work history is free text in the CMMS, the tool can't tell whether last month's bearing change explains today's vibration trend |
| Prognostics | Projects remaining useful life | Run hours and failure history across similar assets | Inconsistent equipment naming stops you pooling history from sister assets |
| Advisory | Recommends action and plans the work | Manuals and procedures, warranty and vendor terms, procurement, and personnel records for root-cause work | If the recommendation can't see coverage dates, a covered part can be booked and paid for as a routine repair, and the claim may never be filed |
The first three stages need telemetry that agrees across makers. The last three need telemetry joined to the rest of your records.
Questions to ask before you buy
Put these to any product you evaluate, and to your own data team:
- Can it compare the same asset type across manufacturers without a new connector for every source? Ask the vendor to show lube oil temperature from two makers' gensets on one chart, built from your exports, with no manual unit conversion. If they need a services engagement to do it, expect that cost to come back for every new make, and again for every new tool you add. We call that repeated connector rebuilding for each new tool the integration tax.
- Can it reach maintenance history, manuals and procedures as well as telemetry? Take a recent alarm and ask the tool to open the last work orders and the relevant procedure for that exact pump. A pass returns them from the alarm itself. Otherwise a flag on a fuel pump still leaves the technician hunting through PDFs unless you make your maintenance manuals searchable and link them to the equipment they cover.
- Does it connect a failure to warranty and vendor terms? Pick a component you know is still under warranty and trigger a recommendation on it. A pass shows the coverage window and vendor next to the work order. A fail is a plain replacement job.
- Can it rank two sister assets from different makers on cost per operating hour? A pass draws labor, parts, downtime and warranty data from your own records for both. If someone has to assemble the figure in a spreadsheet first, you get the problem described in why cost per operating hour breaks down on a mixed fleet.
- Will the data still be usable by the next tool you add? Ask whether the signal mappings and asset hierarchy built during the trial can be queried by another tool. If they stay locked inside one product, you redo that work when you add an AI agent, a new dashboard or a second analytics vendor.
A product can compare makers well on the equipment it was built around. That doesn't mean it will on yours. Run the trial on the asset class where you have several makers side by side.
Does a data model replace your maintenance software?
No. 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, the rest of your records are linked to the same equipment, and any authorized tool can query the result.
That separates two decisions that often get blurred: which analytics tool to buy, and how to fix the data every tool depends on. Because the layer is model-agnostic and the translation happens once, the PdM product you choose this year and whatever you add after it connect to the same structure, and neither needs its own pipeline.
Before you request a demo at sailplan.com/request-demo, list the systems you run. In the demo we walk through how the model would be built from them; a member of our team responds within one business day of your request. With that structure in place, you can run the cross-maker tests above on your own fleet's data instead of the vendor's reference equipment.
Work with a Boatwork professional
Meta
- Meta title: Predictive Maintenance Software: What Your Fleet Data Needs
- Meta description: Why predictive maintenance software stalls on mixed-OEM fleets, what each stage needs from your data, and the questions to ask vendors before you buy.
- Slug: predictive-maintenance-software-fleet-data-requirements
- Internal links: Condition-Based or Planned Maintenance for Ships: What Decides It Is Your Data, Not the Method, How to Make Maintenance Manuals Searchable on a Fleet, Why Cost Per Operating Hour Calculation Breaks down on a Mixed Fleet
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.