SEA ARROW [VOLUME 1]: Engineering the Post-RMA Surface Fleet

Engineering the Post-RMA Surface Fleet

Speed, Modular Payload, Resilient Autonomy and the Future of Maritime Systems

VOLUME I – FLAGSHIP SYSTEM ARCHITECTURE

Manuscript Assembly v1.0

Executive Summary

Sea Arrow is a proposed next-generation autonomous maritime surface system designed to explore a capability gap between small uncrewed surface vessels and large crewed warships.

Small USVs can be distributed, specialized and relatively easy to deploy in numbers, but they often become constrained by payload, electrical power, range, sea keeping, communications dependence and repositioning speed. Large warships solve many of those problems through scale, but they are expensive, crew-intensive, geographically finite and unnecessary for many distributed sensing, relay, survey, logistics or support tasks.

Sea Arrow explores the space between those two extremes. Its design hypothesis is that a maritime force may gain useful new options from a medium-sized autonomous surface node combining meaningful modular payload, unusually high selective mobility, several distinct operating modes, strong local vehicle control, degraded-network resilience and re-coverability after selected failures.

The current controlled baseline is approximately:

21.95 m / 72 ft length;
12,888 kg controlled full-load target;
1,600 kg modular payload allowance;
approximately 2,000 L working fuel assumption;
twin Mercury Racing 1550/1350 main engines;
100-knot primary high-speed engineering target;
120-knot stretch region;
130+ knot research region;
P1 practical electric low-speed propulsion;
P2 experimental magnetohydrodynamic propulsion research;
autonomous / uncrewed operation;
local real-time vehicle control;
bounded mission autonomy under human authority;
independent safety-governor logic;
graceful degraded-return architecture.

These figures define the current engineering concept. They do not represent a completed or sea-trial-proven production vehicle. The 100-knot objective remains a target, not a demonstrated result.

The Operational Problem

Maritime forces are increasingly best understood not as collections of isolated ships, but as systems of interconnected crewed and uncrewed nodes. A future maritime system can include crewed surface vessels, uncrewed surface vessels, aircraft, unmanned aircraft, underwater systems, satellites, shore facilities, communications relays, distributed sensors and logistics networks.

How should capability be distributed across many physical nodes so that the overall maritime system becomes more flexible, geographically distributed and resilient?

Large ships remain essential because they can carry substantial fuel, power, sensors, command capacity, personnel, maintenance and payload. But a large platform cannot physically occupy several distant locations at once. Small autonomous nodes can add geographic presence, but they may be too slow, too lightly powered or too payload-constrained to fill every distributed role. Sea Arrow is intended to investigate whether a useful middle layer exists.

Speed as a System Capability

Sea Arrow treats speed as time-distance compression rather than spectacle. A sensor, relay or payload cannot be digitally transmitted from one ocean location to another. It has to move.

DISTANCE
/
REPOSITIONING SPEED
=
TIME UNTIL CAPABILITY ARRIVES

The Sea Arrow hypothesis is not that the craft should travel everywhere at maximum speed. It is that high-speed repositioning may become valuable when time matters enough to justify the energy cost.

One Vehicle, Several Operating Personalities

QUIET / LOW-SPEED
|
v
NORMAL TRANSIT
|
v
HIGH-SPEED REPOSITION
|
v
SPRINT
|
v
DEGRADED RETURN

Quiet or low-speed mode emphasizes precise maneuvering, sensing and reduced machinery disturbance. Transit emphasizes range and fuel efficiency. High-speed repositioning emphasizes time-distance compression. Sprint exists only inside a separately validated envelope. Degraded return changes the objective from mission completion to preservation and recovery of the craft.

The Complete Vehicle

The present Sea Arrow concept is a carbon-composite tunnel catamaran. Its twin hulls and central tunnel are part of the dynamic support system. At low speed, buoyancy dominates. At very high speed, running wetted area must fall and the craft becomes a coupled hydrodynamic-aerodynamic system.

Two reconstructed CFD-ready candidates, A-R0 and C-R0, define the next comparison. Each is scheduled for analysis at 60, 80 and 100 knots. Those simulations have not yet been executed, and the final dynamic hull remains open.

Mass, Payload and Range

The controlled full-load target is 12,888 kg, including a 1,600-kg modular payload allowance. The payload is not treated as spare weight. Each mission module affects mass, center of gravity, structure, electrical power, cooling, data interfaces, electromagnetic compatibility, maintenance and the allowable operating envelope.

Change the mission without redesigning the vehicle.

The broader project objective includes at least 300 nautical miles of efficient-high-speed range with mission reserve, but that range has not yet been demonstrated. Final range closure depends on the selected dynamic hull, actual drag, propeller, drive ratio, fuel flow and mission profile.

Modular Mission Architecture

Potential mission families include maritime sensing, communications relay, hydrographic and oceanographic survey, search-and-rescue support, emergency logistics, support to other uncrewed systems, passive electronic-support sensing and experimental technology packages. Vehicle control, safety, essential navigation, propulsion control and fault management remain protected core functions rather than mission-module functions.

INDEPENDENT SAFETY GOVERNOR
+—-> LIMIT / VETO / DEGRADE

The network should increase capability, not become a prerequisite for immediate physical survival. Human authority remains above the mission layer. Mission autonomy operates inside defined bounds. Fast stabilization remains onboard.

Failure and Degraded Return

The goal is not to claim that every failure is survivable. It is to design the system so that selected failures remove capability before they remove the entire vehicle.

Build a Family, Not a Hero Vehicle

Sea Arrow is intended to become a common family of interoperable maritime nodes rather than one exceptionally complicated craft. Common hull, propulsion, power architecture, vehicle control, safety architecture, navigation, diagnostics, maintenance philosophy and mission interfaces should remain stable where practical, while mission specialization occurs through controlled modules.

The objective is not the most capable individual craft. It is the most useful family of interoperable maritime nodes.

Current Truth State

Sea Arrow is currently a developed engineering architecture. It is not yet a demonstrated operational vehicle. The project has a coherent system architecture, controlled mass and payload targets, CFD-ready A-R0 and C-R0 hull candidates, propulsion and quiet-mode architectures, electrical, thermal, acoustic and materials logic, layered control and safety concepts, degraded-network and degraded-return logic, a modular mission system and a defined verification pathway.

The following remain unresolved or unproven:

transient high-fidelity CFD for the six A-R0/C-R0 cases;
final dynamic hull selection;
validated 100-knot performance;
validated 300-nmi range;
final propeller and drive ratio;
complete dynamic stability envelope;
complete structural FEA closure;
final P1 hardware and validated acoustic performance;
demonstrated operational benefit from MHD;
integrated prototype testing and progressive sea trials;
multi-vehicle fleet experiments.

The Development Path

Do not optimize downstream systems against geometry that has not closed.

The Sea Arrow Hypothesis

Can a future maritime force gain useful new operational options from a family of fast, modular, locally resilient autonomous surface nodes without turning each node into an unaffordable miniature warship?

Sea Arrow is one proposed answer. Its significance will be established by whether the complete system survives the progression from simulation to component test, subsystem test, prototype, sea trial, repeatability and multi-vehicle operation.

Opening – The Question

Why build another autonomous maritime system?

That is the wrong question if it is asked as though the world needs one more unmanned boat simply because autonomy, sensors and software now make one possible. The useful question is harder:

What capability is missing from the future maritime force, and what kind of physical machine would have to exist to fill it?

Sea Arrow begins there.

The concept is not based on the assumption that existing warships are obsolete, that small unmanned surface vessels are inadequate, or that every future naval problem can be solved by automation. It starts from a different observation. Maritime forces increasingly operate as systems made from many different kinds of nodes: crewed ships, aircraft, satellites, unmanned aircraft, unmanned surface and underwater vehicles, shore facilities, sensors, communications links, logistics networks and command organizations. The usefulness of any one platform increasingly depends on how well it can contribute to that larger system.

Large crewed ships can carry enormous amounts of fuel, power, sensing, communications equipment and payload. They can remain at sea for long periods and perform many functions simultaneously. But they are necessarily expensive, limited in number and geographically finite. A ship cannot be in two places at once. Adding more capability to an already capable ship does not solve that basic problem.

Small autonomous systems attack the problem from the opposite direction. They can be distributed in larger numbers. They can perform specialized sensing, relay, survey, inspection or support functions without requiring a crew aboard every vehicle. But small systems introduce their own limits: payload, power, range, sea keeping, communications dependence and, for Sea Arrow, repositioning speed.

