Features

Each maintenance definition can carry two triggers at the same time. One is a calendar interval in days. The other is a running-hours interval measured on a counter. Both are checked all the time. Whichever limit is reached first sets the next due date.

The "show-only-in-range" window (70% of the interval by default) decides when a task shows in the planners' views. The maintenance list never floods with far-future jobs. An overhaul on a counter resets the running hour counter when it is done, so the next due date is worked out correctly after major maintenance.

Completed maintenance goes through a configurable four-stage sign-off chain: Ship Responsible, Ship Approver, Company Reviewer and Company Approver. Each stage sets its own method. All means every named person must approve. One means any single person can approve. Not required means the stage is skipped.

The seven-status workflow shows where each record is in the pipeline: Waiting, In Progress, Waiting for Ship Approval, Waiting for Office Approval, Ship Not Approved, Office Not Approved and Office Approved. It suits everyone from single-vessel operators who skip every approval stage to large fleet managers who ask for dual office sign-off on each maintenance record.

When a maintenance task passes its due date unfinished, the system asks for a structured explanation. There are 21 overdue reason codes in 7 categories. PMS covers definition or scheduling errors. Operation covers voyage and operational limits. IMS covers inventory and spare part issues. Third party covers contractor or survey delays. Crew covers staff or competency issues. Software covers system-related causes. Computer covers hardware or connectivity problems.

This breakdown turns overdue reporting from a plain "late or not late" figure into a tool for fleet reliability. Group by reason category to tell failures built into planning from one-off operational disruptions, and aim fixes where they will help most.

When the real world stops a maintenance task from running on schedule, the postponement workflow records exactly why and by how much. Three postponement types cover every valid case. Dry Dock defers the job to the next scheduled drydock period. To Date sets a new due date. Additional Work Hour extends a counter by more hours.

Each postponement request records one of 12 structured reasons: Voyage Complications, Weather Conditions, Man Power, No Expertise, Parts Available, Inaccessible, Misuse, Management Hold Order, Officer Hold Order, Policies, Priority or Other. Every postponement request goes through an approve or reject workflow before the due date changes. That leaves a record you can audit for every schedule change.

Every equipment item has its own spare parts Bill of Materials, linked to the Material module catalog. Each spare part link sets a criticality level: VITAL, ESSENTIAL or DESIRABLE. Procurement teams get priority classification at once, without opening other systems.

This two-way integration means that when a maintenance job is planned, the spare parts it needs are already listed on the equipment. Procurement can raise purchase requisitions straight from the BOM, with no manual part number lookups.

And when a part arrives in Inventory, you see at once which equipment it supports.

Each maintenance job carries its own instructions, the technical manuals that apply, the forms to fill and a risk assessment. The engineer opens one job and has all they need to do the work safely and record it.

Each job states whether it needs a risk assessment: required, the crew's call, or suggested. The crew record what they did and why they deviated, and a list shows every job still waiting for its risk assessment.

Organize all machinery on your fleet in a tree with no depth limit. Categories group equipment families, Equipment nodes stand for physical assets, and Sub-Equipment holds components within a unit. Each maintenance definition and its triggers attach to the equipment they cover. The result is one tree that mirrors the real layout of your vessel.

The tree is the backbone of the PMS module. Every maintenance job, running hour log, spare part BOM and downtime record lives inside it. Deep copy lets you replicate a branch from one vessel to another, which removes repeat setup across sister ships.

When a maintenance task is done, a Maintenance Log keeps the full record of the work. The log holds the work description, crew assignments from 51 ranks across the deck, engine and hotel departments, five attachment types (Diagram, Photo, Manual, Form, Other) and structured approval tracking. Only one person can start a job at a time.

Twenty-one Maintenance Log Event Types track every action from creation through final office approval, creating a complete record ready for class society inspection. Each log carries a snapshot of the maintenance definition and equipment state at the time of completion.

Running hour counters are the base of counter-based maintenance scheduling. Crew enter readings on the ship-side forms made for it, or approve readings that officers submit through a structured request and approval flow.

A full Running Hour Logbook keeps every counter value ever recorded, in date order.

For vessels with a supported monitoring system, Navatom collects counter readings on its own, on a schedule. Nobody types them in, so there are no copying errors. Trigger calculations always use the latest machinery state.

Office reviewers and approvers work from an Approval Queue made for them. It gathers every maintenance log waiting for their action across the whole fleet. One view shows each pending record, with filters for vessel, equipment category, maintenance type and urgency.

