DON26TZ01-NV009 TITLE: Robust Universal Adaptive Denoising Technology
OUSW (R&E) CRITICAL TECHNOLOGY AREA(S): Applied Artificial Intelligence (AAI)
COMPONENT TECHNOLOGY PRIORITY AREA(S): Advanced Computing and Software;Trusted AI and Autonomy
PROJECTED CMMC LEVEL REQUIREMENT: Level 2 (Self)
OBJECTIVE: Develop robust denoising approaches that are highly adaptive and effective.
DESCRIPTION: Signal denoising has shown to be highly effective in improving performance of signal processing radio frequency and acoustic sensing systems. The main hindering signal in these applications is noise as it degrades the ability to sense low level signals masked by ambient noise sources which may be external to the sensor or generated by the sensor itself. The main goal of this SBIR topic is to develop a denoising technology that suppresses noise while preserving the underlying signal features. Traditionally, denoising methods have struggled to maintain performance when presented with highly non-stationary or complex noise patterns. The traditional approaches typically require extensive and time-consuming tuning to achieve desired performance. On the other hand many of learning-based methods have demonstrated excellent denoising performance but suffer from limited robustness. Therefore, the method’s performance will drop if the training conditions do not adequately reflect the characteristics of the operational environment. The Navy seeks improvements in denoising performance greater than 10 dB.
For such a system installed on an aircraft, it will experience both wind- and aircraft-generated noise. That noise has components that are narrow band (< 10 Hz wide) and broadband (10s to 100s of Hz wide). The spectrum of interest for sensing extends from approximately 10 Hz to 1000 Hz. When compared with more traditional active noise cancellation techniques, the denoising approach should be capable of providing 6 dB of additional cancellation and show potential to deliver 10 dB or more cancellation.
PHASE I: Develop concepts for a robust denoising approach requiring minimal training and are effective in highly non-stationary or complex noise environments. Modeling and simulation to include laboratory measurements to assess the efficacy of the approach based on an in-air or ground-based mobile acoustic sensing system is desired. Consider how the approach may be extended to a radio frequency (RF) system operating in the 1-10 GHz range. The Phase I effort will include prototype plans to be developed under Phase II.
PHASE II: Develop and demonstrate an end-to-end denoising approach on an acoustic frequency sensing system in a laboratory environment and ultimately in a representative operational environment. The prototype assessment should include narrow and broadband noise removal performance while preserving desired signal characteristics, robustness in the presence of non-stationary noise environments. At least 10 dB of noise cancellation is needed with 15 dB desired over traditional active noise cancellation techniques. Consideration for the ease of integration and fielding should be made. Demonstrating the efficacy of the denoising approach on a variety of host platforms is desired. Further refine the extension of the denoising technique to use by RF sensing systems.
PHASE III DUAL USE APPLICATIONS: Support the transition to Navy use.
A universal highly adaptive denoising approach could find applications across remote sensing, communication systems, biomedical signal processing, audio restoration, and image enhancement.
REFERENCES:
KEYWORDS: Denoising; Signal Processing; Deep Learning; Non-Stationary; Acoustic; Radio Frequency
| 5/19/26 | Q. | Would it be fair to assume that this topic pertains to an acoustic system facing mechanical noise and/or environmental noise? |
| A. | Undesired external noise sources including environmental and man-made as well as sensor noise itself is to be addressed. | |
| 5/18/26 | Q. | Can we assume a multichannel sensor input (regardless of whether acoustic or RF) without special hardware requirements or any other a priori knowledge, including as to placement/orientation of the microphones? |
| A. | No, not universally. In most cases individual sensor inputs from an array of known orientation are available but that will not always be the case. For example, in some instances the array inputs are already beamformed as a single output. | |
| 5/10/26 | Q. | The topic references generating tests from unstructured documentation to improve preservation specifications for debloating workflows. Should proposals assume that improving exception-path preservation and configuration-dependent execution behavior are priority areas for augmentation, given their known role in debloating regression failures? |
| A. | Both examples are desirable areas for augmentation. | |
| 4/29/26 | Q. | Does the Navy anticipate that the Phase II prototype should integrate with containerized CI/CD environments (e.g., Platform One–style pipelines), or is the expected transition environment primarily research-grade tooling used to evaluate debloating effectiveness? |
| A. | In Phase II, the prototype should integrate with CI/CD environments such as Navy software factories. | |
| 4/29/26 | Q. | Are the generated tests intended primarily to increase behavioral coverage for coverage-driven debloating tools, or should they also function as semantic preservation specifications capable of validating correctness beyond execution-path coverage? |
| A. | The primary intent behind the generated tests is to more effectively drive the debloaters. | |
| 4/29/26 | Q. | Should Phase I focus primarily on demonstrating the feasibility of automated feature-intent extraction and documentation-driven test generation, or is the expectation to also implement an operational prototype capable of producing executable test suites from real repositories? |
| A. | The Phase I prototype is a proof of concept to demonstrate feasibility of approach. | |
| 4/29/26 | Q. | The topic description suggests AI-based extraction of feature intent from unstructured artifacts. Is the Navy primarily interested in LLM-driven semantic interpretation of documentation for test generation, or are hybrid approaches combining static analysis, symbolic reasoning, and LLM-assisted inference equally acceptable? |
| A. | All approaches are acceptable that can address the challenges described in the topic description. We do not require any specific technique. | |
| 4/29/26 | Q. | The Objective and Description indicate that generated test suites will serve as inputs to proactive cybersecurity tools such as debloating systems. Has the Navy identified specific debloating tools that proposers should assume as integration targets, or should proposals remain tool-agnostic while demonstrating compatibility with representative research or open-source debloating frameworks? |
| A. | Proposals should focus on test augmentation. The tests could be consumed by various debloating tools. | |
| 4/29/26 | Q. | Should we assume there is access to the source and repo docs such as Readme.md, API docs, deploy config data (helm), and current test cases? |
| A. | Yes. | |
| 4/29/26 | Q. | What languages will be the focus: C/C++, Java, Python, golang? |
| A. | Any source language is acceptable for Phase I proof of concept. | |
| 4/27/26 | Q. | For DON26BZ01-NV030, could you clarify whether the expected solution is intended to operate primarily before build artifact generation (e.g., optimizing material selection, geometry processing, and AM parameter sets prior to creation of the machine build package), or whether the Navy is also interested in post-generation analysis of build artifacts to identify unused or unnecessary structures, parameters, or features that could be removed to improve performance or reduce defects?
In particular, if post-generation approaches are within scope, should proposers assume access to sufficient internal representation of the build package to support feature-level analysis, or is the expectation that optimization occurs earlier in the digital-twin workflow where full lifecycle parameter visibility is available? |
| A. | The scope can include analysis of build artifacts and the configuration used to generate them. |
** TOPIC NOTICE ** |
The Navy Topic above is an "unofficial" copy from the Navy Topics in the DoW FY-26 Release 1 SBIR BAA. Please see the official DoW Topic website at www.dodsbirsttr.mil/submissions/solicitation-documents/active-solicitations for any updates. The DoW issued its Navy FY-26 Release 1 SBIR Topics pre-release on April 13, 2026 which opens to receive proposals on May 6, 2026, and closes June 3, 2026 (12:00pm ET). Direct Contact with Topic Authors: During the pre-release period (April 13, through May 5, 2026) proposing firms have an opportunity to directly contact the Technical Point of Contact (TPOC) to ask technical questions about the specific BAA topic. The TPOC contact information is listed in each topic description. Once DoW begins accepting proposals on May 6, 2026 no further direct contact between proposers and topic authors is allowed unless the Topic Author is responding to a question submitted during the Pre-release period. DoD On-line Q&A System: After the pre-release period, until May 20, 2026, at 12:00 PM ET, proposers may submit written questions through the DoW On-line Topic Q&A at https://www.dodsbirsttr.mil/submissions/login/ by logging in and following instructions. In the Topic Q&A system, the questioner and respondent remain anonymous but all questions and answers are posted for general viewing. DoW Topics Search Tool: Visit the DoW Topic Search Tool at www.dodsbirsttr.mil/topics-app/ to find topics by keyword across all DoW Components participating in this BAA.
|