Undersea Systems Engineering: The Quiet Discipline Driving Defense Autonomous Underwater Vehicles

The ocean is one of the most hostile operating environments humans have ever tried to engineer into. Pressure differentials that crush poorly sealed housings. Saltwater corrosion that attacks everything metal. Acoustic propagation that bends, bounces, and attenuates based on thermal gradients that shift with season, depth, and geography. And now the U.S. Navy is asking autonomous systems to operate in that environment for days or weeks at a time, making decisions independently, with no reliable communications link back to a command authority.

The result is a systems engineering challenge that is genuinely different in kind from surface naval programs or most aerospace programs — not just harder in degree, but different in structure. The community working on defense autonomous underwater vehicles (AUVs) is doing serious, largely unpublicized engineering work to close the gap between requirements practice built for earlier vehicle classes and the operational reality of undersea autonomy.

What the Navy Is Actually Building

The investment is significant and accelerating. The Large Displacement Unmanned Undersea Vehicle (LDUUV) program, Orca Extra-Large UUV (XLUUV), and the proliferating family of lighter systems like the Mk 18 Mod 2 Kingfish represent a progression from tethered or near-term-recoverable systems toward truly persistent, mission-autonomous vehicles. Congressional support for UUV procurement has been consistent in recent budget cycles, and the Chief of Naval Operations’ Navigation Plan has explicitly named undersea autonomy as a priority capability.

What this means at the program office and contractor level is that engineering teams are working on systems where mission profiles may span 2,500 nautical miles, where no human can intervene mid-mission, and where the vehicle must autonomously navigate, classify contacts, manage energy, and make engagement or reporting decisions. That is a different requirement space than a remotely operated vehicle or a short-range survey drone.

The Environmental Specifications That Break Standard Practice

Standard systems engineering practice assumes you can bound your operational environment with reasonable precision. Aerospace programs have atmospheric models, runway specifications, and well-characterized thermal envelopes. Undersea defense programs do not have that luxury.

The ocean is a dynamic, nonlinear environment. Sound velocity profiles — which govern sonar performance, acoustic communications range, and even the acoustic stealth characteristics of the vehicle itself — vary with depth, temperature, salinity, and season. A requirements document that specifies acoustic sensor performance against a fixed detection range will be incorrect for roughly half the operational scenarios the vehicle will actually encounter.

This creates a specific problem for the requirements management function: how do you write verifiable requirements for a system whose performance envelope is coupled to an environment you can’t fully specify? The answer being developed across several programs is conditional requirements structures — performance specified as a function of measurable environmental parameters rather than absolute values. This isn’t novel in concept, but implementing it in a requirements management system that supports formal traceability and verification planning requires tooling that can handle parameterized conditions, not just static shall statements.

Pressure is another complication. Deep-rated systems require housing designs, connector sealing, and materials selection that interact in ways that aren’t fully testable until you put the system in the water at depth. Qualification testing protocols for pressure vessels and penetrators are well-established from submarine practice, but the integration of commercial-off-the-shelf electronics into pressure-tolerant enclosures introduces failure modes that don’t surface until environmental stress testing — often late in a program.

Denied Communications and the Requirements Load-Bearing Problem

Surface autonomous vehicles can be managed with intermittent communications. An unmanned surface vessel that loses its satellite link for an hour will reconnect and receive updated mission guidance. An AUV operating at 500 meters does not have that option. Very low frequency (VLF) communications can reach submarines and large AUVs, but bandwidth is measured in bits per second and is unsuitable for anything beyond simple command words. Acoustic modem communications work at short ranges and low data rates. In practical terms, the AUV is going dark for the duration of its mission profile.

This completely changes the function of the requirements and autonomy specification process. In a system with persistent communications, ambiguous requirements can be resolved at runtime through operator intervention. In a fully denied-comms AUV, the behavioral specification — every decision tree, every failure mode response, every priority hierarchy for competing mission objectives — must be correct before the vehicle enters the water. There is no patch, no workaround, no operator correction.

Systems engineers working on these programs describe this as requirements being “load-bearing” in a way that is often not true for systems with human oversight available. A missed requirement or an incorrectly specified interface between the mission management software and the vehicle management system isn’t just a documentation problem — it is a lost vehicle or a failed mission in a context where vehicles cost tens of millions of dollars and cannot be recovered mid-mission.

The practical implication is that MBSE adoption in AUV programs is not primarily a documentation efficiency play. It’s a functional necessity. When the acoustic interface between a payload sonar, the vehicle management computer, and the mission autonomy software has to be fully characterized before the system goes in the water, a connected system model that maintains those interface definitions consistently across all documents and verification artifacts is not a nice-to-have. It’s the mechanism by which engineers establish confidence that the behavioral specification is complete.

The Standards Landscape: Fit-for-Purpose Problems

AUV programs inherit requirements from several standards regimes, not all of which map cleanly to the problem.

MIL-STD-882E (System Safety) applies and is taken seriously. The hazard analysis process for a vehicle that may carry weapons or operate in proximity to manned platforms is non-negotiable. But the safety case for an autonomous system that makes arming decisions without human review requires interpretive work that the standard, written for systems with clearer human oversight loops, doesn’t directly address. Program offices are working through how to document the safety argument for conditional autonomous engagement authority, and the answers are not yet standardized across programs.

