Summary
For most of its history the shipboard Planned Maintenance System (PMS) has been a self-contained database: a schedule, a job library, a history and a stores list, synchronised with the office every few days. That model is changing quickly. Continuous connectivity, sensor data, integrated enterprise systems and artificial intelligence are turning maintenance from a scheduled routine into a data-driven, fleet-wide process.
This paper looks at the technologies shaping that change, separates what is mature from what is still emerging, and sets out what ship managers can do now so that their data is ready. The central argument is simple: every one of these technologies depends on clean, structured maintenance data. Fleets that fix their foundations today will be able to adopt the future; fleets that do not will automate their existing errors.
1. From PMS to integrated ERP
Where we are
In many fleets the PMS, purchasing, inventory, finance, crewing and QHSE (quality, health, safety and environment) systems are separate products, connected by exports, spreadsheets and email. The same equipment, part or vessel is described differently in each. Reconciling them takes time, and decisions are made on partial information.
Where it is going
Maritime software is converging on integrated platforms in which maintenance is one module of a wider enterprise resource planning (ERP) environment:
- A job raises its own requisition. When a planned job is due and the parts are not on board, the purchasing process starts automatically, timed to the vessel's port rotation.
- Costs follow the work. Labour, spares and services are booked against the job and the equipment, so maintenance cost per system and per vessel is available without manual compilation.
- Defects feed QHSE. A failure on critical equipment links to the incident, non-conformity and corrective action records required by the ISM Code.
- Crew competence meets the job. Work can be planned around who is on board and qualified to do it.
There are two architectural routes. An integrated suite from one supplier offers consistency but ties the fleet to that supplier. A best-of-breed approach connects specialist systems through open application programming interfaces (APIs) and shared master data. Either works if the master data is consistent: one definition of each vessel, equipment item, part and supplier, used by every system. Paper 05 in this series covers how to design that master data.
What to do now: treat master data as a fleet asset with an owner; insist on documented, open APIs when buying any maritime software; avoid customisations that cannot be migrated.
2. Digital twins
What a digital twin is, and is not
"Digital twin" is used loosely. In a useful sense, a digital twin is a digital representation of a physical asset that is kept up to date with data from that asset and is used to support decisions about it. A 3D model on its own is not a twin, and neither is a dashboard. The value lies in the connection between data, models and decisions.
Twins are often described in levels of capability:
| Level | Question answered | Ship maintenance example |
|---|---|---|
| Descriptive | What is the current state? | Live equipment status, running hours, open defects and condition readings in one view |
| Diagnostic | Why did it happen? | Linking a performance drop to fouling, wear or operating conditions |
| Predictive | What will happen? | Estimating remaining useful life of a bearing or turbocharger from trends |
| Prescriptive | What should we do? | Recommending when to clean the hull or overhaul a unit, balancing cost, fuel and risk |
Most practical ship twins today are descriptive or diagnostic. Predictive and prescriptive capabilities exist for specific systems, notably main engines, hull and propeller performance and some rotating machinery, but rarely across a whole vessel.
Figure 1. Digital twin capability levels and where ship maintenance twins stand today.
What a twin needs from maintenance data
A digital twin is only as good as the data behind it. For maintenance, that means:
- an equipment hierarchy that matches the physical ship and links to the 3D or system model;
- maintenance history and failure records in coded, structured form;
- condition and sensor data linked to the right equipment;
- design and maker data: drawings, limits, performance curves.
DNV's recommended practice DNV-RP-A204, Qualification and assurance of digital twins, gives a framework for establishing whether a twin is fit for its intended purpose, which is a useful discipline before relying on one for decisions.
What to do now: fix the equipment register and hierarchy, and make sure condition data is stored against equipment rather than in reports. These are the foundations of any twin.
3. Sensors, data standards and the shipboard data server
Modern ships already generate large volumes of machinery data through their alarm and monitoring systems, engine control systems and dedicated monitoring equipment. Two problems have limited its use: the data is locked inside separate systems, and the same measurement is named differently on every ship.
International standards now address both:
- ISO 19847 (Ships and marine technology — Shipboard data servers to share field data at sea) specifies requirements for onboard data servers that collect and share data from shipboard systems.
- ISO 19848 (Ships and marine technology — Standard data for shipboard machinery and equipment) defines how machinery data should be identified and structured, so the same measurement is described consistently across vessels and suppliers.
Together they make it practical to collect data once on board and use it in several applications: the PMS, performance monitoring, a twin and the office analytics. For maintenance the immediate benefits are automatic running-hour counters (removing a major source of PMS error, as described in paper 02) and continuous condition monitoring of critical machinery (paper 04).
What to do now: when specifying newbuildings or upgrades, ask for data to be available through standardised interfaces, and map key measurements to equipment in the PMS.
4. Artificial intelligence in maintenance
Predictive maintenance models
Machine-learning models can detect anomalies in sensor data and, given enough examples, estimate the remaining useful life of components. Two limitations are often understated:
- Failure data is scarce. Well-maintained equipment rarely fails, so models have few examples to learn from. Anomaly detection, which learns what "normal" looks like and flags deviations, is usually more practical than direct failure prediction.
- Models need context. A change in vibration may reflect a change in load, a sensor fault or a developing defect. Models perform far better when they can see operating conditions and maintenance history, which again depends on structured PMS data.
AI assistants for engineers
Large language models (LLMs) are now able to search and summarise maintenance manuals, job histories and defect reports in natural language: "When was the last overhaul of No. 2 generator fuel pump, and what did the engineer find?" or "What is the maker's tightening procedure for this cylinder head?"
This is genuinely useful, with an important condition. Language models can produce fluent answers that are wrong. In maintenance, an invented torque value or interval is a safety risk. Responsible use requires:
- answers grounded in the vessel's own documents, retrieving from the actual manuals and records rather than general knowledge;
- citations back to the source document and page, so the engineer can verify;
- the assistant declining to answer when the source does not contain the information;
- humans remaining responsible for maintenance decisions.
This is the same principle that underpins good PMS data: every job, interval and part traceable to the maker's manual. AI makes that traceability more valuable, not less.
AI-assisted data work
AI is also changing how PMS databases are built and maintained. Extracting jobs and parts lists from instruction books, mapping legacy data to new structures and finding inconsistencies can be accelerated with AI tools, provided the output is checked against the source by engineers. Speed without verification simply produces errors faster.
What to do now: digitise manuals in searchable form and link them to equipment; capture failures in coded form; start with anomaly detection on critical machinery rather than ambitious failure prediction.
5. Connectivity: the ship becomes part of the network
Low Earth orbit (LEO) satellite services have brought broadband connectivity with much lower latency and higher capacity to many vessels. For maintenance this changes several assumptions:
- Continuous synchronisation replaces periodic replication between ship and shore databases, so the office sees the real state of the vessel.
- Cloud-hosted PMS becomes viable, with local caching on board for periods without connectivity.
- Remote expert support through video and augmented reality lets shore specialists or maker service engineers guide work on board.
- Software and data updates, such as revised job libraries, reach ships promptly.
Connectivity is not universal or guaranteed, and systems must still work offline. But design assumptions are shifting from "occasionally connected" to "usually connected".
6. Cyber security becomes a maintenance discipline
More connectivity and more integration widen the attack surface. Regulation has followed:
- IMO Resolution MSC.428(98) requires cyber risks to be addressed in the safety management system under the ISM Code, from the first annual verification of the company's Document of Compliance after 1 January 2021.
- IACS Unified Requirements E26 (Cyber resilience of ships) and E27 (Cyber resilience of on-board systems and equipment) apply to ships contracted for construction on or after 1 July 2024, setting requirements for the design, integration and operation of computer-based systems.
For maintenance this has practical consequences. Operational technology on board, such as control, monitoring and navigation systems, needs its own maintenance: software versions, patches, backups, access control and asset inventories. These activities belong in the PMS like any other maintenance, with intervals, responsibilities and records. The PMS itself, once connected to ERP and sensors, must be secured and its integrations controlled.
What to do now: add computer-based systems to the equipment register, with software versions and owners; schedule cyber maintenance tasks in the PMS; review the integrations between systems.
7. Remote surveys and digital certificates
Classification societies increasingly accept remote techniques for some surveys, using video, photographs, drones and data supplied by the ship. IACS Recommendation 42 gives guidelines for the use of remote inspection techniques. Electronic certificates are now widely used and accepted.
Remote surveys depend on the quality of evidence the ship can provide. A PMS that holds structured records, photographs, measurements and reports against each item makes remote verification straightforward. One that holds only "job done" ticks does not.
8. Additive manufacturing of spare parts
Additive manufacturing (3D printing) can produce certain spare parts on demand, reducing lead times and the need to hold slow-moving stock, as discussed in paper 06. Class societies have published guidance on the qualification of additively manufactured parts. In practice, adoption is currently strongest for non-critical parts, tooling and obsolete components, and for printing at qualified facilities ashore rather than on board. The key enablers are digital part definitions, rights from the original manufacturer and a qualification process for anything safety-related.
9. Autonomy and reduced manning
The International Maritime Organization is developing a goal-based Code for Maritime Autonomous Surface Ships (MASS). Whatever the pace of autonomy, the direction for maintenance is clear: fewer people on board to detect and fix problems means more reliance on remote monitoring, condition-based strategies, reliable equipment and planned interventions in port. The building blocks are the same as for the rest of this paper.
10. A realistic view of maturity
Figure 2. Maturity of the technologies in this paper for ship maintenance today.
| Technology | Maturity for ship maintenance today | Main dependency |
|---|---|---|
| PMS integrated with purchasing and inventory | Mature | Consistent master data |
| Full ERP integration across QHSE, crewing, finance | Maturing | Master data, open APIs |
| Automatic running hours from ship systems | Mature where interfaces exist | Data server, equipment mapping |
| Condition monitoring of critical machinery | Mature | Measurement points, baselines, failure records |
| Descriptive and diagnostic digital twins | Maturing | Hierarchy, sensor data, history |
| Predictive and prescriptive twins, whole-ship | Emerging | Data volume, failure data, validation |
| AI assistants grounded in vessel documents | Emerging, moving quickly | Digitised manuals, citations, governance |
| Remote surveys | Established for defined scopes | Structured evidence in the PMS |
| Additive manufacturing of spares | Emerging, niche | Qualification, digital part data, rights |
11. What to do now
The common thread across every technology in this paper is data. A practical sequence for the next two to three years:
- Clean the foundations. Verify equipment registers and job libraries against the makers' documentation (paper 01).
- Standardise master data across the fleet: hierarchy, equipment classes, makers and failure codes (paper 05).
- Digitise and link documents, so manuals, drawings and certificates are searchable and attached to equipment.
- Connect the data you already have. Automate running hours and bring condition data into the PMS (papers 02 and 04).
- Integrate maintenance with purchasing and inventory, driven by planned demand (paper 06).
- Bring operational technology and cyber tasks into the PMS.
- Pilot AI and twins on narrow, valuable problems, with clear success measures and human verification.
Conclusion
The PMS of the future will not be a standalone database. It will be the maintenance layer of an integrated, connected and increasingly intelligent fleet platform, fed by sensors, linked to the enterprise, represented in digital twins and queried through AI assistants. None of that works without trustworthy maintenance data. The fleets that benefit first will be those that treat their PMS data as the foundation it has always been, and invest in it before the technology arrives.
References and further reading
- ISO 19847, Ships and marine technology — Shipboard data servers to share field data at sea.
- ISO 19848, Ships and marine technology — Standard data for shipboard machinery and equipment.
- DNV, DNV-RP-A204: Qualification and assurance of digital twins.
- International Maritime Organization, Resolution MSC.428(98), Maritime cyber risk management in safety management systems.
- IACS, Unified Requirements E26 (Cyber resilience of ships) and E27 (Cyber resilience of on-board systems and equipment).
- IACS, Recommendation 42, Guidelines for use of remote inspection techniques for surveys.
- International Maritime Organization, work on the Code for Maritime Autonomous Surface Ships (MASS).
- Companion papers in this series: 01 Job library, 02 Intervals and class, 03 Migration, 04 RCM and CBM, 05 Master data and 06 Spare parts.
Preparing your PMS data for what comes next? We build, clean, structure and migrate PMS data so it is ready for integration, analytics and digital twins. See our Planned Maintenance System services and Digitisation services.