DON26BZ05-NV077 TITLE: Multi-Core Parallel Processing for Sensor Fusion Architecture
OUSW (R&E) CRITICAL TECHNOLOGY AREA(S): Quantum and Battlefield Information Dominance (Q-BID)
COMPONENT TECHNOLOGY PRIORITY AREA(S): Advanced Computing and Software
PROJECTED CMMC LEVEL REQUIREMENT: Level 2 (Self)
OBJECTIVE: Investigate and develop an efficient architectural structure/design to optimize sensor fusion algorithms within multi-core processors using parallel processing.
DESCRIPTION: The enhancement of target tracking, situational awareness, and decision-making in manned and autonomous systems is accomplished by fusing data from multiple sensors (homogeneous and heterogeneous). There are many complex issues within the implementation of sensor fusion, including, but not limited to, process latency, overprocessing of redundant data, and the inherent serial nature of current fusion architecture. To alleviate these issues, a prioritization ranking system is implemented to process higher valued tracks/data while dropping others. This forces a trade-off that risks track loss, leading to incomplete tracks and reduced situational awareness for operators in high-workload environment.
The objective is to develop a modular, platform-agnostic sensor fusion architecture that utilizes multi-core parallel processing to optimize data throughput and minimize latency. The system must support the parallel execution of both whole-task and sub-task fusion algorithms across multiple processing cores to maximize hardware utilization. The proposed architecture must demonstrate a significant reduction in process latency without the loss of fused track data or correlation accuracy.
Key requirements include:
• Parallelization: Ability to decompose fusion tasks into sub-tasks (spatial-alignment, temporal correlation, and attribute fusion) for concurrent execution.
• Track Integrity: Elimination of track loss currently caused by serial processing bottlenecks or aggressive data-prioritization filters.
• Latency: Real-time processing capability to support operator’s decision-making in dynamic, complex environments.
• Platform Integration: Size, Weight, and Power (SWaP) for the processing unit should be compatible with 5th-generation or later platforms (typically 0.5 to 1.0 cubic feet and 28V DC power).
• Scalability: Design accommodates increasing number of data sources, including, but not limited to:
o AESA Radar
o Distributed Aperture Systems (DAS)
o Electro-Optical Targeting Systems (EOTS)
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 and/or subcontractor 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 NAVAIR 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: Focus on the architectural definition and high-fidelity modeling of a multi-core parallel processing sensor fusion engine. The approach consists of three primary tasks:
• Architecture Design: Define a scalable fusion framework that decomposes the serial bottlenecks into parallelizable sub-tasks. This design will specifically address the integration of data streams within the specified SWaP constraints of a tactical processing unit.
• Modeling and Simulation (M&S): Develop a discrete-event simulation environment to provide an initial assessment of throughput, latency, and track correlation accuracy. The simulated environment will assess and compare the proposed parallel architecture against current serial benchmarks to quantify performance gains.
• Feasibility Validation: Establish the mapping of fusion sub-tasks to physical CPU/GPU/FPGA cores compatible with strict SWaP constraints of 5th generation tactical aircraft. The Phase I Option, if exercised, will culminate in a Preliminary Design Document (PDD). This document will detail the finalized architectural constraints, interface control definitions, and a hardware-software roadmap required to transition the design into a functional prototype in Phase II.
The Phase I effort will include prototype plans to be developed under Phase II.
PHASE II: Develop, integrate, and demonstrate a full-scale prototype of Parallel Multi-Core Sensor Fusion architecture. Building on Phase I architectural design and simulation results, the software-defined fusion algorithms will be transitioned into a tactical-grade processing unit. The primary focus of this effort is the real-time execution of fused track correlation across multiple sensors (both heterogeneous and homogeneous) data streams without the latency overhead inherent in legacy serial processors.
Technical Milestones include:
• Hardware-in-the-Loop (HiTL) Integration: Implement the parallelized fusion engine onto a multi-core System-on-Chip (SoC) that meets the 28V DC power and 80-pound weight constraints.
• Algorithmic Optimization: Refine sub-task decomposition to ensure balanced load distribution across processing cores, targeting an approximate reduction in end-to-end track latency of 50% compared to Phase I benchmarks.
• Performance Demonstration: Conduct a demonstration using sensor data to validate track consistency and correlation accuracy under dynamic, complex scenarios.
The final Phase II deliverable will be a Technology Readiness Level (TRL) 6 prototype, including a comprehensive Test and Evaluation (T&E) report and a transition plan for integration for Program Offices and manned/unmanned platforms.
Work in Phase II may become classified. Please see note in Description section.
PHASE III DUAL USE APPLICATIONS: Integrate the Phase II developed processing unit within a HiTL simulation, verify the performance of the complete system, and transition to an aircraft platform. Examples of potential dual use applications include search and rescue, home/private security, autonomous driving/robotics, and smart grid/energy management.
REFERENCES:
KEYWORDS: Parallel Processing; Sensor Fusion; Algorithmic Optimization; Target Tracking; Sensor Networks; Multi-Core Processors; Situational Awareness; Sensor Processing
| 9/2/26 | Q. | 1. The topic requires the contractor to be able to acquire and maintain a secret-level facility clearance. Is a current facility clearance expected of the offeror at award, or is an uncleared small business with a credible sponsorship path a viable offeror on this topic?
2. Phase I is architecture, modeling and simulation, and a mapping of fusion sub-tasks to physical cores. How is demonstrated tactical-aircraft processing experience weighed against the quality of the architecture definition and the simulation work itself? 3. Is there a serial baseline implementation or benchmark a proposal should compare against, or is establishing the baseline part of Phase I? 4. The topic names spatial alignment, temporal correlation and attribute fusion as sub-tasks. Is that decomposition prescriptive, or an example? 5. Track integrity is the stated hard requirement. What would count as proof that no fused track data is lost, in a Phase I simulation rather than on hardware? |
| A. | 1. A Secret-level Facility Clearance (FCL) is not required at Phase I award. Uncleared small businesses with a credible sponsorship path are viable offerors. FCL sponsorship and processing will be initiated during Phase I if required for Phase II transition.
2. Proposals are evaluated holistically based on the stated Phase I criteria. While tactical-aircraft processing experience demonstrates feasibility and domain maturity, strong technical merits—specifically the rigor of the proposed architecture definition, modeling, and simulation approach—remain the primary basis for Phase I technical evaluation. 3. Establishing the serial baseline and relevant performance benchmarks is part of the Phase I scope of work. No government-furnished baseline implementation is mandated prior to award. 4. The listed sub-tasks (spatial alignment, temporal correlation, and attribute fusion) are illustrative examples, not a prescriptive decomposition. Offerors may propose alternative or extended sub-task architectures suited to their technical approach. 5. In Phase I simulation, proof of track integrity can be demonstrated via deterministic tracking metrics, including: zero unhandled track drops/stalls under peak synthetic load, formal packet/message delivery accounting across simulated cores, data latency and throughput bounds, and association accuracy. |
|
| 8/25/26 | Q. | Is there a minimum number of data sources to be supported for phase I? |
| A. | Recommendation of 2-3 sensors. | |
| 8/25/26 | Q. | Has the Government begun this work or this new? |
| A. | No, the government has not begun work on this topic. | |
| 8/25/26 | Q. | Are there acceptable latency standards? |
| A. | No set minimum latency standard. | |
| 7/1/26 | Q. | When whole-task and sub-task sensor-fusion functions execute concurrently across multiple processing resources, does the Government require deterministic fused track-state results, or is asynchronous track-state reconciliation acceptable provided no fused track data or correlation accuracy is lost? |
| A. | Asynchronous reconciliation is acceptable, provided little to no fused track data/correlation is lost. | |
| 8/24/26 | Q. | 1. Phase I test scenario -
May the performer use a representative synthetic sensor-fusion scenario for Phase I, or does the Government prefer a specific scenario or workload?
2. Required fusion functions - Are target correlation and position fusion sufficient for the Phase I demonstration, or does the Government expect additional fusion functions? 3. Serial baseline -- May the performer use a representative single-threaded serial baseline with the same fusion logic as the proposed parallel architecture, or does the Government prefer a different baseline? 4. Phase I success criteria -- May Phase I success be measured by comparing the parallel architecture with the serial baseline for latency, throughput, track loss, and correlation accuracy, or does the Government have specific targets for these measures? 5. Phase I processing hardware -- May Phase I feasibility testing be performed on a desktop computer, with the results used to select and map the design to a Phase II System-on-Chip, or does the Government expect Phase I testing on representative embedded hardware? 6. Phase II processor -- May the performer select an off-the-shelf CPU or CPU/GPU System-on-Chip for Phase II based on Phase I results and the required performance and size, weight, and power limits, or does the Government prefer a specific processor or platform? 7. Phase II test support - May Phase II testing begin with representative simulated or recorded sensor streams and commercially available interface hardware, or does the Government expect specific sensor data, interfaces, or test resources to be used? |
| A. | 1. The performer can develop a representative sensor fusion scenario, provided it models a multimodal scenario (ex. Radar + EO/IR), able to track multiple targets.
2. Yes, target position and data association/correlation is sufficient. Phase I is proof of concept 3. Yes, performers can use a representative single-threaded baseline with the same fusion logic. 4. Yes, success metric of Phase I will be measured by the latency, throughput, track loss, and correlation accuracy between the single-threaded baseline and the parallel-processing solution 5. Yes, performers can model the SoC on a desktop computer. 6. Yes, performers can select off-the-shelf CPU/GPU/FPGA, etc. 7. Currently looking at options for hardware-in-the-loop simulation testing. |
** TOPIC NOTICE ** |
The Navy Topic above is an "unofficial" copy from the Navy Topics in the DoW FY-26 Release 5 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 5 SBIR Topics pre-release on August 5, 2026 which opens to receive proposals on August 26, 2026, and closes September 23, 2026 (12:00pm ET). Direct Contact with Topic Authors: During the pre-release period (August 5, through August 25, 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 August 26, 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 September 9, 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.
|