Approval actions (accept, reject or return for correction) run straight from the queue, with no need to open single vessel records. A rejected log notifies the originating ship by itself and gives the reason. This feeds the ship-side correction workflow.

The PMS tree is not built from scratch for every vessel. Category trees and equipment structures can be imported and exported between vessels, so a standard PMS template reaches the whole fleet fast.

The import checks incoming data against the current schema before it commits, so broken structures do not reach production.

Deep copy lets you duplicate any branch of the equipment tree from one vessel to another. It carries all maintenance definitions, triggers, spare parts BOMs and running hour settings. This matters for sister ships and near-identical vessel classes, because nobody has to re-enter data.

Each equipment records its isolation points: the energy type, the method, the device and where it is. Each point keeps its own history, so the crew isolate the same points the same way each time.

The Equipment Explorer shows the equipment tree on the left and a detail panel on the right. Superintendents and chief engineers can move through the whole PMS structure without losing their place. Select a node in the tree and its equipment details, maintenance definitions, running hour history and spare parts load in the right panel at once.

Fast server-side loading handles fleets with tens of thousands of equipment records and hundreds of thousands of maintenance definitions, with no strain on browser memory. You can combine 12 filters, including equipment type, status, category, vessel and date range, to find exactly the records you need.

Maintenance definitions can trigger child definitions on their own. When a parent maintenance is done, its child tasks become active. This allows multi-step maintenance procedures, such as a performance test after an overhaul, or a visual check after a calibration.

The trigger chain is a parent and child hierarchy. Parent definitions list the children they trigger, and children point back to the parent that triggers them. Child maintenances show in the maintenance list with a clear link to the parent, so crew know which higher-level job they support.

Electrical insulation testing (megger testing) needs more than a pass or fail checkbox. Navatom records all six resistance readings (RS, ST, RT, RE, SE and TE), plus ampere and voltage values, the measurement condition (cold or hot) and the final result (pass or fail).

Each reading is stored as a structured number, not a free-text note.

Because it is built for the job, your electrical survey records are machine-readable, easy to trend and ready to show to class surveyors. A separate Megger Tests list view gathers all test results across the fleet for trends between vessels.

Track each period an equipment item is out of use, and mark each event as Planned or Unplanned. Planned downtime covers scheduled overhauls, drydock periods and dry-run maintenance windows. Unplanned downtime covers breakdowns, failures and emergency stops.

Monthly downtime charts show technical superintendents availability trends across the fleet. Each downtime event links to its equipment record, with any related deficiencies and maintenance logs. This lets you match downtime patterns to maintenance history and spot repeat failure modes that call for preventive action.

In Navatom, equipment criticality is not a single yes or no flag. Each equipment item has two separate criticality settings: critical (how important it is to the vessel's operation) and class critical (how important it is to the classification society). The two are judged apart and can differ.

The split matters for planning maintenance and surveys. Class-critical equipment needs class-traceable maintenance records and defined intervals.

Operationally critical equipment gets closer postponement checks. Filters and analytics treat the two settings on their own.

Dedicated dashboard widgets (11 in all) show fleet maintenance health: overdue counts, upcoming maintenance by interval, completion rates by vessel, equipment downtime distribution, running hour trend lines, approval pipeline depth and postponement frequency. Each widget drills down to the maintenance records behind it.

The Analytics section shows views across the fleet: overdue trends by vessel, overdue breakdown by maintenance type and crew rank, and crew task spread by department. These views let technical superintendents move from reactive firefighting to proactive fleet reliability management.

The company designs the PMS structure in the office Structure editor: equipment categories, equipment items, maintenance definitions, triggers and assignments. When the design is ready, one Publish action sends the whole structure to the target vessel and synchronizes definitions over satellite or broadband.

On the ship, incoming structural changes merge in without disturbing maintenance logs already in progress. Synchronization runs both ways under conflict rules that always keep completed maintenance records.

Vessels can work alone when needed. Changes merge on their own when a connection is available.

Every completed maintenance log is preserved permanently in the archive with its full record — work logs, crew assignments, attachments, approval chain, readings, and the 29 Maintenance History Event Types that capture every action taken from creation to closure. The archive is searchable, filterable, and exportable.

Historical records serve many purposes: class society surveys, insurance claims, flag state inspections and internal performance analysis. Because every change to the archive is logged, you can rebuild what happened, when and by whom, years after the fact.