Autonomous Maritime Systems Are Scaling Faster Than the Engineering Frameworks That Support Them

The first unmanned surface vessel to complete a transatlantic crossing did so in 2021. By 2025, at least six commercial operators were running semi-autonomous vessels on established trade routes under remote supervision. Port automation programs at Rotterdam, Singapore, and Tianjin were handling container throughput with minimal human intervention in terminal operations. The U.S. Navy’s Ghost Fleet Overlord program had graduated from concept to program of record.

None of these programs were certified the same way. Most were not certified in any conventional sense at all.

Maritime autonomy is not waiting for a regulatory framework to mature. Programs are scaling, vessels are in service, and contracts are being signed — while the engineering discipline that should underpin all of it is being improvised in real time. That improvisation is producing both impressive engineering ingenuity and some systematic gaps that the sector will eventually have to close.

What’s Actually Deploying

The autonomous maritime sector is not a monolith. Three distinct deployment categories are each creating different engineering demands.

Unmanned Surface Vessels (USVs) range from small ocean data-collection platforms like Saildrone’s 23-foot wind-and-solar-powered vehicles to large defense platforms like L3Harris’s Sea Hunter-class persistent ISR vessels. The engineering challenge here is primarily around long-duration autonomy — the vessel must handle weather variability, collision avoidance under COLREGS, propulsion fault management, and payload operations over weeks or months without human intervention on board.

Autonomous Underwater Vehicles (AUVs) present a different problem set. Communications latency underwater is not a matter of network bandwidth — acoustic modems operate at kilobits per second, and GPS is unavailable below the surface. AUV programs from companies like Kongsberg, Saab, and HII’s Hydroid division are building autonomy stacks that must operate in near-total communications isolation, which pushes decision-making authority to the vehicle itself in ways that surface vessels and aircraft don’t require.

Port Automation is the highest-volume application by deployed unit count. Automated stacking cranes, autonomous guided vehicles (AGVs) in terminal yards, and remote-operated ship-to-shore cranes are mature technology — Rotterdam’s Maasvlakte II has operated automated container handling since 2014. The newer challenge is integrating vessel-side systems (berth approach automation, mooring assist systems) with shore-side infrastructure, creating cross-boundary system interfaces that span organizational ownership.

Each of these domains shares a common trait: they are operating ahead of the standards that would normally govern them.

The Regulatory Gap Is Not a Temporary Condition

In aviation, DO-178C governs airborne software. DO-254 governs complex electronic hardware. The FAA won’t certify an aircraft without compliance artifacts for both. In automotive, ISO 26262 defines functional safety for road vehicles, and SOTIF (ISO 21448) addresses the newer problem of safe intended functionality in autonomous systems. In rail, EN 50128 and EN 50129 provide equivalent coverage.

Maritime has the International Maritime Organization. The IMO published its MASS (Maritime Autonomous Surface Ship) regulatory scoping exercise in 2021, which identified which existing instruments apply and which have gaps. The result was a framework for developing new regulations — not a certification standard. The IMO’s target for a goal-based MASS code is 2028, and that timeline has already slipped. Individual flag states — Panama, Marshall Islands, Cayman Islands — are issuing voyage-specific approvals for autonomous vessels under existing frameworks that were not designed with autonomy in mind.

The practical effect is that companies building autonomous maritime systems are writing their own standards. They typically draw from:

  • IEC 61508 (functional safety for electrical/electronic/programmable systems) — the baseline safety integrity level framework that most engineering teams default to when nothing domain-specific exists.
  • DO-178C — borrowed for software considerations, particularly in defense maritime programs where the prime contractors have aviation heritage.
  • ISO 21448 (SOTIF) — increasingly referenced for the specific problem of operational design domain definition and out-of-domain detection, which is a genuine architectural challenge for AUVs operating in variable sea states.
  • NATO STANAG 4754A — for defense programs integrating with allied interoperability requirements.

The problem with self-selected standards is not that the individual standards are bad — IEC 61508 is a rigorous framework. The problem is that when no external authority validates the selection, programs have no forcing function to apply them consistently. A program that selects IEC 61508 SIL 2 for its autonomy stack because it sounds appropriate, without working through a proper hazard analysis to justify that selection, has a document trail that looks like compliance without the engineering substance.

Interface Complexity as a First-Order Engineering Problem

Shore-based control infrastructure for autonomous vessels is not an afterthought — it is half the system. A USV operating at sea under remote supervision has two distinct operational modes: fully autonomous (following a pre-planned mission profile with onboard decision-making) and supervised (where a human operator at a shore control station can intervene, redirect, or override). The interface between these modes is where many of the hardest engineering problems live.

