Features

Organize every piece of machinery on your fleet using an unlimited-depth hierarchy: Categories group equipment families, Equipment nodes represent physical assets, and Sub-Equipment handles components within a unit. Each maintenance definition and its triggers attach directly to the equipment they govern, creating a single navigable tree that mirrors your vessel's actual arrangement.

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

Every maintenance definition can carry two independent triggers simultaneously: a calendar-based interval measured in days, and a running-hours-based interval measured against a counter. Both triggers are evaluated continuously, and whichever threshold is reached first drives the next due date calculation.

The "show-only-in-range" visibility window (defaulting to 70% of elapsed interval) controls when a task surfaces in planners' views — so the maintenance list never floods with far-future jobs. Counter-type overhauls reset the running hour counter upon completion, ensuring recurrence is calculated correctly after major maintenance events.

Completed maintenance passes through a configurable four-stage sign-off chain: Ship Responsible, Ship Approver, Company Reviewer, and Company Approver. Each stage independently configures its execution method — All (every designated person must approve), One (any single designee suffices), or NotRequired (stage is bypassed entirely).

The seven-status workflow (Waiting, In Progress, Waiting for Ship Approval, Waiting for Office Approval, Ship Not Approved, Office Not Approved, Office Approved) captures every position in the pipeline. This architecture accommodates everything from single-vessel operators who bypass all approval stages to large fleet managers who require dual office sign-off on every maintenance record.

When a maintenance task is executed, a Maintenance Log captures the full record of what was done. The log includes work description, crew assignments from 29 supported ranks across Deck and Engine departments, five attachment types (Diagram, Photo, Manual, Form, Other), and structured approval tracking. A distributed lock prevents concurrent starts of the same job.

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

Electrical insulation testing (megger testing) demands precision beyond a simple pass/fail checkbox. Navatom captures all six resistance readings — RS, ST, RT, RE, SE, and TE — alongside ampere and voltage values, measurement condition (cold or hot), and the final determination (pass or fail). Every reading is stored as a structured numeric record rather than a free-text note.

This purpose-built data capture ensures your electrical survey records are machine-readable, trend-able, and immediately presentable to class surveyors. A separate Megger Tests list view aggregates all test results across the fleet for cross-vessel trend analysis.

Running hour counters form the backbone of counter-based maintenance scheduling. Crew enter readings directly via dedicated ship-side entry forms, or approve officer-submitted readings through a structured request/approval flow. A full Running Hour Logbook maintains the complete chronological record of every counter value ever recorded.

For vessels equipped with compatible third-party monitoring systems, the automation layer accepts pushed counter data without manual entry, eliminating transcription errors and ensuring trigger calculations always use the most current machinery state.

The Equipment Explorer presents the hierarchical equipment tree on the left alongside a contextual detail panel on the right, allowing superintendents and chief engineers to navigate the entire PMS structure without losing their place. Selecting any node in the tree instantly loads its equipment details, maintenance definitions, running hour history, and spare parts in the right panel.

High-performance server-side rendering handles fleets with tens of thousands of equipment records and hundreds of thousands of maintenance definitions without browser memory constraints. Twelve composable query filters allow any combination of equipment type, status, category, vessel, and date range to surface exactly the records needed.

When operational reality prevents executing a maintenance task on schedule, the postponement workflow captures exactly why and by how much. Three postponement types — Dry Dock (deferred to the next scheduled drydock period), To Date (explicit new due date), and Additional Work Hour (counter-based extension) — cover every legitimate scenario.

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. Postponement requests go through an approve/reject workflow before the due date changes, creating an auditable record of every schedule deviation.

Track every period an equipment item is unavailable, classifying each event as Planned or Unplanned. Planned downtime covers scheduled overhauls, drydock periods, and dry-run maintenance windows. Unplanned downtime captures breakdowns, failures, and emergency stops.

Monthly downtime distribution charts give technical superintendents fleet-wide visibility into availability trends. Linking downtime events to the parent equipment record — along with related deficiencies and maintenance logs — allows correlation between downtime patterns and maintenance history, surfacing recurring failure modes that demand preventive action.

