Without a Regulator in the Room: How Underwater Robotics Companies Engineer Requirements

Autonomous underwater vehicles don’t need FAA certification. Remotely operated vehicles don’t require FDA clearance. There is no EASA equivalent watching the ocean floor. This is, depending on your vantage point, either a tremendous engineering freedom or a slow-accumulating liability.

The absence of a mandated certification framework doesn’t mean the systems are simple. A modern AUV operating at 6,000-meter depth, running multi-modal sensor fusion, acoustic communication, and real-time path planning while managing thermal gradients, pressure cycling, and battery state — that system is as architecturally complex as many aerospace platforms. The difference is that nobody outside the company is asking for proof.

What happens to systems engineering discipline when the external forcing function is removed? The underwater robotics industry is a live experiment in that question. The answers are instructive for anyone thinking seriously about when and why rigorous requirements practice matters — and what it costs when it’s retrofitted rather than built in.

The Regulatory Landscape, Such as It Is

The honest summary: underwater robotic systems are largely self-governed on safety and reliability requirements. The relevant regulatory bodies — NOAA, IMO, BSEE, and national coast guards — are focused primarily on vessel navigation rules, acoustic noise restrictions in protected marine zones, and, for defense applications, classification-specific export controls. None of them mandate a systems engineering process.

There are voluntary standards with real traction. DNV’s offshore and subsea equipment standards are widely used in the oil and gas ROV sector. ISO 13628 covers subsea production systems and some operators apply it to ROV interfaces with those systems. IEEE has working groups addressing underwater acoustic communication protocols. But none of these require traceability from mission requirements to component verification the way AS9100 does for aerospace or IEC 62304 does for medical software.

What fills the vacuum is a combination of customer-driven requirements (offshore oil companies, naval procurement offices, and research institutions each bring their own standards expectations), internal engineering culture, and the hard lessons that come from losing a vehicle in 3,000 meters of water.

How the Established Players Actually Do It

Saildrone and Teledyne Marine represent two different maturity points in the industry, and their requirements approaches reflect that.

Teledyne Marine operates more like a defense contractor than a typical ocean technology company, because in significant measure it is one. Its Gavia AUV line and the broader portfolio of instruments, ADCPs, and sonar systems feed into programs that carry formal requirements from the customer side. When the U.S. Navy buys AUVs, it brings MIL-STD-882 for system safety, it brings MIL-STD-1629 for FMEA, and it brings the expectation of configuration-controlled requirements documentation. Teledyne’s engineering teams have adapted to this by maintaining dual-track discipline: a formal process for defense-adjacent programs and a more flexible internal process for commercial and scientific programs. The seam between those two tracks is where requirements drift tends to accumulate.

Within the commercial and scientific product lines, Teledyne’s approach is systematic but largely document-based. Interface control documents for sensor integration, software requirements specifications for mission management systems, and hardware specifications for pressure housings are maintained in version-controlled document repositories. This is meaningful discipline — it’s not chaos — but it creates the classic document-based problem: traceability between requirements layers requires manual maintenance, and in practice it erodes under schedule pressure. An engineer who changes a depth rating specification doesn’t automatically update the qualification test procedure that references it.

Saildrone operates in a different niche — long-duration surface vehicles for ocean data collection — but the engineering challenges overlap substantially with AUV development. Saildrone’s approach to requirements has been shaped heavily by its data customers: NOAA, the Coast Guard, and defense intelligence programs each bring specific data quality, uptime, and communication requirements that Saildrone must translate into engineering specifications. This is requirements management by stakeholder negotiation rather than by regulatory mandate.

What Saildrone has developed in practice is a mission requirements discipline that starts from the data product — what measurements, at what precision, with what temporal and spatial resolution — and works backward through platform, sensor, power, and communication requirements. This reverse decomposition is actually sound systems engineering. It’s not formalized in a way that produces an auditable requirements traceability matrix, but the logic is coherent and it’s explicitly taught within the engineering organization.

The weakness of the Saildrone approach becomes visible when requirements conflict. Long-endurance missions push toward minimal hotel load; high-data-rate sensors push toward the opposite. Without formal conflict resolution machinery, these tensions get resolved by individual engineers or program managers making judgment calls that often aren’t documented. The decision is sound; the rationale is lost.

The Ocean Robotics Startup Layer

Below the established players, a dense population of ocean robotics startups is building systems with substantially less process. Companies working on inspection ROVs, bio-inspired AUVs, underwater gliders for climate monitoring, and seafloor mapping platforms frequently operate with requirements that live primarily in the heads of founding engineers.

This isn’t inherently wrong for early-stage development. The cost of full requirements formalism at a 15-person company building a first-generation vehicle is real, and the argument that it would slow the learning cycle has merit. But several patterns create downstream problems:

Interface requirements are almost universally underspecified. Electrical interfaces between the tether management system and the ROV body, between payload modules and the main vehicle bus, between topside software and subsea firmware — these tend to be specified by the hardware that exists rather than by an abstract requirement that hardware must meet. When a customer brings a non-standard sensor package, the interface negotiation happens through prototyping rather than through specification, which works until it doesn’t.