The Sea Arrow hypothesis is that there may be value in a medium-sized autonomous surface node with unusually high selective mobility, meaningful modular payload, several distinct propulsion and operating states, strong local vehicle control, and enough degraded capability to remain useful when parts of the supporting network fail.

The current Sea Arrow concept is approximately twenty-two metres long. Its controlled full-load design target is approximately 12.9 tonnes. It carries a 1,600-kilogram modular-payload allowance. Its high-speed architecture is based on two Mercury Racing 1550/1350 engines. A separate practical electric propulsion path is intended for low-speed, lower-disturbance operation. An experimental magnetohydrodynamic branch remains separate from the practical baseline. The principal high-speed target is 100 knots, with higher speeds treated as stretch or research regions rather than established capability.

Those numbers matter, but they are not the reason the machine exists. The more important question is what a surface system with those characteristics could do differently.

Higher mobility does not eliminate distance. It changes the time required to respond to it. That difference is the operational reason for investigating extreme surface speed.

Sea Arrow is therefore not designed around the proposition that maximum speed should be used continuously. Very high speed demands enormous power. Power demands fuel. Fuel adds mass. High power produces heat, vibration and acoustic energy. Dynamic loads increase. Control becomes more demanding. The usable sea-state envelope may narrow. Range can collapse if the vehicle spends too much of its mission at maximum output.

Use different physical states for different parts of the mission.

A low-speed mode can prioritize maneuvering, persistence and reduced machinery disturbance. A normal transit state can prioritize range and efficiency. A high-speed state can compress time when repositioning produces enough operational value to justify the energy cost. A sprint state can exist above that, but only inside a separately validated thermal, structural and stability envelope. And when equipment fails or environmental conditions exceed the primary mission envelope, the machine should change objectives again. At that point the mission may simply be to preserve the craft, retain navigation and control, and return.

This means the vehicle is not really one operating point. It is one physical architecture capable of moving among several controlled operating personalities.

If useful modular payload matters, payload cannot simply be treated as spare weight. Its mass, location, electrical demand, cooling requirement, data interfaces and structural attachment all have to be controlled. If degraded-network operation matters, communications cannot be part of the fast stability loop. If graceful return matters, one subsystem cannot be allowed to become the hidden root of the entire vehicle.

Every useful capability creates physical consequences elsewhere in the machine.

There is no free speed. No free payload. No free endurance. No free redundancy. No free autonomy. No free quietness. The design becomes credible only when those costs are carried openly by the rest of the architecture.

That is also why Sea Arrow is being developed as a modular maritime node rather than as a small ship carrying every conceivable naval function. The 1,600-kilogram payload allowance is potentially more valuable as an interface than as a fixed payload.

If the common hull, machinery, control architecture, safety system and mission interfaces can be kept stable, Sea Arrow does not have to remain one craft. It can become a family: a sensing node, a relay node, a survey node, a logistics node, an unmanned-systems support node and an experimental node.

The interesting unit then stops being the individual vehicle. It becomes the distributed maritime system made from interoperable vehicles.

Sea Arrow is not yet a demonstrated 100-knot autonomous craft. The current work has produced a coherent vehicle architecture, a controlled mass model, recovered hull-family constraints, two new reconstructed CFD-ready geometries, first-principles power and hydrodynamic screens, propulsion and quiet-mode architectures, thermal and materials logic, layered control and safety concepts, and a defined verification program. But the dynamic hull has not been selected, the final high-speed propeller and drive ratio are not closed, the 300-nautical-mile range objective has not been demonstrated, the structural design has not passed complete FEA, P1 has not been bench-qualified, P2 remains research, and no integrated prototype has completed progressive sea trials.

Can a future maritime force gain useful new operational options from a family of fast, modular, locally resilient autonomous surface nodes – without turning each node into an unaffordable miniature warship, and without making the system dependent on perfect communications, perfect autonomy or unproven technology?

Sea Arrow is one proposed answer. The remainder of this volume develops that answer from the outside inward and ends with the engineering sequence required to find out whether the concept survives contact with the water.

PART I – THE OPERATIONAL PROBLEM

1. The Surface Fleet Is Becoming a Network

1.1 From Individual Platforms to Distributed Maritime Systems

The surface fleet is no longer best understood only as a collection of individual ships. It is increasingly useful to think in terms of a distributed maritime system: crewed platforms, uncrewed surface systems, air and subsurface nodes, offboard sensing, communications and data exchange, and mission functions spread across multiple physical locations.

This does not make the individual platform unimportant. It changes the question asked of the platform. Instead of asking only what a ship can do by itself, the system asks what physical function the node contributes, where that node can be placed, how quickly it can move, what it can carry, how it communicates, and what remains possible when other parts of the network disappear.

1.2 Why Large Platforms Cannot Be Everywhere

Large ships solve hard problems through scale. They carry fuel, power, sensors, communications, people, repair capability, stores and multiple payloads. But they are expensive, crew-intensive, finite in number and physically confined to one location at a time.

Geography therefore remains a hard constraint. A highly capable ship cannot be in two places at once. Concentrating more capability into one hull does not eliminate that fact. Distributed operations require more physical nodes if the force needs simultaneous presence across a wide maritime area.

1.3 Why Small Autonomous Nodes Matter

Small autonomous nodes matter because they add physical presence without requiring every location to be occupied by a major crewed platform. Their value can come from position as much as from raw payload. A modest sensor in the correct place can be more useful than a more capable sensor far away. A relay located where it restores connectivity can have disproportionate value. A small survey or logistics platform can extend the reach of the larger system.

Distribution therefore creates a different form of capacity: more places can be occupied, more local measurements can be made, and more functions can be separated instead of being forced onto one hull.

1.4 The Network Dependency Problem

Distribution introduces a new weakness: dependence on communications, navigation and external information. A remote vehicle can become fragile if it requires a continuous link merely to remain stable or controllable.

Sea Arrow therefore separates network-dependent mission functions from non-network-dependent physical control. High-level mission updates, external sensing and coordination may come from the network. Fast stabilization, propulsion control, steering, safety and fault response stay onboard.

HUMAN AUTHORITY
|
v
MISSION OBJECTIVES + LIMITS
|
v
MISSION AUTONOMY
|
v
LOCAL VEHICLE CONTROL
|
v
PHYSICAL VEHICLE

INDEPENDENT SAFETY GOVERNOR
+—-> LIMIT / VETO / DEGRADE / RETURN

At 100 knots the vehicle would travel about 51.44 m/s. Immediate control therefore cannot wait on distant communications. Local deterministic control is not optional; it follows from the physics of the vehicle.

1.5 The Mobility Problem

A distributed node is useful only where it physically exists. Slow surface systems can provide excellent persistence, but repositioning across maritime distances may consume hours. Geography can therefore change faster than the node can move.

Mobility becomes a system capability because it determines how quickly sensing, relay, payload or replacement capacity can become useful in a new location.

For an illustrative 100-nautical-mile move:

10 kt -> 10 hours

20 kt -> 5 hours

40 kt -> 2.5 hours

80 kt -> 1.25 hours

100 kt -> 1 hour

These are not operational predictions. They simply show how speed changes the time-distance relationship.

1.6 The Missing Capability

The resulting requirement is broader than speed alone.

The fleet needs a distributed surface node that can carry useful payload, move rapidly when required, operate at low speed when speed is unnecessary, retain local control when networks degrade, and survive enough failures to return.

1.7 Truth Boundary

The distributed-force argument is an operational design hypothesis, not proof that Sea Arrow already works. The current project has defined the architecture, mass model, candidate geometry, propulsion concepts, control hierarchy and verification program. It has not demonstrated the final hull, 100-knot performance, 300-nmi range or prototype sea-trial behavior.

The next chapter therefore places Sea Arrow precisely in the gap it is intended to explore: between the small USV and the major warship.

2. The Missing Node Between a Small USV and a Warship

2.1 The Existing Capability Spectrum

Sea Arrow exists because the maritime capability spectrum contains a gap. At one end are small uncrewed surface vessels. They can be inexpensive enough to distribute, simple enough to specialize, and small enough to deploy in numbers. At the other end are large crewed ships. They can carry substantial fuel, power, payload, sensors, communications equipment, repair capability and human command capacity.

Both ends of the spectrum are useful. The problem appears between them. A small autonomous vessel can be too constrained in payload, electrical power, range, sea keeping or mobility to perform some missions well. A large warship can perform those missions, but using a major crewed platform for every distributed sensing, relay, logistics or support requirement defeats much of the purpose of distribution.

SMALL USV
|
v
MEDIUM AUTONOMOUS PLATFORM
|
v
SEA ARROW DESIGN SPACE
|
v
LARGE UNCREWED / CREWED PLATFORM
|
v
MAJOR WARSHIP

