submarine

Most engineers still picture a submarine as a hull - a propeller. And a periscope - but the modern submarine is actually a distributed software platform carrying more telemetry endpoints than a small data center. Over the past decade, the operational model for undersea vehicles and submarine cable infrastructure has shifted from manual navigation and scheduled maintenance to continuous software-driven monitoring. That shift isn't just a maritime curiosity; it's a master class in building reliable systems under extreme constraints.

I have spent portions of my career instrumenting remote industrial systems, including uncrewed underwater vehicles used for pipeline inspection and environmental monitoring. The same patterns we use in cloud observability - metrics, logs, traces, anomaly detection - apply underwater. But with bandwidth measured in bytes per second instead of gigabits. That changes almost everything about how you design an architecture.

This article treats the submarine as a systems engineering case study. We will look at undersea telemetry, autonomous navigation stacks - acoustic networking, cable-break incident response, GIS data pipelines - security controls. And open-source tooling. The goal isn't to romanticize submarines. The goal is to extract engineering lessons that apply to any constrained, safety-critical. Or high-latency environment.

Why Submarine Infrastructure Is Really a Software Engineering Problem

Submarine cables carry over 95% of intercontinental internet traffic. According to TeleGeography, there are roughly 500 active and planned submarine cable systems worldwide as of 2024. These cables aren't dumb pipes. Modern submarine cable landing stations run SDH, DWDM. And increasingly software-defined networking (SDN) controllers that allocate capacity, detect faults. And fail over traffic in milliseconds. The physical asset may be buried under the seabed. But its behavior is governed by software.

That means a submarine cable outage is rarely just a physical break it's a control-plane event. When a cable is severed by an anchor or a subsea landslide, the optical line terminal equipment detects a loss of light, the multiplexer triggers alarms, and the network operations center must decide whether to reroute traffic over a different submarine path or wait for repair. Those decisions are automation problems, not maritime problems. In production environments, we found that the incident response workflow for a submarine cable break looks almost identical to a cloud region failure: detect, isolate, notify, fail over. And schedule remediation.

Submarine systems also force you to think about infrastructure as code. Cable route surveys, repeater spacing, and power feed equipment configurations are now stored in geographic information systems and version-controlled network models. A change to a submarine cable map can be reviewed like a pull request. The lesson for software engineers is simple: if you can model a physical asset as a programmable resource, you can apply the same deployment and observability practices you use for containers and virtual machines.

Undersea Telemetry: What Production Monitoring Looks Like at Depth

Modern autonomous underwater vehicles (AUVs) and remotely operated vehicles (ROVs) generate a stream of sensor data that would look familiar to any observability engineer. Depth, heading, pitch, roll - battery voltage, thruster current, water temperature. And sonar range are published as time-series metrics. Tools like MAVLink, the lightweight messaging protocol originally designed for drones, are widely used for telemetry on underwater vehicles running open-source autopilots such as ArduSub.

The difference is the transport layer. Where a cloud workload can emit metrics over HTTP or gRPC at high frequency, a submerged vehicle often relies on a tether or an acoustic modem. A tether may carry Ethernet, but an acoustic modem might provide only 10 to 100 bits per second with latency measured in seconds. This forces a telemetry design pattern I call prioritized summarization: high-resolution data is stored locally on the vehicle. While only critical state changes and compressed aggregates are transmitted in real time. This is the same idea behind edge computing and remote observability pipelines,, and but taken to an extremeFor more on that pattern, see our guide to building remote observability pipelines for constrained hardware.

When our team instrumented an ROV fleet for subsea inspection, we used a local Prometheus instance on the surface vessel to scrape the ROV's onboard exporter over a TCP-to-serial bridge. The ROV itself ran a small agent that buffered metrics when the link dropped. After the mission, we replayed the buffer into Grafana and Elasticsearch for post-dive analysis. And the architecture wasn't exoticIt was standard observability infrastructure with a very unreliable last mile.

Navigation Stacks for Autonomous Underwater Vehicles Explained

Autonomous navigation underwater is harder than autonomous driving on land because GPS signals don't penetrate water. A submarine or AUV must rely on dead reckoning from a Doppler velocity log (DVL), an inertial measurement unit (IMU), a pressure depth sensor. And a compass. These sensor streams are fused using algorithms like the extended Kalman filter or the unscented Kalman filter. In the ArduSub ecosystem, the vehicle's position estimate is maintained by an EKF that consumes data from a barometer, compass. And DVL when available.

Acoustic positioning systems add another layer. Ultra-short baseline (USBL) and short baseline (SBL) systems use acoustic transponders to calculate the vehicle's position relative to a surface vessel. Long baseline (LBL) systems deploy an array of seabed transponders to create an underwater GPS-like grid. Each of these systems has its own error model, update rate,, and and failure modeA robust submarine navigation stack must continuously evaluate which sensors are trustworthy and gracefully degrade when one is lost.

This is exactly the kind of sensor fusion problem that robotics engineers solve with ROS 2. In a typical ROS 2-based AUV, each sensor publishes to a topic, and a localization node subscribes to those topics to maintain a transform tree. If the DVL loses bottom lock, the EKF increases the covariance on velocity. And the navigation system relies more heavily on the IMU. That kind of explicit uncertainty management is something most web services never have to consider. But it's a valuable mental model for any system that must make decisions on incomplete data.

Acoustic Communication: The Ultimate Low-Bandwidth Constraint

If you think a 3G connection is slow, try sending a command to a submarine over an acoustic modem. Underwater acoustic communication typically operates at data rates from tens of bits per second to a few kilobits per second, depending on range and conditions. Latency can be several seconds for a single round trip. Packet loss is common due to multipath propagation, ambient noise. And thermoclines that bend acoustic energy away from the receiver.

Protocol design under these constraints is a brutal exercise in minimalism. Many underwater acoustic networks use custom modem protocols with small fixed-size frames, forward error correction. And aggressive retransmission timers. The MAVLink protocol, for example, can be adapted to acoustic links by selecting low-rate message streams and disabling high-frequency sensor messages. In practice, an operator may only receive a position update once every 10 to 30 seconds during an acoustic-only mission.

This low-bandwidth reality has a direct analogy in distributed systems: the cost of coordination explodes when the network is slow and lossy. Submarine communication forces engineers to question every byte. Do you send raw sensor values or send only deltas? Do you use a binary protocol or JSON? Do you compress before encryption or encrypt before compression? These are the same questions we ask when optimizing APIs for mobile clients on unreliable networks, except underwater there's no CDN to hide the latency. The engineering discipline transfers directly to edge computing and offline-first application design.

Pressure, Corrosion. And Failure Modes: Hardware Observability Lessons

Every submerged system lives in a hostile environment. A submarine cable repeater sits at depths where pressure exceeds hundreds of bar. Connectors corrode, and biofouling accumulatesShrimp can burrow into cable insulation. These physical degradation processes are slow and often invisible until a failure occurs. The only way to manage them is through continuous condition monitoring and predictive maintenance.

Submarine cable systems monitor electrical parameters like voltage, current. And insulation resistance along the entire cable. A drop in insulation resistance can indicate water ingress long before a full break. Similarly, an AUV can track thruster current draw over time to detect bearing