Consider the requirements surface this creates:

  • Communications link requirements must specify degraded-mode behavior. What does the vessel do when the Iridium link drops? What actions are permissible in link-loss conditions? What is the maximum allowable latency before the vessel defaults to a safe state? These are safety-critical requirements that span vessel hardware, software, communications infrastructure, and shore-side operator procedures.

  • Human factors requirements for shore-based control centers are largely unaddressed by existing maritime regulation. Aviation has extensive human factors standards for controller workload, display design, and alerting — maritime equivalent standards for remote vessel operators are nascent. Companies building these systems are writing their own human factors requirements, often citing EASA or FAA human factors guidance by analogy.

  • Operational Design Domain (ODD) requirements must specify the conditions under which autonomous operation is permitted. This is a concept borrowed from automotive Level 4 autonomy — it specifies the environmental envelope (sea state, visibility, traffic density, geographic bounds) within which the autonomy stack is validated to operate. Violations of the ODD boundary must be detected and responded to, which creates additional requirements for environmental monitoring and mode management.

Each of these requirement clusters creates interface control documents and cross-system dependencies that multiply across development teams. A program with a vessel engineering team, an autonomy software team, a communications infrastructure team, and a shore-side operations technology team needs to maintain consistent, bidirectional traceability between all of them. That is not a problem a shared document repository solves.

How Programs Are Building Rigor Without a Roadmap

The most sophisticated programs in this space are not waiting for the IMO. They are building engineering rigor through a combination of borrowed standards, internal certification frameworks, and — critically — engineering process discipline that would survive external scrutiny if scrutiny eventually arrives.

The Norwegian Maritime Authority has been the most aggressive national regulator in this space, issuing technical guidance for autonomous and remote-controlled vessels in collaboration with companies like Kongsberg Maritime and Wilhelmsen. The UK Maritime and Coastguard Agency issued interim guidelines in 2023. In the U.S., NAVSEA is developing internal autonomy standards for USV programs under the auspices of its Maritime Autonomous Systems (MAS) program office — but these are defense-specific and not publicly available.

Several engineering practices are emerging as consistent across leading programs:

Hazard analysis before architecture. Programs that build their safety architecture around a structured HAZOP or STPA (System-Theoretic Process Analysis) exercise, rather than retrofitting safety arguments to existing designs, produce more defensible safety cases. STPA, developed at MIT, is particularly well-suited to autonomous maritime systems because it addresses control-theoretic failures — the kind that arise from unexpected interactions between autonomous decision-making and human operators — rather than just component failures.

ODD as a first-class engineering artifact. Leading programs treat the Operational Design Domain as a formally managed requirement, not a prose description in a concept of operations document. This means the ODD has a version history, is linked to test evidence, and drives both the autonomy architecture and the monitoring subsystem design.

Living traceability. The pace of regulatory change in this space means that requirements will be revised — often — as standards mature. Programs that manage requirements in tools where links to design artifacts and test records are maintained automatically are better positioned to respond to those revisions than programs that manage requirements in Word documents with manual RTM spreadsheets. When the IMO eventually publishes a MASS code and programs need to demonstrate compliance, the gap analysis task is either a matter of hours or a matter of months, depending on whether traceability was maintained throughout development.

This is the context in which modern requirements management platforms are genuinely relevant — not as document repositories, but as systems that maintain the semantic relationships between requirements, design, and verification evidence. Tools like Flow Engineering, which use a graph-based model to represent these relationships natively, allow maritime autonomy teams to query their traceability across system boundaries: which shore-side control requirements are linked to onboard autonomy behaviors? Which ODD conditions have test coverage? Which requirements are affected if the communications latency threshold changes? These are not questions a flat document can answer without substantial manual effort.

Where the Engineering Gaps Still Live

Honest assessment requires naming what is not working.

Safety case methodology is inconsistent. Some programs are producing rigorous Goal Structuring Notation (GSN) safety cases. Others are producing what amount to compliance checklists dressed up in safety case language. Without an external authority reviewing these artifacts, there is no mechanism to distinguish between them from the outside.

Human factors is the weakest link. Shore-based control center design for multi-vessel supervision is a genuinely unsolved human factors problem. How many vessels can a single operator supervise? What cognitive load does a degraded-link condition create? What display architecture supports rapid situation awareness across heterogeneous vessel types? Programs are answering these questions empirically — by building systems and watching how operators perform — rather than from a validated design framework.

Cross-organizational interface management is still largely manual. Even programs using modern requirements tools often revert to ICD (Interface Control Document) spreadsheets at the boundary between vessel and shore. The organizational seam between a shipbuilder and a control center integrator is frequently where engineering discipline degrades, because neither party has authority to mandate the other’s toolchain.

The Honest Outlook

Maritime autonomy will have a proper regulatory framework eventually. The economic incentives — fuel savings from weather-optimal routing, crew cost reduction, insurance rating improvements for vessels with verified safety systems — are large enough that industry and regulators will be forced to converge. The IMO’s MASS code, whenever it arrives, will give programs a fixed certification target.

When that happens, the programs that built genuine engineering rigor — real hazard analysis, formally managed ODDs, maintained traceability between requirements and evidence — will have a material advantage over programs that assembled compliance-looking artifacts without the underlying substance. The former can demonstrate safety. The latter will need to rebuild their documentation.

The absence of a certification roadmap is a genuine problem. It is also, for engineering teams willing to invest in disciplined practice now, a temporary one.