2.2 What Small USVs Do Well

Small autonomous craft have powerful advantages in distribution, specialization, reduced onboard human burden, numbers and risk separation. A fleet of smaller nodes can occupy more physical locations than one large platform. One vehicle can be configured for sensing, another for relay, another for survey, another for experimental equipment.

Removing permanent onboard crew also changes the mass and volume architecture by reducing requirements for accommodation, food, sanitation and habitability. Those advantages are real, and Sea Arrow should preserve as many of them as possible.

2.3 Where Small USVs Become Constrained

The same features that make small USVs attractive create hard limits. Payload competes with fuel, batteries, propulsion, structure, sensors and cooling. Power generation requires machinery, fuel, wiring and heat rejection. Range adds mass. Sea keeping becomes harder as the hull shrinks relative to the wave environment. Repositioning speed may remain low, and remote systems can become dependent on continuous external control or data.

There is therefore a class of mission in which more payload, more power, more autonomy, more sea-going capacity and much greater mobility may justify a larger vehicle. That is where Sea Arrow begins.

2.4 What Large Warships Do Well

A major crewed ship solves many of these constraints by scale. It can carry large fuel reserves, generate substantial electrical power, host multiple sensors simultaneously, support large antennas, carry repair teams and sustain human command at sea. Sea Arrow should not pretend to reproduce those advantages.

Trying to shrink every large-ship function into a medium autonomous craft creates a growth loop:

2.5 Why Sea Arrow Is Not a Miniature Warship

Sea Arrow should reject the design philosophy of taking everything useful on a large ship and shrinking it until it fits. Some functions can remain elsewhere in the larger system. A crewed command platform may provide higher-level mission direction. Other platforms may provide long-range sensing. Shore infrastructure may provide maintenance and data processing. Other Sea Arrows may carry different mission packages.

Do not carry permanently what can remain modular, distributed or external without compromising safe vehicle operation.

2.6 The Sea Arrow Design Space

The current design space combines an approximately 21.95-m / 72-ft catamaran, a 12,888-kg controlled full-load target, about 2,000 L of fuel as a working assumption, a 1,600-kg modular payload allowance, twin Mercury Racing 1550/1350 main propulsion, a 100-knot primary target, 120-knot stretch region, 130+ knot research region, P1 practical electric low-speed propulsion, P2 experimental MHD research, autonomous operation and graceful degraded return.

SEA ARROW
=
MEANINGFUL PAYLOAD
+
HIGH SELECTIVE MOBILITY
+
MULTIPLE OPERATING MODES
+
LOCAL VEHICLE AUTONOMY
+
DEGRADED RETURN

2.7 What the Platform Must Be – and Must Not Be

Sea Arrow must be fast when speed creates value, economical enough to move normally, quieter at low speed, modular, locally controllable, maintainable and recoverable after selected failures.

It must not depend on permanent high-speed operation, perfect communications, perfect navigation, one enormous integrated mission payload, speculative technology for baseline success, every vehicle carrying every mission system, or every failure being solved by additional hardware redundancy.

The hypothesis is not that Sea Arrow replaces a major warship. It is that there may be an important class of maritime work for which a major warship is unnecessarily large and a small slow USV is physically constrained.

3. Why Rapid Repositioning Changes the Problem

Sea Arrow only makes sense if speed changes something more important than the speedometer. The central question is what becomes possible when a useful maritime node changes position much faster – and what the complete machine has to give up to do it.

3.1 Speed as Time-Distance Compression

Speed is useful when it reduces the interval between a capability being needed and that capability becoming physically available at the required location.

For an illustrative 100-nautical-mile movement:

10 kt -> 10 hours

20 kt -> 5 hours

40 kt -> 2.5 hours

60 kt -> about 1 hour 40 minutes

80 kt -> about 1 hour 15 minutes

100 kt -> 1 hour

These are geometric examples, not mission predictions.

DISTANCE TO NEW TASK
/
REPOSITIONING SPEED
=
TIME BEFORE NODE BECOMES USEFUL THERE

3.2 What Faster Surface Mobility Could Change

At a high level, faster surface mobility could change how quickly a distributed system repositions sensors, restores communications coverage, replaces an unavailable node, moves modular payloads, supports emergency response or changes fleet geometry. The claim is not that high speed solves each of those tasks by itself; the claim is that time-to-position can become a meaningful design variable.

3.3 Speed Is a Selective Capability

Sea Arrow does not need to travel everywhere at maximum speed. The useful architecture separates low-speed or quiet operation, normal transit, high-speed repositioning and short-duration sprint, with degraded return as a separate recovery state.

LOW-SPEED / QUIET
|
v
NORMAL TRANSIT
|
v
HIGH-SPEED REPOSITION
|
v
SHORT-DURATION SPRINT

DEGRADED RETURN = SEPARATE RECOVERY STATE

3.4 The Cost of Speed

Very high speed propagates consequences through the whole machine:

The twin Mercury architecture provides roughly 2.013 MW at two 1,350-hp ratings and roughly 2.312 MW at two 1,550-hp ratings. Those are engine-output figures, not useful thrust power. A first-principles 100-knot screen showed that the available propulsion implies a total-drag ceiling on the order of only tens of kilonewtons, depending on effective propulsion efficiency. Static full-wetted friction alone would exceed that ceiling, proving that very large dynamic unloading is not optional.

At 100 knots the vehicle moves about 51.44 m/s: 5.14 m in 0.10 s, 12.86 m in 0.25 s and 25.72 m in 0.50 s. Fast stabilization therefore has to remain local.

3.5 The 100-Knot Design Question

The program keeps the performance claims separated: 100 knots is the controlled engineering target, 120 knots is a stretch region, and 130+ knots is a research region. None is demonstrated.

The kinetic-energy scale rises rapidly with speed – roughly 17.1 MJ at 100 knots, 24.6 MJ at 120 knots and 28.8 MJ at 130 knots for the controlled full-load mass. That reinforces why structure, sea state, control and stopping or maneuvering margins matter increasingly as speed rises.

The next authoritative evidence is the six-case A-R0/C-R0 CFD campaign at 60, 80 and 100 knots with heave and pitch free. The program needs drag, trim, heave, pitch moment, running wetted area, tunnel pressure, support-center position, spray and ventilation behavior, plus convergence and uncertainty. Those simulations are prepared but have not yet been run.

3.6 Where Speed Stops Helping

Speed stops helping when the reduction in transit time is outweighed by the penalties imposed on the rest of the system. Those penalties can include fuel consumption, reduced range, higher thermal load, higher acoustic output, structural demand, reduced environmental envelope and diminishing operational value.

The current sea-state anchors – approximately Hs 1.25 m for the controlled mission region and approximately Hs 2.5 m for degraded or survival return – are design anchors, not claims that a particular high speed is safe in those conditions. The safe speed in each environmental state still has to be established.

The earlier idea of a silent sprint has therefore been retired. Maximum-power high-speed operation is not acoustically quiet. Quietness belongs primarily to the low-speed operating personality.

3.7 First-Principles Gate

High speed remains valuable only if the complete system gains more operational value from the reduced transit time than it loses through fuel, mass, signature, structural demand and reduced environmental envelope.

If 80 knots eventually produces almost all of the useful repositioning benefit at much lower cost than 100, 120 or 130 knots, the design should be allowed to say so. The program should not protect a performance number from engineering evidence.

That conclusion leads directly into the machine architecture: one vehicle needs several operating personalities because no single operating point can solve the whole mission.

PART II – THE MACHINE THAT RESULTS

4. One Vehicle, Several Operating Personalities

Sea Arrow cannot be designed around one operating point. A craft optimized only for maximum speed would carry the penalties of maximum-speed propulsion, cooling, structure and fuel even while performing missions that do not require those characteristics. A craft optimized only for endurance would surrender the rapid repositioning capability that gives Sea Arrow its distinctive place inside a distributed maritime system.

The requirements are physically different. They conflict. That means the architecture has to separate them.

QUIET / LOW-SPEED
|
v
NORMAL TRANSIT
|
v
HIGH-SPEED REPOSITION
|
v
SHORT-DURATION SPRINT
|
v
DEGRADED RETURN

4.1 Why One Operating Point Cannot Solve the Mission

Quiet operation favors low shaft power, low machinery vibration, reduced exhaust, reduced cooling airflow, efficient electric propulsion and precise low-speed control. High-speed operation favors very high power density, large fuel flow, aggressive dynamic unloading, high structural stiffness and strong control authority. Efficient transit favors lower fuel consumption and conservative thermal state. Degraded return favors reliability, functional isolation and preservation of essential control.