Every equipment item carries its own spare parts Bill of Materials linking directly to the Material module's catalog. Each spare part link assigns a criticality level — VITAL, ESSENTIAL, or DESIRABLE — giving procurement teams instant priority classification without consulting separate systems.

This bidirectional integration means that when a maintenance job is planned, the spare parts required are already listed against the equipment. Procurement can generate purchase requisitions directly from the BOM without manual part number lookups. Conversely, when a part arrives in Inventory, the equipment it supports is immediately visible.

When a maintenance task passes its due date without completion, the system demands a structured explanation. Twenty-one overdue reason codes span seven categories: PMS (definition or scheduling errors), Operation (voyage and operational constraints), IMS (inventory and spare part issues), ThirdParty (contractor or survey delays), Crew (personnel or competency issues), Software (system-related causes), and Computer (hardware or connectivity problems).

This taxonomy transforms overdue reporting from a binary "late/not late" metric into a fleet reliability intelligence tool. Aggregate by reason category to distinguish systemic planning failures from one-off operational disruptions, and target corrective efforts where they will have the greatest impact.

Company designs the PMS structure — equipment categories, equipment items, maintenance definitions, triggers, and assignments — in the office Structure editor. When the design is ready, a single Publish action deploys the entire structure to the target vessel, synchronizing definitions over satellite or broadband connections.

Ship-side deployments merge incoming structural changes without disturbing in-flight maintenance logs. Bidirectional synchronization uses conflict resolution rules that always preserve completed maintenance records. Vessels operate independently when needed, with changes merging automatically when connectivity is available.

Maintenance definitions can trigger child definitions automatically. When a parent maintenance is completed, its child tasks become active — enabling multi-step maintenance procedures where a performance test follows an overhaul, or a visual check follows a calibration.

The trigger chain uses a parent-child hierarchy, where parent definitions list their triggered children and children reference their triggering parent. Child maintenances appear in the maintenance list with clear parent linkage, so crew know exactly which higher-level job they are supporting.

Equipment criticality in Navatom is not a single binary flag. Each equipment item carries two independent criticality dimensions: critical (operational criticality to the vessel) and classCritical (criticality from the classification society's perspective). These two dimensions are evaluated separately and can diverge.

This distinction matters for maintenance prioritization and survey planning. Class-critical equipment demands class-traceable maintenance records and defined intervals. Operationally critical equipment demands higher postponement scrutiny. Filtering and analytics respect both dimensions independently.

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 multiple purposes: class society surveys, insurance claims, flag state inspections, and internal performance analysis. Because the archive is immutable and comprehensively logged, any reconstruction of what happened — and when, and by whom — is possible years after the fact.

Office-side reviewers and approvers work from a dedicated Approval Queue that aggregates all maintenance logs awaiting their action across the entire fleet. A single view surfaces every pending record, with filtering by vessel, equipment category, maintenance type, and urgency.

Approval actions — accept, reject, or return for correction — are executed directly from the queue without navigating into individual vessel records. Rejected logs automatically notify the originating ship with the rejection reason, feeding back into the ship-side correction workflow.

Ten dedicated dashboard widgets provide real-time KPIs for 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 into the underlying maintenance records.

The Analytics section surfaces aggregate views across the fleet — overdue trend analysis by vessel, overdue breakdown by maintenance type and crew rank, and crew task distribution by department. These views give technical superintendents the intelligence to move from reactive firefighting to proactive fleet reliability management.

The PMS tree is not built from scratch for every vessel. Category trees and equipment structures are importable and exportable between vessels, enabling rapid fleet-wide deployment of a standard PMS template. The import process validates incoming data against the current schema before committing, preventing corrupt structures from reaching production.

Deep copy functionality allows any branch of the equipment tree — including all maintenance definitions, triggers, spare parts BOMs, and running hour configurations — to be duplicated from one vessel to another. This is essential for managing sister ships and near-identical vessel classes without manual re-entry.