At the annual machinery survey, the class surveyor no longer asks for a binder: he asks for the history. Which work orders on generator no. 2 over the past twelve months, who closed them, at what running hours, and why the injector overhaul was pushed back by 250 hours. If the answer comes out in three clicks, the survey moves on. If it takes an evening of digging through spreadsheets and notebooks, the tone changes — and the list of observations grows. That is precisely what planned maintenance system software — a PMS, in classification society vocabulary — is there to guarantee: that the vessel's planned maintenance is described, executed, recorded and demonstrable at any moment.
Yet ask three surveyors what a PMS must contain and you will get three answers that overlap without coinciding. Class rules define outcomes, not software: that is what explains the variation. This article is about the tool itself: what DNV, LR, ABS, BV, RINA or ClassNK actually require from the software, the technical specifications that follow from those requirements, and the criteria that separate a genuine PMS from a computerised calendar. The approval process itself — building the file, the trial period, the annual audits, keeping the arrangement alive — is covered in our dedicated article on getting and keeping an approved planned maintenance system. Here, we are talking about the evidence machine, not the procedure.
What is planned maintenance system software?
Planned maintenance system software is the application that structures a vessel's planned maintenance: it holds the equipment inventory, carries the jobs and their intervals, triggers work on calendar dates or running-hour counters, and records what was done, by whom and in what condition the component was found. On board it plays a double role: the engine department's day-to-day working tool, and the body of evidence presented to class, the flag State and Port State Control.
In practice the term covers the same reality as maritime CMMS or ship maintenance software: "PMS" is simply the word the rules use. Chapter 10 of the ISM Code already requires every vessel it covers to maintain the ship in accordance with a system of inspections at appropriate intervals, to deal with non-conformities and to identify critical equipment — without mandating any software. Classification societies go one step further: the moment an owner wants the maintenance regime formally recognised (and wants survey credits in return), the medium has to offer guarantees that a binder or a spreadsheet cannot give. The same logic runs through other regimes: under USCG Subchapter M, a towing vessel's TSMS rests on exactly the same kind of documented, auditable maintenance records — our article on Subchapter M and TSMS maintenance requirements covers the American case. In every jurisdiction, the software is where the argument is won or lost.
What classification societies actually require from the software
Whether you sail under DNV, LR, ABS, BV, RINA or ClassNK notation, the requirements converge on a short list. Each society words them its own way in its rules and guides, but the substance barely moves:
- An inventory of the machinery covered: every item in scope uniquely identified, with its characteristics, its location on board and its maker's documentation attached.
- Justified intervals: maker's recommendations by default, adjustable on documented operating experience or on condition monitoring — never frequencies set by feel.
- Job descriptions: what has to be done at each due date, so the result does not depend on the memory of whoever holds the post.
- Complete records: work done, date, author, running hours at the time of the job, condition found, spares consumed.
- Identification of overdue work: the system must show unambiguously which due jobs have not been done — the overdue list is the first thing the surveyor asks for.
- Controlled access: named accounts and differentiated rights, so that records cannot be altered or deleted without leaving a trace.
Read those six points again: the software specification writes itself. The table below translates each rule requirement into a concrete function to check during a demonstration.
| Class rule requirement | What the software must actually do |
|---|---|
| Equipment inventory | Vessel → system → equipment → component tree, unique codes, maker's documents attached to each record |
| Justified intervals | Calendar dates and running-hour counters combinable, a mandatory justification field on any interval change |
| Job plans and procedures | Instructions, checkpoints and safety notes carried by the work order itself |
| Maintenance records | Timestamped, attributed close-out, counter reading required, condition found, photos and attachments |
| Overdue identification | Overdue list by vessel and by criticality, produced in one click, exportable for the surveyor |
| Controlled access and integrity | Individual accounts, roles (chief engineer, second, rating), change log, no silent deletion |
Outcome rules, not homologated software
No classification society mandates a brand of software. Some issue conformity statements to vendors whose product meets their requirements, which simplifies the paperwork; but the approval that matters is always the vessel's system — the software, its data, the procedures around it and the crew who use it. An excellent tool filled in carelessly will be refused; an average tool kept rigorously can pass. The software is a necessary condition, never a sufficient one.
The software requirements hidden behind the rules
The rules say nothing about databases or synchronisation. But confront them with the reality of a working ship and four technical requirements impose themselves — and they are the ones that eliminate most generic solutions.
Data integrity first
Every entry must be timestamped and attributed to a person, and any later change must leave a trace. This is the criterion the shared spreadsheet fails on day one: an Excel cell rewrites itself without a witness, a row disappears without a history, and two versions of the file circulate between ship and office. We put figures on what that really costs in Excel versus a maritime CMMS: beyond the audit risk, it is the evidential value of the whole history that collapses. A surveyor who doubts one record doubts all the others.
Availability on board, therefore offline
Class surveys happen at sea, at anchor or in ports where connectivity is wishful thinking. A purely web-based PMS, unreachable without a network, is unusable at exactly the moment you need it. The software has to work offline: browsing the history, raising and closing work orders, entering counter readings, all queued locally and synchronised as soon as the vessel finds a network again. That is how the Smart Sailors mobile app is built, and it is a knockout criterion: without a real offline mode, entries get made on paper "for now", and then stop being made at all.
Traceability of postponements
No maintenance plan runs exactly as written: a part arrives late, the weather rules out stopping a generator, a port call gets cut short. What the surveyor penalises is not the postponement — it is the invisible postponement. The software must therefore require, for every shifted due date, a recorded justification: who decided, when, on what grounds, with what new deadline. The full life cycle of the work order — creation, assignment, execution, any deferral, close-out — must be readable months later without reconstruction.
Reporting in one click, not one evening
The overdue list, the complete history of one item of equipment, the running hours at each intervention: those three reports must come out in seconds, filtered and exportable to PDF or spreadsheet. That matters for the class survey, and just as much for a port State inspection: during a Port State Control visit, maintenance is classic deficiency territory, and the ability to produce a clean history on the spot changes the outcome of the inspection.
Cyber security, the newcomer in the specification
Since IACS UR E26 and E27 took effect for newbuilds contracted from mid-2024, the cyber resilience of onboard systems — and of the software that connects to them — has entered the scope of classification. For a PMS, that translates into very concrete questions for the vendor: account and password management, encrypted exchanges, update policy, backups and data location. Our article on IACS UR E26/E27 and maintenance details what these rules change on board.
What does an approved PMS change for machinery surveys?
The answer fits in one sentence: within a continuous machinery survey arrangement, an approved PMS allows part of the inspections to be credited on the strength of the chief engineer's work recorded in the software, with the classification society verifying the whole at an annual audit instead of attending every opening-up. Concretely: fewer dismantlings done purely for show, shorter surveys, and inspections spread across the five-year cycle.
The precise conditions — eligible equipment, chief engineer qualification, content of the annual audit — vary with your classification society, and the arrangement is lost if the system's upkeep slips. The full journey is described in our article on the approved planned maintenance system; and to tie that arrangement into the wider calendar of hull surveys, certificates and statutory deadlines, see how to run ship certificates and class surveys from a CMMS. Keep just this in mind: without software able to produce unimpeachable records, the question of approval does not even arise.
How to choose planned maintenance system software: the criteria that matter
A sales demonstration always shows software that works. The criteria below are the ones that separate a PMS that will survive five years of operation and three audits from a tool abandoned at the first crew change.
- Native offline mode: the mobile app must let you browse, enter and close work without a network, with deferred automatic synchronisation — not just a read-only cache.
- Built-in running-hour counters: jobs triggered on actual running hours, not only on the calendar; that is the role of the Meters module, and it is what makes your intervals defensible in front of a surveyor.
- Import of maker's schedules: job plans and intervals for engines, generators and auxiliaries must be importable or built from templates, not retyped line by line for three weeks.
- A change log: who changed what, and when — on intervals, due dates and close-outs. Without it, no evidential value.
- Audit-ready exports: history per equipment, overdue list, counter readings, to PDF and spreadsheet, without manual assembly.
- Links to inventory and purchasing: every work order must be able to consume spares and trigger replenishment, or you will end up running two systems that drift apart.
- A fleet view: comparing backlog, costs and counters across every vessel from the office, without consolidating by hand.
- Readable per-vessel pricing: a price that punishes the number of users discourages crew adoption — and it is the crew who keep the records alive.
- A vendor who knows ships: the question "how do you handle a deferral for weather?" quickly eliminates generic CMMS platforms dressed up as maritime.
To turn this list into a structured decision, use our 32-criteria scorecard with RFP template: it weights these points by fleet type and stops you choosing on demo impressions alone.
Beyond compliance: the same software steers the costs
A PMS bought only to satisfy class is an investment half wasted. The data that convinces a surveyor — running hours, job history, spares consumed, overdue work — is exactly the data that steers availability and budget. The same history that proves compliance feeds MTBF per equipment, the preventive ratio, the value of stock tied up and the full cost per vessel: the 15 maritime maintenance KPIs come out at no extra effort once the entry is made a single time, at source, in the Maintenance module.
That is the argument to put to management when the PMS is seen as a compliance cost: the tool class requires is also the one that documents budget requests, justifies drydock trade-offs and puts facts on the table with engine makers. Compliance pays for the ticket; operations collect the return.
A word on implementation
The best software fails if the rollout is botched: an incomplete inventory, intervals copied without checking, an untrained crew, and six months later the spreadsheet is back out of the drawer. Treat it as a real project — importing maker's data, configuring vessel by vessel, training incumbents and their reliefs — and follow a proven method: our phase-by-phase implementation checklist maps the route, and the complete maritime CMMS guide sets the PMS within the full set of modules — inventory, purchasing, certificates, crew — that revolve around it.
Key takeaways
Classification societies do not require software: they require outcomes — an inventory, justified intervals, complete records, visible overdue work, controlled access — that only genuine planned maintenance system software can guarantee over time. The criteria that matter are not cosmetic: data integrity, offline operation, traceable postponements, one-click audit exports. They are what separates the tool that reassures a surveyor from the computerised calendar that collapses at the first precise question.
And the same tool that secures the class survey steers the fleet's costs, stocks and availability. That is exactly what Smart Sailors was built for: a maritime CMMS designed in Marseille by seafarers, deployed on more than 700 vessels, with a mobile app that works offline and histories that are audit-ready by construction. Request a demonstration on your own equipment, or take a look at our plans — the trial is free for 30 days.
.png){kind=small}