The main engines solve the high-energy mobility problem. The quiet auxiliary system solves the low-speed low-disturbance problem.

4.2 Quiet / Low-Speed Mode

Quiet mode exists because not every part of a maritime mission benefits from high propulsion power. The practical architecture is P1: a separate electric low-speed propulsion path, with the Mercury main engines shut down where practical.

BATTERY
|
v
INVERTER
|
v
ELECTRIC MOTOR
|
v
LOW-SPEED PROPULSOR

An illustrative 5-kN low-speed drag screen at 80-percent efficiency gives roughly 16.1 kW at 5 knots, 25.7 kW at 8 knots and 32.2 kW at 10 knots. Those are not final P1 requirements, but they show why the low-speed system belongs to a different power class than the high-speed machinery.

4.3 Transit Mode

Transit mode exists to move the craft over meaningful distance while preserving fuel, machinery margin and mission reserve. The final economical transit speed is not yet closed. It depends on the actual hull resistance, propeller efficiency, drive ratio, engine fuel consumption, sea state and loading condition.

Cruise efficiency and maximum mobility are different design objectives.

4.4 High-Speed Repositioning Mode

High-speed repositioning is where Sea Arrow becomes physically unusual. At approximately 100 knots, the static hydrostatic condition is no longer the relevant running condition. The hull must transition toward dynamic support, reduce running wetted area, establish stable trim, manage tunnel pressure, maintain propulsor immersion and retain control authority.

4.5 Sprint Mode

Sprint mode represents short-duration operation closer to the maximum validated capability of the vehicle. Maximum power may not be continuously sustainable, and sprint permission should depend on vehicle state rather than merely throttle position.

ALLOWABLE SPRINT
=
SPEED
X SEA STATE
X LOADING
X CG
X FUEL STATE
X THERMAL STATE
X PROPULSION HEALTH
X CONTROL MARGIN

4.6 Degraded Mode

Preserve the vehicle rather than preserve the original mission.

A one-engine condition is not simply the two-engine vehicle at half power. Available thrust falls, asymmetric thrust appears, steering demand changes, electrical generation and cooling may change, and the safe speed envelope changes. The system therefore needs a validated degraded configuration rather than an improvised continuation of the original mission.

4.7 Mode Transitions

The difficult part of a multi-mode vehicle is moving safely between modes. Engine start and stop, electrical redistribution, thermal-state change, control-law change, allowable-speed change and safety-governor limits have to be coordinated.

4.8 Why Multiple Propulsion Personalities Are a System Decision

The reason Sea Arrow contains more than one propulsion path is not technological enthusiasm. It is the consequence of contradictory mission physics. The main engines solve high-power mobility, P1 solves practical low-speed movement without operating the main combustion machinery, and P2 investigates an experimental alternative without becoming a prerequisite for baseline success.

Experimental capability should attach to the architecture without becoming the architecture’s single point of failure.

5. The Complete Sea Arrow

Sea Arrow can now be described as a complete system rather than as a collection of promising technologies. The vehicle is defined by the way geometry, mass, propulsion, electrical power, thermal rejection, acoustics, materials, sensing, control, modular payload and degraded return interact inside one approximately 22-m autonomous maritime platform.

5.1 The Vehicle at a Glance

The current controlled Sea Arrow baseline is a roughly 21.95-m / 72-ft carbon-composite tunnel catamaran intended for uncrewed operation. Its current full-load target is 12,888 kg with a 1,600-kg modular payload allowance and a working fuel assumption near 2,000 L. High-speed propulsion uses two Mercury Racing 1550/1350 engines. P1 is the practical electric low-speed branch. P2 remains experimental MHD research. The principal high-speed target is 100 knots, with 120 knots as a stretch region and 130+ knots as research.

The vehicle has not demonstrated those speeds, the final dynamic hull remains open, the 300-nmi range objective is unproven, the final propeller and drive ratio remain open, P1 hardware is not finalized, P2 remains research, and no integrated prototype has completed progressive sea trials.

5.2 Twin Hulls and Central Tunnel

The twin-hull geometry is part of the high-speed support architecture. At low speed, buoyancy supports the vehicle conventionally. As speed rises, hydrodynamic lift increases, running wetted area should fall, and tunnel airflow can begin to contribute pressure and aerodynamic force. Beam, tunnel geometry, water support, airflow, dynamic unloading and stability therefore interact.

A / Velocity, B / Ocean and C / Stability represented different design priorities. The current A-R0 and C-R0 reconstructed candidates preserve enough of those philosophies to test which geometry produces the most useful combination of resistance, stable trim, dynamic support and control margin.

5.3 Mass, Fuel, Payload and Center of Gravity

Mass is one of the hardest constraints in the vehicle. The current controlled full-load target is 12,888 kg, with 1,600 kg reserved for modular payload and roughly 2,000 L of fuel as a working assumption. Stage-2 analysis placed the representative full-fuel/full-payload LCG near 9.13 m forward of the transom and VCG near 0.80 m, with different payload and fuel states shifting longitudinal CG by several tenths of a metre.

Every mission module therefore needs a controlled installed mass, CG, structure, electrical load and cooling load. The vehicle configuration must know what operating envelope remains valid.

PAYLOAD INSTALLED
|
v
MASS + CG UPDATED
|
v
VEHICLE CONFIGURATION VERIFIED
|
v
VALID SPEED / SEA-STATE ENVELOPE SELECTED

5.4 Main Propulsion

The principal high-speed propulsion architecture uses two Mercury Racing 1550/1350 engines. Combined nominal output is about 2.013 MW at two 1,350-hp ratings and about 2.312 MW at two 1,550-hp ratings. Those figures are engine output, not useful thrust power.

ENGINE
|
v
DRIVE
|
v
PROPULSOR
|
v
WATER
|
v
THRUST

The M8 drive family remains the leading candidate, but the final ratio and propeller are not closed. Propulsor optimization must wait for the dynamic running state.

5.5 P1 Practical Quiet Propulsion

P1 provides a separate practical electric path for low-speed operation. Keeping large combustion engines running merely to move slowly creates unnecessary acoustic output, vibration, fuel consumption, heat and exhaust.

BATTERY
|
v
POWER CONVERSION
|
v
INVERTER
|
v
ELECTRIC MOTOR
|
v
LOW-SPEED PROPULSOR

5.6 P2 Experimental MHD

P2 remains deliberately separate. Magnetohydrodynamic propulsion is physically real, but a practical system has to contend with large electrical current, magnetic-field generation, Joule heating, electrochemical behavior, possible bubble generation, power-conditioning mass and thermal rejection. Sea Arrow therefore does not depend on P2 for baseline success.

P1 = PRACTICAL BASELINE
P2 = EXPERIMENTAL RESEARCH

5.7 Electrical Architecture

Sea Arrow needs electrical power for vehicle control, navigation, communications, sensors, pumps, thermal management, mission systems, computers, P1 propulsion and actuators. The central design principle is segregation of critical and noncritical loads.

CRITICAL BUS
– vehicle control
– safety
– essential navigation

ESSENTIAL SUPPORT
– cooling
– health monitoring
– core communications

MISSION BUS
– payload systems
– mission sensors
– high-rate data

AUXILIARY / EXPERIMENTAL
– nonessential loads
– research systems

Electrical failure should remove mission capability before it removes vehicle control.

5.8 Thermal Architecture

SPREAD
|
v
BUFFER
|
v
DISTRIBUTE
|
v
COOL
|
v
REJECT

Heat must be moved deliberately from local sources to practical rejection locations. The present architecture considers high-conductivity spreaders, protected aluminium for selected internal thermal distribution, liquid cooling and titanium at selected seawater heat-exchanger interfaces. These are architecture choices rather than final production drawings.

No propulsion, electrical or mission-system capability is real until its waste heat has a credible path to the ocean or atmosphere.

5.9 Acoustic Architecture

At high speed, Sea Arrow is not acoustically subtle. Two high-output combustion engines create combustion noise, mechanical vibration, intake noise, exhaust noise, cooling airflow and propulsor noise. The hull itself creates hydrodynamic disturbance. The earlier idea of a silent sprint is therefore retired.

Low-speed P1 operation instead attempts to suppress avoidable machinery sources through main-engine shutdown where practical, resilient mounts, structural isolation, machinery enclosures, acoustic liners and baffled ventilation.

5.10 Materials Architecture

