AI system for autonomous ships: from perception to certification

Autonomous Vessel: Where Situational Awareness Breaks Down

An autonomous vessel operates in an environment where the situation changes faster than the world model updates: a tug leaves the berth, a small craft does not identify itself on air, reflections from concrete return with delay.

Perception here is not “vision” but a decision-making loop on incomplete data, and it usually breaks not on the open sea but at mode boundaries: on approach, in narrow waters, and during mooring.

The first point of failure is sensor fusion.

Radar, lidar, cameras and a satellite navigation receiver update at different rates and weather rain, glare and hull shadow differently; when timestamps and calibration between sources diverge, one object arrives as two targets or does not arrive at all.

Perception robustness rests not on the most sensitive sensor but on the consistency of loops and on an explicit description of which source the system trusts in which situation.

A separate trouble is false detections at the berth. Reflections from the wall, crane and moored vessels produce phantom targets: tracking follows objects that are not there, the obstacle count grows, and the planner goes into cautious braking instead of movement.

If you simply raise thresholds, the next voyage will miss a real object, and the cost of these errors is asymmetric — therefore behavior is built into architecture, not tuning.

In narrow waters the scene changes in jerks: a near object occludes a far object, targets overlap, and target tracking failure occurs — motion history is lost, the object opens anew.

Worst of all when this coincides with mooring mode: automation drops out and hands control to the operator at the most loaded moment. Next we break down how this is closed — from data fusion to the control handback procedure.

Measurable Effect: Failures, Downtime, Manual Control

The effect has to be checked not by feel but by the event log: a perception system can be considered tuned only when its contribution is visible in numbers. We take the set of metrics below both from the vessel and from the shore loop — stages of work are accepted by them too.

• False alarm rate. We count not the absolute number of detections, but their frequency per hour of travel separately by each obstacle type: after threshold tuning and trajectory-based target filtering, detections on waves and spray go away, real objects remain.
• Number of manual interventions per transit. Each switch to remote control is analyzed by cause; the goal is to leave interventions only for scenarios pre-defined as non-standard.
• Downtime window. Time from sensor failure to return to automatic mode is measured on the test bench, not on the voyage — that way it is reproducible and independent of weather.
• Eliminated failure class. We record which failures no longer cause loss of automation: channel desynchronization, degradation of an individual sensor, short-term communication loss.
• System availability. Share of time when the control loop is available in full configuration, accounting for redundancy and scheduled maintenance.

Metrics are embedded in the acceptance test program and in reports under Rules for the Classification of Autonomous Ships: the customer receives not a presentation but a protocol showing exactly what changed relative to the initial state and on which route segment.

Automation Levels: Comparison of Operating Modes

We compare automation modes not by the “smartness” of algorithms, but by how much responsibility the system takes from the crew and what it must do on failure.

Therefore crew prompts, route autopilot and full autopilot are different requirements for sensors, redundancy and the number of people in the control loop.

Hardware redundancy sets the boundary of the mode, not vice versa: duplication of sensors, computers and communication channels determines whether the system will have time to hold course before human intervention or immediately hand over control.

We formulate mode limitations before development starts — otherwise during testing every failure turns into an unaccounted scenario, and the scope of rework grows with it.

Implementation Stages: From Audit to Handover to Crew

Implementing an autonomous vessel is not installing a “smart” box, but a sequence of stages where each next one removes the risk of the previous one.

Until hull lines, navigation modes and the nature of the route are understood, any sensor placement scheme remains a guess, and a trained model is a hypothesis test on water.

Below is how we run a project from the first boarding to the moment when the crew works with the system under standard regulations.

1. Vessel and route audit. We inspect hull, power system, steering and standard systems, record vibrations and conditions on the bridge. In parallel we describe the route profile: narrow waters, depths, traffic intensity, areas with unstable communication. Output — a risk map and a list of situations where automation must yield to the human.

2. Sensor placement scheme. We calculate coverage, overlaps and blind zones behind superstructures, choose installation points accounting for wash and spray protection. We agree the scheme before installation: moving a sensor after mounting means new cable routes and recalibration.

3. Installation and calibration. We bring data from different sources into a unified coordinate system, synchronize timestamps, check accuracy on the bench and during mooring trials. An error in fusion here turns into false detections at speed.

4. Data collection and labeling. We record reference runs in different modes and weather, then label objects, distances and trajectories. Separately we collect rare scenarios: small craft without identification, floating debris, head-on passing in narrow waters.

5. Model tuning. Training runs on the labeled dataset, validation on held-out runs the system has not seen. We tune detection thresholds and safe-failure logic: when uncertain, the system reduces speed and stops rather than “guessing” the situation.

6. Acceptance tests. The program is drawn up in advance: first scenarios at the test site, then full-scale runs along the route, simulation of sensor failure and communication loss. Each scenario has its own pass criterion, and we do not move to the next until it is met.

7. Handover to crew. We train watch officers, provide regulations, action maps for failures and the procedure for reviewing recordings. We accompany the first runs, then the crew works independently, and we remain in contact under support regulations.

Describe the vessel, route and required level of autonomy — we will return with an assessment and a stage plan.

What Remains On Board: Documentation and Regulations

