DON26BZ01-NV022 TITLE: Extremely Wide Band Digital Recording System for Artificial Intelligence/Machine Learning Development
OUSW (R&E) CRITICAL TECHNOLOGY AREA(S): Applied Artificial Intelligence (AAI)
COMPONENT TECHNOLOGY PRIORITY AREA(S): Advanced Computing and Software;Integrated Sensing and Cyber;Trusted AI and Autonomy
PROJECTED CMMC LEVEL REQUIREMENT: Level 2 (Self)
The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), 22 CFR Parts 120-130, which controls the export and import of defense-related material and services, including export of sensitive technical data, or the Export Administration Regulation (EAR), 15 CFR Parts 730-774, which controls dual use items. Offerors must disclose any proposed use of foreign nationals (FNs), their country(ies) of origin, the type of visa or work permit possessed, and the statement of work (SOW) tasks intended for accomplishment by the FN(s) in accordance with the Announcement. Offerors are advised foreign nationals proposed to perform on this topic may be restricted due to the technical data under US Export Control Laws.
OBJECTIVE: Develop a small and dense data recorder that can store > = 8 Petabytes of information in < = 4 u of 19-inch rack space, will be scalable and flexible in nature, and will demonstrate the interfacing to > = two different interface protocols each supporting > 400 GB/sec data transfer rates for > = 30 seconds.
DESCRIPTION: In today’s environment, emphasis is put on how Artificial Intelligence/Machine Learning (AI/ML) can solve most of the Department of War’s (DOW) problems as long as the AI/ML algorithms are trained correctly. This training requires vast amounts of relevant data. Unlike commercial websites where the algorithm developers can have the public train them based on security selection images, the DOW does not have vast stores of relevant data sets much less a global community to train the algorithms. Unfortunately, very few to none of the fielded program of record (POR) systems have the ability to record (at the tactical edge) relevant data products in sufficient quantity to help algorithm developers.
This SBIR topic is intended to develop extremely deep sensor data recorders for implementation/fielding on tactical platforms for tactical sensors at the tactical edge. These recording devices must be able to be integrated easily into the platform’s sensor suite and be able to record the relevant data products for use in future algorithm development and training.
These recorders must easily adapt to various networking infrastructures (e.g., InfiniBand, NVLINK, PCIe, and or Ethernet, etc.) and support the extreme streaming bandwidths for wideband (500Mhz and greater I/Q data) Radio Frequency (RF) digital data and high definition (4 K or greater) streaming video. These recording devices must be scalable in nature, at a minimum take up less than or equal to 4u of face plate volume in a 19-inch rack, and record greater than 8 petabytes of storage.
These devices must meet all NSA data at rest encryption requirements and be developed in a manner to easily acquire a volatility certification letter. References 7, 8, and 9 are provided for informational purposes, further information may be provided to Phase II awardee. These prototype devices will be installed on manned and unmanned platforms. With that in mind, they must be developed with remote and/or autonomous operations in mind. These prototype devices will deliver the hardware and the requisite software to perform recording, playback, librarying, and search functions for the data on the devices.
Key requirements:
- Less than or equal to 4u of 19-inch rack volume
- Must meet class B shipboard installation Environmental Qualification Testing (EQT)
- Greater than 8 petabytes of data storage
- Must meet data at rest security requirements
- Must meet non-volatility certification requirements
- Have networking architecture demonstrating ability to configure to multiple types of networks
- Have a minimum of two different networking options where each networking option can sustain > 400 GB/s data rate
- Compliance with shipboard installation environmental qualification requirements
- Ability to perform data at rest encryption and the ability to meet volatility requirements for system posture changes
- Ability to consume data from a defined sensor and parse/tag this data
- Ability to record and playback from both local and remote users
Conduct, at a minimum, two lab demonstrations at the developer’s facility and one integration and demonstration at a government lab. (Note: The government lab will provide testing and validation of the capabilities and provide immediate feedback to the developer for further refinement of the prototype.) Work with the government lab to develop a shipboard installation and testing plan. If the Phase II Option is exercised, focus on getting the prototype system ready to be installed and tested at sea during a government-defined testing event.
Work produced in Phase II may become classified. Note: The prospective contractor(s) must be U.S. owned and operated with no foreign influence as defined by 32 U.S.C. § 2004.20 et seq., National Industrial Security Program Executive Agent and Operating Manual, unless acceptable mitigating procedures can and have been implemented and approved by the Defense Counterintelligence and Security Agency (DCSA) formerly Defense Security Service (DSS). The selected contractor must be able to acquire and maintain a secret level facility and Personnel Security Clearances. This will allow contractor personnel to perform on advanced phases of this project as set forth by DCSA and ONR in order to gain access to classified information pertaining to the national defense of the United States and its allies; this will be an inherent requirement. The selected company will be required to safeguard classified material during the advanced phases of this contract IAW the National Industrial Security Program Operating Manual (NISPOM), which can be found at Title 32, Part 2004.20 of the Code of Federal Regulations.
PHASE I: Develop and provide a detailed schedule out through Phase II options, as well as a detailed technical description as to how they will achieve success. The initial deliverable of the Phase I award will be a kickoff meeting detailing how they will get to the final briefing.
The final briefing will show specifically to meet the following requirements:
- Less than or equal to 4u of 19inch rack volume
- Meeting class B shipboard installation Environmental Qualification Testing (EQT)
- Greater than 8 Petabytes of data storage
- Data at rest security requirements
- Non-Volatility certification requirements
- Networking architecture demonstrating ability to configure to multiple types of networks.
- Interface descriptions on how external systems will interface and operate the prototype device remotely and locally
- Examples of the user interfaces and the schema for formatting, recording, librarying, and playback
- Cost and schedule program management plan
- Phase I option will be showcasing software modules and fundamental breadboard designs and present the detailed plans for Phase II and Phase II option.
PHASE II: Hold a kickoff meeting with a detailed development plan including costing (recurring and non-recurring separated) development; and detailed security and testing plans
These plans will include detailed:
- technical plans
- security plans
- EQT plans
- lab testing plans (both at developers facility and at government labs) utilizing different types of networks.
- ship installation and at sea testing (Phase II Option, if exercised, will be integration and testing at sea)
After the kickoff meeting and with government concurrence of the plan, the awardee will focus on developing the solution meeting all the security, environmental qualifications, and performance requirements agreed to.
The system to be developed shall meet the following requirements:
- < = 4u of 19 inch rack space
- > = 8 Petabytes of storage
- Minimum of two different networking options where each networking option can sustain > 400 GB/s data rate
- The prototype system will show compliance with shipboard installation environmental qual requirements
- The prototype system shall show the ability to perform data at rest encryption and the ability to meet volatility requirements for system posture changes.
- The prototype system shall show the ability to consume data from a defined sensor and parse and tag this data.
- The prototype system shall demonstrate the ability to record and playback from both local and remote users
There will be at a minimum two lab demonstrations at the developers facility and one integration and demonstration at a government lab. The government lab will provide testing and validation of the capabilities and provide immediate feedback to the developer for further refinement of the prototype.
- The awardee will work with the government lab to develop a shipboard installation and testing plan.
- The Phase II option Option, if exercised, will focus on getting the prototype system ready to be installed and tested at sea during a government defined testing event.
It is probable that the work under this effort will be classified under Phase II (see the Description section for details).
PHASE III DUAL USE APPLICATIONS: The awardee will clearly and in detail describe how this capability will transition to a Navy program of record (POR). This plan will also describe how it will be used in the POR and the initial concept of what data products will be recorded.
Any commercial industry looking for low cost optical processing on extremely large data sets will benefit from this technology.
REFERENCES:
KEYWORDS: Digital Recorders: Radar Interfaces; Combat Control Interfaces; Electro Optic data; Continuous Digital Intermediate Frequency; CDIF; Burst Digital Intermediate Frequency; BDIF
| 5/19/26 | Q. | Can we confirm that the requirement is indeed 400GB/s and not the much more achievable 400Gb/s? |
| A. | The requirement is > =400GigBytes/sec for real-time recording. | |
| 5/19/26 | Q. | What Protocols are used to connect the Sensor Suite to the data recorder? Or are there any specific proprietary applications needed to collect and parse this raw data? |
| A. | Data is required to be stored and played back. Data labeling is part of the design and needs to support different data types on the platform. At a minimum, the exact start date and time (Zulu time) should be used in all filenames. Different Data types as stored on the device should be easily queried and searched. This data when in playback should be synchronized. | |
| 5/18/26 | Q. | 1. For the >400 GB/s requirement, is performance measured at network ingress, sustained storage write rate, or end-to-end recording throughput including parsing, metadata tagging, encryption, and storage commit?
2. Can the >400 GB/s throughput be distributed across multiple ports/interfaces? If so, are there any port-count limitations? 3. Must both interface options independently support >400 GB/s, or can one interface meet the full requirement while the second supports a lower data rate? 4. Are Ethernet-based transports such as RoCEv2, TCP, UDP and RDMA countable as multiple streaming interfaces, or one? 5. Is the >400 GB/s requirement measured as raw line rate (header + payload) or payload throughput only? 6. Must sustained storage writes maintain >400 GB/s continuously, or is staged buffering acceptable provided no data loss occurs during the required capture interval? 7. What is the expected retention time of this data? 8. The proposal mentions IQ Data as well as video links, is there a specific transport protocol that is used? (i.e. VITA-49 over UDP/Video over ARINC 429) Can this downstream recorder steer the upstream sensor source streaming physical layer? 9. Is the recorder expected only to receive and record upstream sensor streams, or should it also provide control-plane functions that can configure, steer, throttle, or otherwise manage the upstream sensor/source streaming physical layer? 10. Are there required or preferred timing/synchronization interfaces such as 1PPS, IEEE-1588/PTP, IRIG-B, or GPS timing? 11. Is the =8 PB requirement intended as fully usable storage capacity after RAID/parity/formatting overhead? 12. For Phase I feasibility demonstrations, is FIPS 140-validated commercial encryption acceptable, or is full CSfC compliance expected at this stage? 13. Is the 4U requirement intended to include the complete recording system, including networking, compute, storage media, power/cooling, encryption hardware, and any required timing/control modules, or may some support infrastructure be external? 14. For the playback requirement, should "playback" be interpreted as reproducing the recorded stream at original or line-rate timing through an output interface, or is an interface to offload data to another host? |
| A. | 1. The requirement is >=400GigBytes/sec for real-time recording. Playback has to meet real time for all data. Goal is data playback at faster and slower than the recorded rates. Transfer of data can be an offline process. The intent is to stream continuously > = to 400 GB/Sec. This can be an aggregate of the streams happening simultaneously (i.e. 8 x 50 GB/Sec streams all happening simultaneously - or other variations on the theme). Gaps in data are not acceptable. Loss data is not acceptable.
2. See answer 1. 3. These recorders must easily adapt to various networking infrastructures (e.g., InfiniBand, NVLINK, PCIe, and or Ethernet, etc.) and support the extreme streaming bandwidths for wideband (500Mhz and greater I/Q data) Radio Frequency (RF) digital data and high definition (4 K or greater) streaming video. These recording devices must be scalable in nature, at a minimum take up less than or equal to 4u of face plate volume in a 19-inch rack, and record greater than 8 petabytes of storage. As long as your aggregate meets the design requirements. Networking architecture demonstrates configuring of multiple types of networks. A minimum of two different networking options where each networking option can sustain > 400 GB/s data rate. 4. See Answer 3. 5. Data is required to be stored and played back. Data labeling is part of the design and needs to support different data types on the platform. At a minimum, the exact start date and time (Zulu time) should be used in all filenames. Different Data types as stored on the device should be easily queried and searched. This data when in playback should be synchronized. 6. The requirement is >=400GigBytes/sec for real-time recording with no data loss. 7. Greater than 5 years. 8. We do not have this information. 9. In no way is the request asking for the recorder to control sensor devices. 10. Timing source will be available at installation at the required accuracy. This information is required as part of the proposal submittal so we cannot provide an answer for this. 11. The requirement is to store > = 8 Petabytes of information in < = 4 u of 19-inch rack space with 27 inch depth. The recorder should not remove any data from the real-time streams including any header information. The storage size requirement is to store >= 8 Petabytes of data. 12. A DAR solution is required for the Wideband Recorder. DAR using NSA Commercial Solutions for Classified (CSfC) for commercial usage should be acceptable if the proposer is developing a dual use component. The military depending on implementation, environment and usage requires compliance with:
14. See Answer 5. The requirement is 400GigBytes/sec for real-time recording. Playback has to meet real time for all data. Goal is data playback at faster and slower than the recorded rates. Transfer of data can be an offline process. |
|
| 5/19/26 | Q. | Information provided by the Technical Points of Contact:
The ONR SBIR office fully understands and appreciates the position all of you are in. It is a vast understatement to say that the last few years have been fraught with significant turmoil. When this topic was submitted (over a year ago) we estimated that the final cost of a unit out of the SBIR would be roughly 500-600 thousand dollars. With inflationary growth as it has been we can see that the final cost has grown significantly.
The ONR SBIR office will not have the leeway to just dump additional dollars into this nor does ONR have a potential near term fix for this problem set. Yet it is undeniable that the need still exists for the DoW and specifically the navy (I would assume the same holds true for the commercial world as well). What the ONR SBIR can say is that as with all RFI's the request is for the Objective outcome, and it then falls on the shoulders of the responders to outline what the thresholds can realistically be achieved, and then it is up to the Naval graders to decide what are allowable tradeoffs between performance, cost and schedule. Unfortunately, those last two are significantly more unstable than in previous topic submissions. ONR SBIR recommends that the performers propose a scalable architecture that shows how to meet ALL of the requirements but at the end of Phase II we will demonstrate with a subset that can fit within the budget of the SBIR. Areas where the Navy will not relax are the throughput requirements, Cyber security requirements and the physical footprint. Areas where the Navy will relax on is the delivery of > = 8 PetaBytes of physical storage BUT the proposals MUST show how their defined proposal can meet ALL of the cited requirements. The ONR SBIR would like to finish this up with an assurance that we understand what the economy and the nation are going through and we support the proposers in efforts to be successful. |
| A. | The ONR SBIR office fully understands and appreciates the position all of you are in. It is a vast understatement to say that the last few years have been fraught with significant turmoil. When this topic was submitted (over a year ago) we estimated that the final cost of a unit out of the SBIR would be roughly 500-600 thousand dollars. With inflationary growth as it has been we can see that the final cost has grown significantly.
The ONR SBIR office will not have the leeway to just dump additional dollars into this nor does ONR have a potential near term fix for this problem set. Yet it is undeniable that the need still exists for the DoW and specifically the navy (I would assume the same holds true for the commercial world as well). What the ONR SBIR can say is that as with all RFI's the request is for the Objective outcome, and it then falls on the shoulders of the responders to outline what the thresholds can realistically be achieved, and then it is up to the Naval graders to decide what are allowable tradeoffs between performance, cost and schedule. Unfortunately, those last two are significantly more unstable than in previous topic submissions. ONR SBIR recommends that the performers propose a scalable architecture that shows how to meet ALL of the requirements but at the end of Phase II we will demonstrate with a subset that can fit within the budget of the SBIR. Areas where the Navy will not relax are the throughput requirements, Cyber security requirements and the physical footprint. Areas where the Navy will relax on is the delivery of > = 8 PetaBytes of physical storage BUT the proposals MUST show how their defined proposal can meet ALL of the cited requirements. The ONR SBIR would like to finish this up with an assurance that we understand what the economy and the nation are going through and we support the proposers in efforts to be successful. |
|
| 04/21/2026 | Q. | The topic mentions 400 GB/sec data transfer rates. Can you please clarify if the intent is 400 Gigabits / sec or 400 Gigabytes / sec? |
| A. | The requirement is 400GigBytes/sec. |
** 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.
|