Sea Arrow requires a mixed-material system. CFRP is the primary lightweight structure. GFRP can provide galvanic isolation. Protected aluminium can serve selected internal and thermal roles. Titanium is attractive at selected wet interfaces and heat exchangers. Pyrolytic graphite can provide local high-conductivity heat spreading where useful. Magnesium is unattractive near wet carbon-composite structures because of galvanic concerns.

5.11 Sensors and Vehicle-State Awareness

An autonomous high-speed craft has to know what the machine is doing, not merely where it is. State awareness includes position, velocity, heading, pitch, roll, yaw rate, acceleration, propulsion state, steering state, electrical condition, thermal state, fuel state, actuator state and faults.

SENSORS
|
v
STATE ESTIMATION
|
v
CONFIDENCE
|
v
VALID OPERATING ENVELOPE

5.12 Control Architecture

HUMAN AUTHORITY
|
v
MISSION AUTONOMY
|
v
REAL-TIME VEHICLE CONTROL
|
v
PHYSICAL MACHINE

INDEPENDENT SAFETY GOVERNOR
+—-> CONSTRAIN / VETO / DEGRADE

Humans determine objectives and operating boundaries. Mission autonomy translates those objectives into bounded behavior. Real-time vehicle control handles the physical machine locally. The independent safety governor can limit, veto, reduce mode or command return. The architecture is not based on an AI system controlling everything; it is based on bounded authority and deterministic physical control.

5.13 Maintenance and Accessibility

Accessibility belongs in the architecture. Systems requiring routine service should be reachable: engines, driveline equipment, batteries, inverters, pumps, heat exchangers, sensors, electrical distribution and mission-module interfaces. Replaceable modules should have practical removal paths, controlled connectors and known configuration state.

5.14 Degraded Return

The vehicle is not complete unless it contains a credible way home. Degraded return is the combined result of fault detection, functional isolation, essential electrical power, usable navigation, remaining propulsion, thermal protection and safe reduced-speed control.

5.15 Current Truth State

The project currently has a coherent mission architecture, an approximately 22-m vehicle baseline, a controlled 12,888-kg full-load target, a 1,600-kg modular payload architecture, current mass and CG models, twin-Mercury high-speed propulsion architecture, P1 practical low-speed electric architecture, P2 MHD research branch, A-R0 and C-R0 CFD-ready candidates, electrical, thermal, acoustic and materials architectures, layered control and safety logic, degraded-network logic, degraded-return philosophy, modular mission logic and family-of-systems direction.

It does not yet have completed transient multiphase CFD for the six cases, a final selected high-speed hull, validated dynamic stability across the required envelope, a final high-speed propeller or drive ratio, demonstrated 300-nmi range, complete structural FEA closure, final P1 hardware, demonstrated P1 acoustic performance, demonstrated operational MHD benefit, integrated prototype sea trials or demonstrated 100-knot performance.

SEA ARROW TODAY
=
COHERENT ARCHITECTURE
+
CONTROLLED ENGINEERING BASELINE
+
CFD-READY GEOMETRY
+
DEFINED VERIFICATION PATH

NOT A PRODUCTION VEHICLE
NOT A SEA-TRIAL-PROVEN 100-KNOT CRAFT

6. The Modular Mission System

Sea Arrow becomes significantly more useful when the 1,600-kilogram payload allowance stops being treated as empty carrying capacity and becomes a controlled mission-system interface. The objective is to make the payload allowance usable without requiring the entire vehicle to be redesigned every time its mission changes.

6.1 Payload Is an Interface, Not Empty Weight

Mass is only the first constraint. A mission module changes center of gravity, structural load, volume, electrical power, cooling, data traffic, electromagnetic compatibility, software authority, environmental limits and maintenance access. A module exists only if the platform can carry, power, cool, communicate with and maintain it without invalidating the rest of the vehicle.

6.2 The Mission-Module Envelope

Every module must declare its installed mass, center of gravity, structural attachment, volume, normal and peak electrical load, cooling demand, data needs, electromagnetic compatibility, software authority, environmental limits and maintenance requirements.

Mission payloads may request vehicle motion or a desired observation geometry, but they should not directly own steering actuators, propulsion control, stability control or safety limits.

MISSION MODULE
| request / data
v
MISSION AUTONOMY
|
v
SAFETY GOVERNOR
| permit / limit / veto
v
REAL-TIME VEHICLE CONTROL
|
v
PHYSICAL MACHINE

6.3 Maritime Sensing Module Family

A sensing configuration could support surface observation, environmental monitoring, passive detection, weather and sea-state measurement and distributed data collection. The high-speed capability may be used to move the sensor rapidly between useful positions, while sensing itself occurs at a slower or lower-disturbance state.

RAPID REPOSITION
|
v
DECELERATE
|
v
LOW-DISTURBANCE MODE
|
v
SENSOR OPERATION
|
v
REPOSITION IF REQUIRED

6.4 Communications / Relay Module Family

A relay configuration could extend communications, bridge networks or restore coverage when geometry changes. The communications mission can fail without taking vehicle control with it. The platform still retains local navigation, steering, propulsion control, safety and return behavior.

6.5 Hydrographic and Oceanographic Module Family

Survey modules can support seabed mapping, water-column sensing, environmental data collection and hydrographic work. These missions may prefer slow precise movement and long endurance rather than maximum speed, reinforcing the value of the multi-mode architecture.

6.6 Search-and-Rescue and Emergency Support Modules

An emergency-support configuration could carry observation equipment, emergency communications, medical or rescue supplies, flotation or survival equipment and other time-sensitive payloads. The correct requirement is to reach the emergency as rapidly as the validated vehicle, loading and environmental envelope safely allow – not to promise maximum speed regardless of sea state.

6.7 Logistics Modules

Sea Arrow is not a bulk transport craft. Its logistics value would lie in carrying relatively modest loads whose timing matters, such as spare parts, batteries, medical supplies, sensor packages or repair equipment. Module identity must connect to the allowed operating envelope because cargo mass and position can change trim and high-speed limits.

MODULE INSTALLED
|
v
KNOWN MASS + CG
|
v
VEHICLE CONFIGURATION UPDATED
|
v
VALID ENVELOPE SELECTED
|
v
SPEED / SEA-STATE LIMITS APPLIED

6.8 Uncrewed-System Support Modules

Sea Arrow can potentially support UAVs, other USVs and UUVs through high-level functions such as communications relay, data transfer, delivery of replacement equipment, recovery assistance, navigation support or future recharge and power-transfer experiments. The concept begins with interfaces rather than assuming the vehicle physically carries every possible drone.

6.9 Electronic-Support and Signature-Management Modules

A mission configuration could support high-level passive electronic observation or electromagnetic-environment characterization. These modules introduce strong EMC requirements because power electronics, motors, alternators and communications can contaminate sensitive measurements. Experimental signature-management work should remain modular rather than distorting the common vehicle core.

6.10 Experimental Modules

A modular Sea Arrow can become a maritime technology-development platform for new sensors, communications, energy storage, cooling, navigation, autonomy, materials, acoustic treatment and alternative low-speed propulsion. Experimental hardware should attach to a stable core so that failed experiments produce information rather than program-ending consequences.

6.11 Module Commonality

Modularity only works if the interfaces are actually common. The platform therefore needs controlled mechanical, electrical, thermal, data, EMC, software-authority, environmental, maintenance and configuration boundaries. The exact connectors and standards remain later engineering work, but the principle can be frozen now.

Change the mission without redesigning the vehicle.

6.12 What Must Never Be Modular

Vehicle control, propulsion control, essential navigation, safety-governor functions, fault management, core electrical protection and essential thermal protection remain part of the protected common core. Mission modules may provide information or request actions, but they should not replace the protected control path.

Stable core, controlled interfaces, bounded modules.

PART III – THE SYSTEM IN A CONTESTED ENVIRONMENT

Sea Arrow Volume I |

7. Operating When the Network Breaks

A distributed maritime system becomes fragile if every useful action depends on a perfect network. Sea Arrow therefore separates local vehicle control, mission autonomy, human authority and an independent safety governor. Communications loss, GNSS degradation, sensor disagreement and return logic are treated as operating states rather than exceptional software errors.

The network can improve the mission; it cannot be allowed to own the immediate physical survival of the craft.

7.1 The Assumption That Must Be Rejected

The assumption is continuous perfect connectivity. Mission-level functions can legitimately rely on the network: updated tasking, wider-area sensor information, changes to mission priority, fleet coordination, remote supervision and payload data exchange. Physical survival functions cannot. Stabilization, propulsion control, steering, thermal protection, electrical protection, actuator monitoring, basic navigation state and degraded-return logic remain local.