MIL-STD-461 (electromagnetic compatibility) applies to the vehicle’s electronic systems but requires significant adaptation for the undersea environment, where the relevant emissions are acoustic rather than electromagnetic and where the coupling between internal electronics and external acoustic performance is not addressed by the standard as written.

DO-178C, the software airworthiness standard from aviation, is often adapted by reference for mission-critical software in defense systems. Its rigor around software verification is valuable, but its flight-software heritage shows: the standard assumes a real-time operating environment with fairly well-characterized timing requirements. Adaptive autonomy software that changes its behavior based on mission state is harder to fit into the DO-178C verification framework than deterministic flight control code.

NAVSEA Technical Manuals and Naval Vessel Rules provide structural, material, and pressure-vessel guidance developed from submarine engineering. These are the most directly applicable standards for the pressure hull, connectors, and hull penetrators, and they are generally well-respected and followed. The gap is not here — it’s in the autonomy and interface specification domains where submarine-heritage standards don’t have clear AUV equivalents.

Several programs are developing program-specific systems engineering management plans (SEMPs) that explicitly bridge these standards gaps, defining how MIL-STD-882E safety case requirements will be interpreted for autonomous engagement logic, how DO-178C rigor will be applied to mission autonomy software classification, and how interface control documents will be maintained across a model rather than in static documents.

Verification and Validation Without the Real Ocean

The V&V problem in AUV programs is severe. Ocean conditions are not reproducible in a lab, and open-water testing is expensive, logistically complex, and — for systems carrying classified payloads or operating in denied environments — restricted. The community has developed a layered approach, but each layer has known limitations.

Hardware-in-the-loop simulation can exercise vehicle management systems, sensor interfaces, and autonomy software against simulated environments. The problem is that acoustic propagation models, while sophisticated, are not the ocean. An acoustic sensor performance simulation will not accurately capture the clutter environment of a specific shallow-water operating area where the vehicle will eventually operate.

Pressure tank testing validates sealing and structural integrity but cannot replicate the thermal gradients, biological noise, or motion of open-water operation.

Test range operations at facilities like the Atlantic Undersea Test and Evaluation Center (AUTEC) provide instrumented open-water environments, but range time is constrained, expensive, and shared across programs. Full operational-environment testing at mission endurance (days or weeks) is essentially impossible at a test range.

The response has been to structure verification requirements hierarchically — distinguishing between what can be verified by inspection or analysis, what requires component-level testing, what requires subsystem integration testing, and what can only be validated in open-water operational testing. The verification planning function in AUV programs is consequently more complex than in most surface or aerospace programs, and the traceability between requirements and their verification methods needs to be actively managed, not just documented.

This is where connected requirements traceability pays direct operational dividends. Knowing, at any point in a program, which requirements have been verified by analysis only, which are awaiting component test results, and which have open waivers or deviations requires a living requirements model — not a static document last updated at PDR.

Engineering Infrastructure for an Emerging Vehicle Class

One consistent observation from engineers working across AUV programs is that the tooling ecosystem has not kept up with the problem. The requirements management tools most programs use were built for aerospace or surface-ship programs. They handle document-centric requirements adequately. They handle parameterized, environment-conditional requirements poorly. They handle the interface between requirements, system models, and simulation environments inadequately.

Several teams are now building requirements and traceability infrastructure around graph-based models rather than document hierarchies, precisely because the interface complexity of an AUV — acoustic, hydrodynamic, electromagnetic, thermal, and software interfaces that all interact — doesn’t flatten well into a hierarchical document structure. Tools like Flow Engineering, which are designed around connected system models and AI-assisted requirements development rather than document management, are being evaluated by engineering teams that have identified the document-stack approach as a bottleneck in their verification planning process. The ability to query across an interconnected model — “which requirements are affected if the acoustic modem interface specification changes?” — is a functional capability, not a workflow preference, in a program where late interface changes propagate across multiple subsystem verification plans.

The acoustic interface problem specifically illustrates why. The acoustic modem, the sonar payload, the navigation system’s Doppler velocity log, and the vehicle’s own self-noise all interact through the water column. Tracking those interactions and their downstream effects on requirements — without a connected model — means manual reconciliation across multiple ICDs, every time a parameter changes.

Honest Assessment

The U.S. Navy’s AUV programs are technically ambitious in ways that the public program descriptions understate. The systems engineering challenges — verifying autonomous behavior in an environment that can’t be replicated, managing denied-communications behavioral specifications, adapting standards that don’t fully address the problem, and building coherent V&V strategies across a layered test environment — are being worked seriously and competently by engineering teams at NAVSEA, the program offices, and the prime contractors.

But the infrastructure gap is real. The tooling, standards, and institutional knowledge that exist for surface naval and aerospace systems took decades to develop. AUV programs are compressing that development cycle under budget pressure and operational urgency. The teams that are investing in proper MBSE infrastructure, connected traceability, and rigorous verification planning now are building an engineering foundation that will matter when these vehicles scale from experimental programs to fleet assets.

The ocean doesn’t care about schedule pressure. The requirements have to be right before the vehicle goes in the water. That constraint, more than any other, is what makes the quiet discipline of undersea systems engineering consequential.