SBIR Topic Watch Search topics Pricing Browser plugin Sign in

DoW/NAVY · DoW STTR 2027 BAA

DON27TZ02-NV004 — Validated Modular Autonomy for Undersea Multi-Vehicle Coordination

Pre-Release | released 2026-11-04 | opens 2026-12-02 | closes 2027-01-06 | CMMC Level 2 (Self), STTR

SBIR.gov page | DSIP topics app (search DON27TZ02-NV004)

TPOC: Joseph Walsh <[email protected]>; Tory Cobb <[email protected]>

Keywords: Autonomous; Autonomy; Continuous Validation; OpenAUV; Robot Operating System; ROS; ROS2; Validation

Technology areas: None

Objective

Develop software modules for existing autonomous undersea vehicles that support and extend existing system autonomy with multi-vehicle coordination behaviors.

Description

Autonomous undersea vehicles performing expeditionary missions require state-of-the-art cooperative sensing and engagement capabilities. The Navy seeks to enhance those capabilities with modular software designed for reliability and operational effectiveness. The advancement sought is development of a modular coordination layer extending existing single vehicle with decentralized multi-vehicle behaviors to enable autonomous decision making under degraded communications, sensing, and PNT conditions. The software prototype needs to take in mission requirements provided by existing Navy command and control (C2) systems and sensor data provided by multiple platforms and use those inputs to coordinate mission performance with other vehicles. It should be compatible with modular unmanned autonomy architectures already in use by the Navy, such as the Open Autonomous Underwater Vehicle (OpenAUV) architecture and the Robot Operating System 2 (ROS 2). Within those architectures, the prototype must interface with existing autonomy designed for single-vehicle operations with minimal changes to already established systems. When the prototype is disabled or unnecessary, vehicle performance and behavior must conform to what would be expected of an unmodified single vehicle. The multi-mission management functions of the software prototype need to use a decentralized C2 scheme that is robust in low-information environments and that degrades gracefully if communications or sensing are limited. The C2 scheme must demonstrate sufficient scalability to effectively manage many vehicles: tens to hundreds. Real-time C2 is a must. The prototype should assume the primary sensing mode of each vehicle is acoustic. Realistic sensors include forward-look and side-scan sonar, possibly with a synthetic aperture. Cameras may be available, but if so, their field of view should not be assumed to allow for keeping other vehicles in sight. Realistic communications include acoustic modems with transmission rates of 5000 bps or less, possibly much less. Communications methods with higher transmission rates are unlikely to be available and may only be possible at extremely close range. The prototype should assume that access to radar and satellite systems is extremely limited or non-existent. In particular, the prototype should not depend on regular access to global positioning system (GPS) data, and it should take into account the possibility that each vehicle is subject to position, navigation, and timing errors that increase in magnitude as each mission progresses. The software prototype must include as an essential component a method of continuous validation that establishes and quantifies risk and trust for all autonomous decision-making, with an emphasis on repeatability. Deliverables must include the documentation and software necessary to implement this continuous validation method, as well as a report quantifying the efficacy of the method. The ideal prototype will be mission agnostic, instead focusing on a generalized set of multi-vehicle behaviors and objectives. The software prototype should minimize potential negative impacts on mission effectiveness, vehicle endurance, vehicle survivability, and operator workload. The prototype can include enabling hardware, provided that such hardware can be installed on existing autonomous undersea vehicles. The complexity of any vehicle modifications should be minimized. The prototype software and any accompanying hardware should also minimize their overall power consumption. Deliverable reports should include analysis identifying and quantifying any such impacts.

Phase I

Develop a concept for an architecture for a prototype multi-vehicle mission module. Ensure that this architecture should provide an approach for decomposing missions into generalized multi-vehicle behaviors and objectives. Identify and design a method of continuous validation that establishes and quantifies risk and trust for autonomous decision-making. Provide required deliverables that include prototype module architecture designs; documentation for the method of continuous validation; and analysis of how those approaches attain the topic’s goals, including both academic research and validated modeling and simulation.

Phase II

Develop a method of continuous validation and determine the extent to which that method can quantify risk for autonomous decision-making, including repeatability analysis. Validate the method itself against a series of reference vehicles running a set of standard missions. Using the proposed method of continuous validation, develop the prototype software module. Analyze its performance on one or more reference vehicles running standard autonomy. Base the analysis on modeling and simulation, component-level testing, laboratory tank tests, and at least one in-water test outside of a laboratory environment. Demonstrate reliability and operational effectiveness in subsea environments with low-bandwidth communications. Prepare a Phase III commercialization/transition plan.

Phase III / dual use

Assess the performance of the prototype method of continuous validation as it would be used by Fleet stakeholders for their autonomous vehicles. Modify the method as necessary in response to Fleet feedback and any discrepancies between expected and actual performance. Complete the prototype software module, any associated hardware, and the documentation necessary for integration into modular unmanned autonomy architectures already in use by the Navy.

References

  1. Bovio, E., Cecchi, D. and Baralli, F. “Autonomous underwater vehicles for scientific and naval operations.” Annual Reviews in Control, 30(2), 2006, pp. 117-130. https://www.sciencedirect.com/science/article/abs/pii/S136757880600054X
  2. Fanelli, F. “Development and Testing of Navigation Algorithms for Autonomous Underwater Vehicles.” Springer, 2019. https://link.springer.com/book/10.1007/978-3-030-15596-4
  3. Harris, C. A., Phillips, A. B., Dopico-Gonzalez, C. and Brito, M. P. “Risk and reliability modelling for multi-vehicle marine domains.” 2016 IEEE/OES Autonomous Underwater Vehicles (AUV). November 2016, pp. 286-293. https://ieeexplore.ieee.org/abstract/document/7778685
  4. Razdan, R., Akbas, M. I., Sell, R., Bellone, M., Menase, M. and Malayjerdi, M. “Polyverif: An open-source environment for autonomous vehicle validation and verification research acceleration.” IEEE Access, 11, 2023, pp. 28343-28354. https://ieeexplore.ieee.org/abstract/document/10075634
  5. Wang, F., Song, R., Zhou, R., Wang, X. and Chen, L. “Verification and Validation of Intelligent Vehicles: Objectives and Efforts From China.” IEEE Transactions on Intelligent Vehicles, 7 (2), 2022. Pp. 164-169. https://ieeexplore.ieee.org/abstract/document/9826530

Copied from the official source and may be out of date. Confirm dates and requirements in the official solicitation.