7.2 Local Control Is Non-Negotiable

At 100 knots Sea Arrow would travel about 51.44 m every second. Immediate stabilization therefore cannot depend on a distant operator or remote compute path. Humans exercise authority at the mission and permission level; the local controller executes safe physical motion in real time.

7.3 Navigation With GNSS

Reliable GNSS contributes position and time, but it is only one part of the navigation solution. A high-speed marine vehicle also needs attitude, angular rates, acceleration, steering state, thrust state, trim, propulsion health and thermal state. GNSS therefore belongs inside a broader state-estimation architecture.

7.4 Navigation Without Reliable GNSS

When GNSS quality declines, the first response should be growing uncertainty rather than immediate total failure. Inertial continuation and other independent observations can carry more weight, but the vehicle should not pretend that confidence remains unchanged.

The operating envelope should shrink as state confidence shrinks.

7.5 Communications Degradation

Communications should be treated as a continuum: full link, degraded link, intermittent link, lost link and link recovery. Full link supports normal mission information exchange. Degraded link prioritizes essential traffic. Intermittent link means the system cannot assume continuous dialogue. Lost link invokes previously authorized local behavior. Link recovery requires reconciliation with the vehicle state that actually exists now.

7.6 Sensor Disagreement

A resilient vehicle has to handle disagreement among sensors, including cases in which a failed sensor still produces plausible numbers. The system must detect disagreement, validate against independent sources where possible, isolate suspect inputs, increase state uncertainty and reduce the operating envelope.

7.7 Mission Autonomy

Mission autonomy is subordinate to the human-delegated mission authority. Its commands are executed through a vehicle-control envelope whose limits, protection priorities, emergency modes and permissible override authorities are themselves defined by human engineering and mission policy.

Human authority owns the objective and decides how much machine risk is permissible.
Mission autonomy executes within that delegation.
Vehicle protection enforces the authorized envelope; it does not independently outrank the mission.

7.8 Independent Safety Governor

The safety governor exists because the system needs a layer whose job is not mission accomplishment. It watches speed, attitude, actuator state, propulsion health, thermal limits, electrical limits, navigation confidence, validated sea-state envelope and configuration state. It can limit, veto, force a lower mode, initiate return or enter a safe state.

7.9 Human Command

Human authority remains above the autonomous mission layer. Humans define mission objectives, operating permissions, geographic bounds, risk limits, return criteria and abort authority. Human control does not require continuous joystick control; it can be exercised through mission authorization, constrained tasking, approval of operating regions, recall and abort.

7.10 Local Resilience Without Unlimited Autonomy

Local resilience means the vehicle can preserve itself and, where explicitly authorized, continue limited mission behavior without immediate external assistance. It does not mean the vehicle acquires unrestricted mission authority. As external certainty decreases, the allowed behavior should become narrower.

7.11 Return Logic

Return is not the absence of a mission. Return is a mission. Communications loss beyond an authorized duration, navigation uncertainty, propulsion degradation, thermal or electrical faults, sensor disagreement, low fuel, worsening environment or mission-module failure can all push the vehicle toward recovery behavior.

PRESERVE CONTROL
|
v
PRESERVE NAVIGATION
|
v
PRESERVE PROPULSION
|
v
PRESERVE ENERGY
|
v
RETURN

8. Survive, Reconfigure, Return

A resilient maritime system should not be designed around the assumption that every subsystem remains healthy for the duration of every mission. Machines fail. The useful question is what failures the vehicle can detect, isolate and survive without allowing one local problem to become a total vehicle loss.

A failure should remove capability before it removes the vehicle.

8.1 The Failure Philosophy

The sequence asks not merely whether the failed component can be restarted, but what capability was lost, what other systems depended on it, what functions remain, and what new operating envelope is safe.

8.2 Functional Isolation

Removing one noncritical capability should remove that capability, not unexpectedly disable the machine.

Modern vehicles can become deeply interdependent through shared power, communications, cooling, software, sensors and controllers. Sea Arrow therefore needs clear power, data, cooling, authority and failure-containment boundaries between the protected vehicle core and mission or experimental systems.

8.3 Main-Propulsion Failure

Loss of one main engine changes the whole propulsion state. Total available thrust falls, asymmetric thrust appears, cooling and electrical generation may change, and the normal high-speed envelope may no longer be valid. The correct response is to enter a separately validated one-engine envelope and return or continue only at reduced capability.

8.4 Electrical Failure

Electrical architecture needs prioritization. Critical loads preserve vehicle control, safety and essential navigation. Cooling, health monitoring and core communications follow. Mission payloads and experimental systems are lower priority. During a fault, the architecture should isolate the failed branch, stabilize the essential bus, shed nonessential loads, check energy margin and reduce operating mode if required.

8.5 Thermal Failure

A cooling fault can propagate unless the thermal architecture is compartmentalized. If heat rejection falls, the system should identify the source or loop, reduce nonessential load, reduce propulsion or mission demand, isolate failed equipment where possible, monitor recovery and enter degraded mode or return.

8.6 Sensor Failure

Autonomous control depends on sensing, so Sea Arrow needs both fault detection and confidence management. A dead sensor is easier to identify than a sensor reporting plausible but incorrect data. Independent corroboration and consistency checks should reduce the chance that one questionable input drives the vehicle into its highest-energy state.

8.7 Communications Failure

Mission coordination may depend on communications. Vehicle control must not.

Communications loss can remove external updates, remote supervision, wider-area data and cooperative functions. It should not remove steering, propulsion control, stability, local fault protection, basic navigation or pre-authorized return behavior.

8.8 Mission-Module Failure

A mission-module failure should not own the survival of the core vehicle.

A mission module may fail electrically, thermally, logically or in software. The core needs a way to remove module authority and isolate data, power or cooling interfaces as required, then continue or return.

8.9 Structural / Damage Response

Structural damage changes the physical load-bearing capacity and cannot always be isolated like software or electrical faults. The architecture therefore needs conservative behavior: reduce dynamic load, assess available health data, restrict speed and sea-state exposure, avoid high-energy modes and return.

8.10 Field Maintainability

Survivability is not finished when the vehicle reaches home. A distributed fleet becomes impractical if every fault requires depot-level intervention. Sea Arrow therefore needs accessible hardware, modular replacement, fault logs, known configuration and minimum specialized intervention where practical.

8.11 Recovery Is a Design Requirement

A failed mission should not automatically become a lost vehicle.

The correct objective is not universal survivability. It is to preserve a credible recovery path for the classes of failure the architecture is designed to tolerate. Resilience means retaining useful choices after something has gone wrong.

9. Build a Family, Not a Hero Vehicle

Sea Arrow becomes more important when the design objective shifts from producing one exceptional vehicle to producing a repeatable family of vehicles that share a common physical core. A single prototype can be impressive and still have little fleet value.

The objective is not the most impressive individual Sea Arrow. The objective is the most useful family of interoperable Sea Arrow nodes that can be manufactured, maintained, configured and operated as one system.

9.1 Why One Perfect Vehicle Is the Wrong Objective

There is a natural tendency in advanced vehicle design to keep adding capability. Each addition can be rational locally, while the complete design becomes heavier, more expensive, harder to maintain and more difficult to manufacture. Sea Arrow should not attempt to build one vessel that is simultaneously the best sensor platform, relay platform, survey platform, logistics platform, uncrewed-system support platform and experimental platform.

9.2 The Common Sea Arrow Core

The common core should include, where practical, hull and principal geometry, main propulsion architecture, primary electrical architecture, vehicle-control system, independent safety governor, essential navigation, thermal-management backbone, common mission-module interfaces, common diagnostics, maintenance philosophy and configuration control.

Preserve commonality until the operational value of specialization clearly exceeds the system cost of breaking commonality.

9.3 Sensor / Surveillance Node

A sensor-focused Sea Arrow can prioritize clean electrical power, vibration isolation, low-disturbance modes, stable sensor mounting, thermal control, data handling and communications. Its distinctive value may come less from a unique sensor than from the ability to move the sensor rapidly between useful positions.

9.4 Relay / Network Node

A relay variant treats connectivity as its primary mission contribution. The communications package can evolve over time while the vehicle-level role remains stable: move communications capability to where the larger system needs it. The relay mission may fail, but the vehicle still retains navigation, steering, propulsion control, safety and return.

9.5 Survey / Ocean Node

A survey or oceanographic variant emphasizes accurate low-speed track keeping, stable sensor geometry, environmental measurements and long periods in low-power operation. The same vehicle can move quickly between survey regions and then transition into low-speed work.

9.6 Logistics Node