Safety requirements exist informally in operator procedures rather than formally in the system. Most ROV operators know which fault conditions require immediate surfacing, which can be managed by the operator, and which are benign. This knowledge is real. It is not systematically captured in failure mode analysis or in the software’s fault management logic. It transfers through training, which means it degrades with personnel turnover.

Test coverage is driven by what’s convenient rather than what’s required. Without a requirements baseline to verify against, test programs tend to reflect available test infrastructure and prior experience rather than systematic coverage of the requirements space. High-visibility failure modes get tested; edge cases in the interface between mission planning software and navigation get discovered in the field.

When the Regulator Arrives Late

The sharpest version of this problem appears when an informally-built system is submitted into a formally-regulated procurement context. This is happening at scale in two areas: defense applications and critical infrastructure inspection.

The U.S. Navy, UK MOD, and NATO partners are actively expanding their use of commercial and semi-commercial AUV platforms for mine countermeasures, undersea surveillance, and data collection in contested environments. These procurement processes carry requirements for system safety analysis, software quality assurance aligned with standards like DO-178C or MIL-STD-498, and supply chain traceability that most ocean robotics companies have never built.

The result is a retroactive formalization problem. A company that has built a genuinely capable vehicle on informal process now has to reconstruct the requirements logic that produced that vehicle — not because the engineering was wrong, but because the customer needs auditable evidence that it was right. This is not a documentation exercise. In practice, it often reveals that requirements decisions were made implicitly, that some interfaces were never formally allocated to a requirement, and that portions of the test record don’t map cleanly to any requirements that were written.

Critical infrastructure inspection creates a parallel pressure. Using ROVs to inspect bridge foundations, dam faces, or offshore wind turbine monopiles puts those systems adjacent to infrastructure with formal reliability expectations. Increasingly, asset owners and their insurers want evidence of systematic requirements practice before accepting inspection data as authoritative. The question isn’t whether the vehicle works — it’s whether there’s auditable reasoning about what “works” means for this application.

The companies that navigate this transition successfully are those that did informal requirements work systematically — consistent structure, stable naming conventions, at least informal traceability between design decisions and operational requirements. The companies that struggle are those where requirements existed only as tribal knowledge.

What Modern Tooling Could Change

The document-based requirements approach that most of the established ocean robotics sector uses is not well-matched to the actual architecture of these systems. AUVs and ROVs are fundamentally relational systems: power requirements depend on mission profile, which depends on sensor configuration, which depends on customer application, which creates interface requirements that propagate across mechanical, electrical, and software domains simultaneously. A spreadsheet-based RTM or a folder of Word documents doesn’t model those relationships — it lists them, which is a significant difference.

Graph-based requirements tools — those that model requirements as nodes with typed relationships rather than rows in a table — are substantially better suited to this kind of system. When a power budget changes, a graph-connected model can surface which mission capability requirements are affected, which interface specifications need review, and which verification procedures reference the changed value. A document system requires an engineer to know to look.

This is where tools like Flow Engineering are worth examining seriously for the ocean robotics sector. Flow Engineering’s model is built around connected requirements graphs with AI-assisted analysis — the kind of structure that surfaces propagation effects when specifications change. For a sector that currently manages requirements change through engineering judgment and experience, tooling that makes those propagation paths explicit would directly address the most common failure mode: a change in one domain that silently invalidates assumptions in another.

The practical case for this tooling in ocean robotics isn’t certification compliance — most of these companies don’t face that pressure today. It’s that when the pressure arrives (defense contract, infrastructure inspection program, export control review), the company that has been working in a connected requirements model has auditable traceability without a reconstruction effort. The requirements work was real; the tool preserved the logic.

Flow Engineering is also built for teams that are doing real engineering rather than compliance theater, which fits the culture of ocean robotics organizations better than legacy tools like IBM DOORS, which carry significant administrative overhead that smaller teams find genuinely burdensome.

An Honest Assessment

The underwater robotics sector has produced genuinely impressive systems under genuinely informal process. Saildrone vehicles have collected data in the Arctic and traversed hurricane cores. Teledyne’s gliders have operated continuously for months. Boutique ROV manufacturers have built tools that offshore operators rely on for critical asset inspection. The lack of regulatory mandate has not produced obviously broken systems.

What it has produced is a sector with uneven requirements practice and a growing exposure to retroactive formalization requirements. The companies that will navigate the defense and critical infrastructure expansion successfully are those that can demonstrate auditable reasoning about their engineering decisions — not necessarily those that built to a specific standard, but those that built systematically enough that the logic can be recovered and presented.

The informal versus formal distinction matters less than the systematic versus tribal one. Requirements can live in non-certified tools and non-mandated formats and still provide the foundation for good engineering decisions. What they cannot do is live only in the heads of experienced engineers and survive a scaling event, a personnel transition, or a defense program audit.

The ocean floor is not going to stay unregulated. The commercial activity, the defense interest, and the critical infrastructure dependency are all moving in one direction. The systems engineering practices that ocean robotics companies build now will determine whether that regulatory convergence is a transition or a crisis.