An uncrewed surface vessel (USV) combines a hull and propulsion system with electrical power, navigation sensors, control software, communications, and a mission payload. Its architecture determines how those components exchange measurements and commands, who can take control, and what the vessel does when a component stops working.
The useful system boundary includes the operator station and launch and recovery arrangements. Removing the onboard crew does not remove human supervision: a USV can be remotely steered or follow a programmed mission with varying amounts of onboard decision-making. NOAA describes both arrangements in its USV overview.
For engineers and program managers, review the components against one loaded configuration, operating area, and recovery plan. That ties the architecture to the mission it must actually perform.
On This Page
- The main components and their boundaries
- How a mission becomes vessel motion
- Interfaces that need explicit definitions
- Power, propulsion, and payload tradeoffs
- Failure responses must match the remaining capability
- How applications change the architecture
- What to request in an architecture review
The main components and their boundaries
The following breakdown is a practical way to review uncrewed surface vessel components. It separates functions even where one enclosure or computer performs several of them. NOAA's overview and WHOI's Jetyak technical description provide examples of these functions assembled into working research vessels.
| Component group | What it contributes | Boundary to examine |
|---|---|---|
| Hull, compartments, and mounts | Buoyancy, protection, and physical support for equipment | Loaded draft, equipment position, watertight penetrations, and lifting or towing arrangements |
| Propulsion and steering | Thrust and control of vessel direction | Required command format, neutral and reverse behavior, and feedback on actual response |
| Energy and distribution | Power for propulsion, computers, sensors, and radios | Usable energy, peak loads, protective devices, and what remains powered after a fault |
| Navigation and state estimation | Estimated position, velocity, heading, and attitude | Measurement age, coordinate reference, uncertainty, and response to inconsistent sensors |
| Perception and mission software | Obstacle information, route selection, and mission sequencing | What the system can detect, which decisions are onboard, and when intervention is needed |
| Autopilot and control allocation | Converts requested motion into actuator outputs | Output limits, steering arrangement, control ownership, and loss of a command source |
| Payload and recorder | Mission measurements and retained data | Mounting, power, timestamps, data format, and storage capacity |
| Communications and operator station | Mission upload, telemetry, alarms, and remote intervention | Coverage, delay, stale displays, command acknowledgement, and takeover procedure |
WHOI's Jetyak illustrates why these boundaries matter. Its documented arrangement combines an impeller-driven kayak, an ArduPilot controller for waypoint navigation, and a separate computer for sensor logging. Radio control, navigation-computer access, and remote viewing of acquired data have distinct roles. A working connection to one subsystem therefore should not be treated as proof that every subsystem is healthy.
How a mission becomes vessel motion
Consider a survey vessel following parallel lines. The mission supplies destinations and task instructions. Navigation estimates the vessel's current state; guidance determines the motion needed to approach the next segment; the controller produces steering and thrust commands. New measurements close the loop by showing whether the vessel responded.
The actuator arrangement changes the final step. A controller may command steering and throttle separately or allocate output to independent left and right propulsion units. ArduPilot documents these as separate configurations, together with several motor-driver signal types, in its motor and servo configuration guide. Matching the physical connector is insufficient if the controller and driver interpret the signal differently.
Obstacle handling is another function. Reaching waypoints does not establish that the vessel detects traffic or can select a suitable avoiding maneuver. ArduPilot's object-avoidance documentation distinguishes sensor inputs, path planners, and actions whose availability depends on vehicle and mode.
For example, an Automatic Identification System (AIS) receiver can supply positions reported by nearby vessels. ArduPilot notes that those messages arrive infrequently. That feed does not establish detection of an unreported floating object. An architecture review should therefore ask separately about reported traffic, locally sensed obstacles, detection limits, and the decision taken when information becomes old.
Control ownership should also be explicit. If an operator requests a turn while mission software is sending course commands, the system needs a defined authority order. Otherwise, a clear operator display can conceal an unclear control path. Specify which source wins, how the change is acknowledged, and whether autonomy resumes automatically or requires another deliberate action.
Interfaces that need explicit definitions
An interface description should tell an integrator how to interpret a value and what to do when it is absent. For each connection, request the physical interface, message format, units, reference frame, update behavior, and failure response.
Commands need results. In systems using MAVLink, the command protocol defines acknowledgements and retry behavior. Its accepted result means the command is valid and the system will attempt it; acceptance is not proof of completion. An operator who orders a mode change needs the resulting mode and vehicle state, not simply confirmation that a message arrived.
Timestamps need a common meaning. Position, attitude, and payload records may originate on different computers. MAVLink's time-synchronization protocol estimates clock offsets using repeated exchanges. An integration specification must still say whether a timestamp represents measurement time, processing time, or reception time. Synchronizing clocks does not erase sensor or processing delay.
As an illustrative calculation, suppose a vessel travels at 2 metres per second and a measurement is associated with a position 0.1 seconds late. The along-track displacement from that timing mismatch alone is 2 × 0.1 = 0.2 metres. These are hypothetical inputs, not a claimed survey accuracy. The example shows why the timestamp convention belongs beside the sensor specification.
Health needs independent visibility. Request separate indications for communications health, navigation confidence, actuator response, and payload recording. The design implication is simple: a live radio should not mask a frozen measurement, and a moving boat should not mask a stopped recorder.
For networked systems, also identify which endpoints may issue motion commands, how access is controlled, and how payload traffic is kept from overwhelming essential telemetry. These are questions for the actual installation; a protocol name alone does not answer them.
Power, propulsion, and payload tradeoffs
Begin with the mission duty cycle: transit, measurement, station keeping, return, and recovery. Budget propulsion and electrical loads for each phase. Count simultaneous activities once: if measurement occurs during station keeping, allocate their combined load to that interval. Treat the following equation as a planning identity, using values established for the proposed configuration:
Required mission energy = transit energy + measurement energy + station-keeping energy + return energy + recovery reserve.
A single advertised endurance figure cannot populate that budget. WHOI's Jetyak description explicitly conditions endurance on engine speed and discusses speed with different loads and without drag-inducing sensors. Those qualifications explain why changing a payload can require reassessing the complete vessel.
Compare architectures against the same task. For a battery-powered craft, request usable energy and peak-current limits with all equipment running. For a combustion-powered craft, include fuel, starting power, electrical generation, and the intervention needed after an engine fault. For a renewable-powered platform, separate the energy that moves the vessel from the electricity available to its instruments. NOAA documents several propulsion and energy approaches; it does not establish one universal performance envelope.
Low-speed behavior deserves its own requirement. ArduPilot's boat Loiter mode allows drift inside a configured radius and commands a return when the boat moves outside it. Heading can vary with the selected behavior. A payload that must face a fixed direction therefore needs a more specific requirement than “holds position.”
Finally, ask for a power-distribution drawing that identifies shared dependencies. Two radios supplied through one converter still share that converter as a potential loss point. Separate components provide useful redundancy only to the extent that the failures they are intended to tolerate are actually separated.
Failure responses must match the remaining capability
“Return home” is useful only while the vessel can navigate and propel itself along a suitable route. Likewise, removing thrust does not keep a floating hull fixed in wind or current. The recovery plan needs to consider the capability left after the fault.
ArduPilot's Rover failsafe documentation separates radio, ground-station, and battery triggers. Ground-station loss is detected through missing heartbeat messages when configured for that behavior. Settings can change the resulting action, and restoring the connection does not necessarily restore the previous operating mode.
Navigation failure is distinct. The EKF failsafe monitors confidence in estimated position and attitude. EKF means extended Kalman filter, the estimator combining sensor information. ArduPilot documents restrictions on entering position-dependent modes when the estimate fails. Returning to a coordinate is not an independent fallback for an unreliable coordinate estimate.
Use a fault table to make the recovery discussion concrete. These are review questions, not universal automatic responses:
| Fault or degraded condition | Question the architecture must answer |
|---|---|
| Operator link disappears | Which onboard function detects it, what action follows, and who can regain control? |
| Position becomes unreliable | Which modes remain usable, and what recovery avoids relying on the rejected estimate? |
| Propulsion output produces little motion | Can the system distinguish a failed actuator from an unmet motion request, and report the remaining maneuvering capability? |
| Energy reaches the return threshold | Does the calculation account for the return route, conditions, and essential electronics? |
| Payload recording stops | Is the operator alerted, and should the mission pause, return, or continue for another purpose? |
| Water ingress or a distribution fault occurs | What is isolated, what stays powered, and how will the vessel be recovered? |
Mode names require care. ArduPilot's Hold mode sets motor and servo outputs to configured trim values. Its boat Loiter behavior actively returns toward a target region. These are materially different responses even if an operator informally calls both “stop.”
How applications change the architecture
The payload and operating environment decide which boundaries deserve the most attention.
- Shallow-water measurement: WHOI's Jetyak uses combinations of echo sounders, current profilers, and a dedicated recorder. That makes sensor installation, data access, and the loaded vessel's operating limits central integration questions.
- Long-duration ocean observation: NOAA describes USVs collecting ocean and atmospheric measurements and transmitting information to shore. This shifts attention toward sustained energy supply, data retention, and the intervention available far from the launch point.
- Support for underwater vehicles: NOAA documents surface craft providing underwater systems with navigation support and communications, including acoustic-modem arrangements. Review the surface-to-operator and surface-to-underwater links separately; success on one does not establish success on the other.
These examples describe functions, not interchangeable products. A platform suitable for a supervised nearshore survey is not automatically suitable for an unattended offshore mission just because both can follow waypoints.
What to request in an architecture review
Request three connected descriptions: a drawing of equipment and power distribution, an interface list showing commands and measurements, and a fault table showing authority and recovery behavior. Review all three against the same loaded configuration and mission.
Then follow one mission step through the whole system: the operator requests it, the controller accepts it, the actuators respond, the sensors report the result, and the payload records useful data. Repeat that walkthrough with the operator link missing, navigation degraded, and a payload fault present. Use any unexplained transition to identify the interface definition or recovery procedure still needed before operation.
Sources
- NOAA Ocean Exploration: Uncrewed Surface Vessels. Government overview of USV functions, energy approaches, applications, and the pictured C-Worker 4.
- WHOI: Jetyak technical description. Research-platform documentation covering propulsion, navigation, radios, payloads, and logging; its conditions apply to the documented configurations.
- ArduPilot: Motor and Servo Configuration. Implementation documentation for control-output arrangements and motor-driver signals.
- ArduPilot: Object Avoidance. Implementation overview of sensor inputs, AIS, and mode-dependent avoidance behavior.
- MAVLink: Command Protocol. Protocol definitions for command delivery, acknowledgements, and execution results.
- MAVLink: Time Synchronization Protocol v2. Protocol documentation for estimating component clock offsets.
- ArduPilot: Loiter Mode. Boat position-maintenance behavior, radius, and heading choices.
- ArduPilot: Failsafes. Radio, ground-station, and battery fault triggers and configurable actions.
- ArduPilot: EKF Failsafe. Estimator-health monitoring and restrictions on position-dependent modes.
- ArduPilot: Hold Mode. Motor and servo output behavior, distinct from active boat station keeping.
Last checked: September 7, 2026.