A logistics variant shifts the mission emphasis toward useful small-load transport. The design problem is not maximum cargo mass; it is how much useful cargo can be moved without disrupting the mass, CG, structural and range envelope. Standardized tie-down points, payload frames, load envelopes, mass limits and handling interfaces become part of the family architecture.

9.7 Uncrewed-System Support Node

Sea Arrow can provide selected forward support functions for UAVs, USVs and UUVs, such as communications relay, data transfer, delivery of replacement equipment, recovery assistance or future power-transfer research. It should not become a universal mothership; the role has to remain inside the physical scale of the platform.

9.8 Experimental Node

An experimental Sea Arrow can carry new sensors, autonomy research hardware, communications, thermal-management experiments, energy-storage experiments, materials, acoustic treatments, P2 MHD research hardware and alternative auxiliary propulsion. The experiment should remain attached to a stable core.

9.9 Commonality Versus Specialization

At what point does specialization save mission mass or increase mission value, but destroy enough commonality that the fleet becomes harder to manufacture, maintain and operate?

Too little specialization creates unused mass and mission compromise. Too much specialization creates unique structures, unique software, unique spares and fragmented support. The useful separation is core commonality versus mission variability.

9.10 Manufacturing Architecture

A family-of-systems design has to be manufacturable as a family. Where practical, variants should share hull tooling, structural molds, engine installation, driveline architecture, electrical harness architecture, cooling interfaces, compute enclosure standards, sensor/network interfaces and module attachment points. Late mission differentiation keeps the production core common for longer.

9.11 Maintenance Architecture

Maintenance should preserve common engine service, control diagnostics, electrical troubleshooting, cooling interfaces, navigation hardware where possible, software/configuration procedures and replacement modules. Common diagnostics allow repeated failures across the fleet to be recognized as systemic weaknesses rather than isolated events.

9.12 Multi-Vehicle Cooperation

The family becomes most interesting when several Sea Arrows operate as different nodes of one maritime system. One node can collect information, another can support communications, another can transport mission equipment, and another can remain available as reserve or replacement.

ONE NODE FAILS
|
v
SYSTEM DETECTS CAPABILITY LOSS
|
v
ANOTHER NODE REPOSITIONS OR ROLE IS REDISTRIBUTED
|
v
NETWORK OPERATES AT REDUCED CAPABILITY
|
v
FAILED NODE RECOVERED / REPLACED

9.13 Fleet-Level Value

The question is no longer only how capable one Sea Arrow is. It becomes how much useful maritime capability a family of common Sea Arrow nodes can generate together. A proposed improvement should therefore be evaluated at two levels: does it improve the individual vehicle, and does it improve or damage the Sea Arrow family?

Build the common vehicle well enough that many different useful Sea Arrows can exist without each becoming a new engineering program.

PART IV – MAKE IT REAL

10. Engineering the Next Generation

Sea Arrow now has enough architecture that the next stage should become less conceptual, not more. The vehicle has a defined mission logic, controlled mass target, candidate geometry, high-speed propulsion architecture, practical quiet-propulsion branch, modular mission system, control hierarchy, degraded-network and degraded-return logic and a family-of-systems direction. But none of those things can substitute for physical evidence.

The next generation of Sea Arrow is produced by successively replacing assumptions with evidence.

10.1 Where the Project Actually Stands

The present Sea Arrow is more mature than a sketch and less mature than a prototype. The project has a roughly 22-m tunnel-catamaran architecture, 12,888-kg controlled full-load target, 1,600-kg payload allowance, working fuel assumption near 2,000 L, twin Mercury main-engine architecture, P1 electric low-speed propulsion, P2 MHD research, reconstructed A-R0 and C-R0 CAD candidates, preliminary mass/CG/inertia models, first-principles power and drag screens, thermal, acoustic and materials logic, layered control and safety concepts, degraded-return architecture, modular mission architecture and family-of-systems direction.

It does not yet have a demonstrated 100-knot vehicle, final dynamic hull, validated 300-nmi range, final propeller, final drive ratio, complete structural FEA closure, final P1 hardware, validated P1 acoustic performance, validated MHD operational value or prototype sea-trial evidence.

10.2 Development Step One – Run the Six CFD Cases

The immediate next evidence should come from the water-and-air model. Two geometries – A-R0 and C-R0 – are compared at 60, 80 and 100 knots. The purpose is to determine whether either present reconstructed hull produces a plausible, stable high-speed running state inside the available propulsion envelope.

Important outputs include total resistance, dynamic trim, heave, pitch moment, running wetted area, tunnel-pressure distribution, support-center position, free-surface behavior, spray, ventilation and numerical convergence and uncertainty.

10.3 Development Step Two – Select or Redesign the Dynamic Hull

The CFD campaign should be allowed to produce any legitimate result: A-R0 is better, C-R0 is better, the difference is smaller than numerical uncertainty, or neither hull closes. If neither geometry produces an acceptable combination of resistance, stability, support and control margin, the program should redesign the hull rather than protect the evidence.

10.4 Development Step Three – Build the Dynamic Stability Model

Once a dynamic hull emerges, the next task is to map stable controllable operation against speed, CG, mass, sea state, propulsion state and control authority. The model has to identify margins to pitch divergence, porpoising, loss of propulsor immersion, unacceptable structural loading and insufficient control authority.

10.5 Development Step Four – Propulsor and Range Closure

The propulsion problem cannot be closed before the running attitude is understood. Once the dynamic hull is known, the program can select the drive ratio and propeller family, estimate realistic efficiency and fuel flow, and close the mission range relationship.

10.6 Development Step Five – Structural FEA

Structural engineering has to cover static hull loads, engine and driveline loads, payload loads, wave loads, slam loads, tunnel-span bending, torsion between hulls, high-speed dynamic loads, fatigue and local attachment loads. CFRP then requires laminate-level engineering, joints, inserts, engine foundations, payload hardpoints and damage tolerance.

10.7 Development Step Six – P1 Quiet-Drive Bench System

P1 should be validated as a physical subsystem before full prototype integration. The bench system needs to close motor, inverter, voltage, battery chemistry, usable capacity, propulsor, cooling, endurance, efficiency, thrust and acoustic behavior.

10.8 Development Step Seven – Thermal, Acoustic and Materials Rigs

Thermal management, vibration isolation, acoustic leakage, corrosion and mixed-material joints should be tested on dedicated rigs and coupons before full vehicle integration. It is cheaper and more informative to discover interface problems at component scale than after the complete prototype exists.

10.9 Development Step Eight – Control Hardware-in-the-Loop

Hardware-in-the-loop testing should inject sensor loss, sensor disagreement, actuator faults, communications loss, navigation degradation, propulsion failure, cooling faults, electrical faults and mode-transition failures. The central question is whether the system detects the fault, isolates it, reduces the envelope, preserves control and allows the safety governor to intervene when required.

10.10 Development Step Nine – Integrated Prototype

The first full Sea Arrow prototype should be heavily instrumented. Its purpose is not merely to prove visually that the boat moves. It should compare predicted mass, CG, thermal behavior, running attitude and structural loads against measured behavior, and record engine state, driveline state, fuel flow, electrical loads, temperatures, pressures, control positions, navigation state and vehicle speed.

10.11 Development Step Ten – Progressive Sea Trials

DOCK
|
v
LOW SPEED
|
v
P1
|
v
TRANSITION
|
v
40-60 KT
|
v
60-80 KT
|
v
100-KT GATE
|
v
120-KT REVIEW
|
v
130+ RESEARCH

Each speed region is attempted only after the previous region demonstrates acceptable control, loads, trim, thermal behavior, propulsion behavior, structural response, navigation and safety-system performance. The test program follows evidence, not schedule pressure or a predetermined claim.

10.12 Development Step Eleven – Multi-Vehicle Experiment

One functioning Sea Arrow does not prove the family-of-systems argument. Only after individual platform behavior is sufficiently mature should the program test multi-vehicle operation: shared control architecture, module interoperability, role substitution, communications degradation, diagnostics, maintenance commonality and fleet-level usefulness.

10.13 Development Step Twelve – Family-of-Systems Development

The final transition is from prototype vehicle to platform family. That requires freezing the parts that should remain common – hull geometry, machinery installation, propulsion, electrical and thermal backbones, navigation, vehicle control, safety governor, diagnostics, mission-module interfaces and maintenance interfaces – while allowing controlled mission variation above that core.

The program should then measure metrics beyond speed, including build hours, unique part count, common-part percentage, mean maintenance time, module-change time, software commonality, diagnostic coverage, spare-part burden and vehicle availability.