An autonomous vessel system lives not only in code. When the vessel leaves the zone of confident communication with shore, decisions are made by the crew, and they are checked by the classification society — by papers.

Therefore we assemble the documentation package in parallel with development and hand it to the customer, not “write it later.” Below is what remains on board and in the shore office.

• System configurations — settings files by operating loops: which modules are active, detection thresholds, modes for port, transit and open water, behavior during sensor degradation.
• Placement diagrams — binding of sensors, computing units, coverage zones and connection points to hull drawings: what is where, how to access for service, where routes run.
• Access policies — user roles, who may change setpoints, who only reads the event log, the procedure for granting contractor rights and rules for work in port.
• Crew instructions — actions when an alert triggers, procedure for switching to manual control, regulations for loss of communication with shore.
• Maintenance regulations — frequency of checks, sensor calibration, optics cleaning and consumables replacement, with a result recording form.
• Failure and review log — typical faults, what was done, what effect it led to: a base for quickly training new shifts.
• Compliance matrix — linkage of classification society requirements to specific functions and checks, with the responsible person indicated.
• Update and rollback plan — how a new version is deployed and how to return to the previous one without losing configuration.

Case: Autonomous Vessel on a Regular Route

A regular route is a convenient proving ground for autonomy: constant leg, mooring at the same points, predictable weather windows. Telemetry of each voyage here is reviewed the same evening, not a month later.

Before Implementation

The vessel followed the route, but the shore center operator took control 45–50 times per 100 transits. Three quarters of episodes — one class of perception failures: false obstacle on water glare, loss of a small craft mark in backlight. Each intervention added 4–6 minutes to the berth downtime window and shifted the entire schedule.

What Changed

Perception was separated into independent channels — radar, optical, thermal — and temporal verification was added: an obstacle is confirmed only if it persists across several consecutive observations. False detections are filtered out before the decision-making loop.

Control handover regulations were described in advance: under which conditions the vessel must request a human and how it returns control.

Result

Manual interventions decreased to 9 per 100 transits, the share of voyages without a single touch of controls grew from 31% to 84%. The berth downtime window shrank from 6 to 2 minutes: mooring follows one trajectory and is not recalculated on the move. The perception failure class did not occur once during the reporting period.

The runs became an evidence base for DNV: voyage logs, intervention reviews, operating conditions matrix. This is what allows route expansion without rebuilding the system.

How Does Crew Assistance Differ from Route Autopilot?

Crew assistance and route autopilot are two different contracts for responsibility, not two levels of one function. In the first case the system proposes course and speed, the decision is confirmed by the watch officer, and control remains with the human.

In the second case the loop is closed by the system, and the crew observes with limited time to intervene.

This leads to different sensor requirements. Prompts need only a navigation suite and surveillance means in one channel. Autopilot needs redundancy: two satellite navigation receivers with correction, radar target detection channel, optical surveillance, inertial unit.

Reliability is calculated per channel — on divergence the system declares degradation rather than averaging estimates.

Practical consequence for the project: the composition of redundancy and the scope of the evidence base are determined not by function, but by the declared level of responsibility.

Therefore at the start we fix which route segments are under autopilot and which remain crew assistance — architecture, test program and certification preparation timelines depend on this.

Doubts and Limitations: Sensors, Weather, Communication

Fog does not blind the system but changes the set of operating channels: radar and the thermal loop see targets when cameras lose contrast.

In waves it is harder — roll gives false horizon motion, so estimates are smoothed by inertial data, and course is calculated relative to water.

Boundaries remain: a small vessel without reflectors in dense fog is a known risk, and it goes into the list of limitations, not into the presentation.

Loss of communication with shore is a standard scenario: the vessel follows a preloaded policy, passes according to IMO rules and goes to a waiting point if safe continuation is impossible.

Modernization of an already built hull is also realistic — mast for sensors, cable routes, power and cooling are installed on site; timelines are determined by approval of changes with the classification society, not by the equipment itself.

Can the system be installed on a vessel already in operation?

Yes, this is the main scenario. We start with a survey: free areas, permissible mass and wind load, power reserve, condition of routes. Then — placement scheme and list of hull modifications for approval with the society.

Let's Discuss the Task: Assessment and Implementation Plan

Assessment of an autonomous vessel does not come from a price list — it is derived from the navigation scenario, sensor composition and regulator requirements. To return with an implementation plan, not a range “from and to,” engineers need inputs; usually one email is enough.

What to send to start:

• Operating scenario: vessel type, route, navigation area, weather conditions, modes from mooring to passing.
• What is already on board: sensor suite, control system, available connection interfaces.
• Classification society and flag requirements: applicable rules and form of evidence base.
• Data: voyage logs, sensor recordings, labeled fragments — what is available and in what volume.
• On-board computer constraints: power consumption, thermal mode, available resource.
• Acceptance criteria: target metrics for object detection, false detections, response time.
• Existing work: prototypes, models, benches and simulators.

In response we will return with an implementation plan: break down the scope of work by stages — data preparation and labeling, training perception models, integration with the control system, testing on a simulator and at sea, preparation of the evidence base for certification — and indicate timelines of each stage with acceptance points. Describe the task and attach what you already have: we will discuss what to focus on first.