The Development Philosophy

Every development stage should retire one class of uncertainty before the next stage is allowed to depend on it.

This rule prevents battery optimization while the hull is unresolved, propeller selection before the running state is understood, fleet doctrine before the vehicle proves basic dynamics, and experimental technologies from becoming mandatory before the practical architecture works.

From Concept to Capability

The next major advances cannot be written into existence. They have to be measured. If CFD rejects both hulls, build a better hull. If range does not close, reconsider propulsion, fuel, mass or mission assumptions. If structure becomes too heavy, redesign the load path. If P1 cannot meet the quiet-mode objective at acceptable mass, revise P1. If MHD proves inefficient, leave it in the research archive. If 100 knots proves useful but 120 does not, stop at 100.

The goal is not to prove that the original Sea Arrow idea was correct in every detail. The goal is to discover the strongest physically coherent system that survives engineering.

Sea Arrow Volume I |

Closing – The Post-RMA Surface Fleet

Sea Arrow began with a narrow engineering question: could an autonomous surface vehicle combine meaningful payload, unusually high selective speed, multiple propulsion states, local resilience and modular missions inside one physically coherent platform? By the end of Volume I, the question has become larger.

The vehicle is interesting as a test of what a post-RMA surface fleet might look like when maritime power is organized less around a small number of individually complete platforms and more around interoperable crewed and uncrewed systems that distribute sensing, communications, logistics, mobility and specialized mission functions across many nodes.

Large ships may remain essential while a growing portion of useful maritime capability moves outward into smaller, distributed, increasingly autonomous nodes.

C.1 From Platform-Centric to System-Centric Design

Traditional naval architecture naturally begins with the platform: size, propulsion, sensors, payload and endurance. A distributed architecture adds another layer: what does the complete system need, and which physical node should perform each function? The important design object becomes not merely the individual platform but the relationship among platforms.

C.2 Crewed and Uncrewed Systems Together

The future surface fleet should not be framed as a contest between crewed and uncrewed vessels. Crewed ships retain advantages in judgment, repair, improvisation, command, maintenance, endurance, large power systems, sensors and logistics. Uncrewed systems extend geographic coverage, persistence, sensing, communications, experimentation and payload movement. Sea Arrow belongs in that distributed layer and should extend the reach of larger platforms rather than pretending to replace them.

C.3 Central Coordination and Local Resilience

A distributed fleet creates a tension between coordination and dependence. More nodes increase flexibility, but can also increase dependence on communications and navigation. Sea Arrow therefore separates central mission coordination from local physical control. The network makes the vehicle more useful; it should not be required merely to keep the vehicle alive.

C.4 Persistence and Rapid Repositioning

Persistence asks how long a node can remain useful in one region. Rapid repositioning asks how quickly the node can become useful somewhere else. Sea Arrow adds mobility to the distributed-system problem and treats high speed as selective time-distance compression rather than permanent operating condition.

C.5 Common Platforms and Modular Missions

A distributed force becomes difficult to support if every mission produces a different vehicle. Sea Arrow therefore separates the common machine from the mission package. Commonality can compound through tooling, spares, diagnostics, training, software and validation, while mission modules provide specialization.

C.6 Sophistication and Field Repair

Advanced technology does not automatically produce a better fleet. A system that performs brilliantly under ideal conditions but requires extensive specialist support after every fault may have poor operational value. Sea Arrow therefore has to combine advanced composites, autonomy, sensing, control and thermal management with accessible machinery, replaceable modules, controlled interfaces, clear diagnostics and known configuration state.

C.7 Automation Under Human Authority

Sea Arrow depends heavily on autonomous operation, but autonomy has a bounded role. It exists because an uncrewed vehicle needs to perform local functions without a person physically onboard and because fast control cannot wait for remote intervention. Human authority remains above the mission system; automation does not become the root of authority.

HUMAN AUTHORITY
|
v
MISSION OBJECTIVES
|
v
MISSION AUTONOMY
|
v
REAL-TIME VEHICLE CONTROL
|
v
PHYSICAL MACHINE

INDEPENDENT SAFETY GOVERNOR
+—-> LIMIT / VETO / DEGRADE

C.8 What Sea Arrow Is Really Testing

The easiest way to misunderstand Sea Arrow is to reduce the project to one number: 100 knots. The project is actually testing whether high selective speed, meaningful payload, useful range, multiple operating states, local resilience, modular missions, field maintainability and common family architecture can coexist inside one medium autonomous maritime platform.

If Sea Arrow reaches 100 knots but cannot carry useful payload, the architecture fails. If it carries useful payload but has unacceptable range, it fails. If it performs well but cannot survive ordinary subsystem faults, it fails. If every mission requires a different vehicle, the family architecture fails. If it requires continuous perfect communications, the resilience concept fails. If it becomes too expensive or difficult to maintain in meaningful numbers, the distributed-system premise weakens.

C.9 Back to the Water

The project now reaches the point where further confidence has to come from evidence. Architecture is important, but architecture is not proof.

If A-R0 fails, reject it. If C-R0 fails, reject it. If neither hull closes, redesign the hull. If range does not close, reconsider speed, fuel, mass or propulsion. If structural reinforcement destroys the mass model, change the architecture. If P1 does not justify itself, redesign P1. If P2 does not produce enough system value, leave it experimental. If 120 knots adds little beyond 100 while sharply increasing cost and risk, do not protect the number.

The concept has to survive engineering – not the other way around.

The final image of Volume I is therefore not a rendering. It is the vehicle returning to the water as an instrumented prototype: sensors active, systems logged, loads measured, thermal state known, configuration known, and every test producing evidence.

Eventually, if the architecture survives, one Sea Arrow becomes several: a sensing node, a relay node, a survey node, a logistics node, a support node – a common family moving across the same maritime system.

Large and small, crewed and uncrewed, centralized where coordination helps, distributed where geography demands it, locally resilient when networks fail, modular where missions change, and disciplined enough that the physics – not the ambition – decides what survives.

That is the Sea Arrow proposition. And now the next answer has to come from the water.

END OF VOLUME I

👉 SEA ARROW [Volume II]: Engineering Development & Recovery Record

APPENDIX A. MEDIA FORMATION. SEA ARROW – COMMERCIAL

APPENDIX B. MEDIA FORMATION.

Note: Not yet authorized to publish detailed biographical information on Team SGT. (missing slides explanation)

Valentin @ SGT = Valentin Picard 😎, Canadian Christian ✝️, Romanian/Canadian 🇷🇴🇨🇦

Cris = , Power Ranger ⚡, autistic quiet kid, Canadian Christian ✝️, Polish/Canadian 🇵🇱🇨🇦

In grade six, on last day, in parking lot alone with Cris, before departure for West/BC:

Valentin Picard: Cris. We made it. Grade school sucked, but we didn’t.

Cris: That’s 30, Valentin. Your number. Thirty attackers in the last round, no mistakes. Nobody’s ever done that. You saved my life for five years. Just like today.

Valentin: It wasn’t school. It was graduation. I guess that was the lesson. Five-year mission. To boldly go. Find the limits of this galaxy and break through.

Cris: I’m #1. Your #1.

Valentin: We’re partners. Equal. The first team that’s equal. You’re Cris. We’re Starfleet Special Forces. The Next Generation of the Next Generation.

Cris: I’ll never see you again. Everyone will betray us, like they always have. But I won’t. I’ll always be with you. You’ll go build the Enterprise, and you’ll remember the superheroes. So will everyone will remember too. And when it flies, I will show people also the real Canada. The good Canada.

APPENDIX C. MEDIA FORMATION.

Star Trek Insurrection Main Title/Ba’ku Theme | Star Trek: Insurrection 🇨🇦 https://youtu.be/bb12fzHsB2o

Equilibrium (2002) – Gun technique scene https://youtu.be/-_y7PL23Cko

Equilibrium – Killed for Reading https://youtu.be/TJf9Pf9rjO4

Star Trek: Insurrection 4K “AI” Upscale – Son’a Fight https://youtu.be/I7cb4ZK9WV4

Equilibrium – The Incineration https://youtu.be/uZWDke-bpmc

She caught feelings, she got arrested | Equilibrium https://youtu.be/7AaH2PzbJDc

Star Trek TNG – Riker and Troi’s wedding https://youtu.be/kw5f_mJl2X8

“Out Of Touch” Poilievre Blasts Carney, Pitches $150B Cuts To Debt, Taxes And Inflation https://youtu.be/OcJodTWFcYI

Main Theme | Star Trek Nemesis | Jerry Goldsmith https://youtu.be/k0KhlbFD-KY