DON26BX05-NP004 TITLE: NAVWAR Open Topic for Unified Assured Positioning, Navigation, and Timing Operational Awareness and Decision Support
OUSW (R&E) CRITICAL TECHNOLOGY AREA(S): Applied Artificial Intelligence (AAI)
COMPONENT TECHNOLOGY PRIORITY AREA(S): Human-Machine Interfaces;Integrated Network Systems-of-Systems;Integrated Sensing and Cyber
PROJECTED CMMC LEVEL REQUIREMENT: Level 2 (Self)
OBJECTIVE: Develop and/or adapt innovative software-enabled capabilities that improve operator understanding of Assured Positioning, Navigation, and Timing (APNT) status, confidence, threats, and recovery options across diverse positioning, navigation, timing, and situational awareness systems and providers.
DESCRIPTION: The United States Navy relies on accurate positioning, navigation, and timing information to support maritime operations, distributed forces, mission planning, and operational decision-making. As the Navy continues to field a growing number of APNT capabilities and related situational awareness systems, operators are increasingly required to interact with multiple interfaces and data sources to understand system health, confidence levels, operational risks, and available response options. This fragmented environment increases cognitive workload, complicates training, and slows decision-making.
The Navy’s GPS-Based Positioning, Navigation, and Timing Service (GPNTS) program continues to enhance APNT resilience through the development and integration of a diverse set of technologies and systems. Examples of these data-types include the opensource All-Source Positioning and Navigation (ASPN) and PNT operating system (pntOS). The Navy seeks innovative approaches capable of ingesting, integrating, processing, and presenting information through GPNTS, to include alternate PNT sources, and related situational awareness systems through a unified operational experience. Of particular interest are solutions that provide operators with rapid understanding of APNT system status, confidence levels, threats, degradations, operational impacts, and recommended courses of action. A common operating picture, "single pane of glass," decision-support environment, or similar approach may be employed to achieve these objectives. The solutions are to transform fragmented operational data into actionable decision advantage and improve the ability of operators to rapidly sense, understand, and act in contested environments.
This topic does not seek development of new Positioning, Navigation, and Timing (PNT) or APNT sensing technologies, navigation algorithms, timing sources, or hardware systems. Instead, the Department seeks expertise in software architecture, data integration, information management, user experience (UX), human-machine interface (HMI) design, analytics, visualization, and decision-support technologies that improve operator effectiveness. Industry best practices in modern software architecture standards, such as containerization for on-prem isolated runtimes will enable the rapid and secure deployment of this capability while minimizing cybersecurity risks from cross-application dependencies.
Commercial industries such as autonomous transportation, cloud operations, telecommunications, logistics, and industrial automation face similar challenges in integrating information from multiple distributed systems to support rapid operational decision-making. Mature commercial technologies that have demonstrated success in aggregating, correlating, visualizing, and presenting actionable insights from disparate data sources may also be suggested. These may include industrial monitoring systems, transportation management systems, enterprise operations centers, autonomous system operations, telecommunications network management, logistics management platforms, and other environments requiring real-time awareness across disaggregated systems. Solutions do not need to be purpose-built for APNT applications if they can be adapted to address the operational objectives of this topic.
Primary technology areas of interest include, but are not limited to:
• Data integration and orchestration platforms
• Human-machine interface (HMI) design
• User experience (UX) design
• Common operating picture technologies
• Operational data visualization
• Decision-support systems
• Workflow automation
• Human-centered design methodologies
• Data analytics and correlation platforms
• AI-enabled operator assistance
• Containerized software architectures
• Mission management software
• Digital engineering environments
Solutions outside these areas that address the stated objective may also be submitted.
PHASE I: The DON is planning to issue multiple Phase I awards for this topic but reserves the right to issue no awards.
Establish feasibility of the conceptual technology or approach through relevant operational use cases, anticipated integration approach, expected improvements to operator effectiveness, and the path toward implementation within Navy operational environments.
Document the results of Phase I in a Final Report. Prepare a Phase II plan.
Phase I Base Deliverables
• Kick-Off Briefing
• Progress Report
• Final Report
• Initial Phase II Proposal
PHASE II: All Phase I awardees may submit an Initial Phase II proposal for evaluation and selection.
Develop a working prototype that demonstrates measurable improvements in operator situational awareness, information accessibility, decision-making effectiveness, workflow efficiency, confidence assessment, or overall operator effectiveness. Mature, integrate, demonstrate, and validate the proposed capability within a representative operational environment.
(Note: Prototype demonstrations may include integration with representative GPNTS, APNT, situational awareness, or related operational data sources.)
Prepare a final report that includes a transition strategy, deployment considerations, sustainment approach, and commercialization plan.
PHASE III DUAL USE APPLICATIONS: Support transition of the developed capability to Fleet operators and associated Programs of Record.
Commercial organizations increasingly require the ability to integrate, organize, visualize, and act upon information from numerous distributed systems. Technologies developed under this topic may have broad applicability in autonomous transportation systems, commercial shipping and logistics, aviation operations, industrial automation, telecommunications network operations, smart infrastructure management, cloud and data center operations, critical infrastructure monitoring, public safety, and enterprise operations centers.
REFERENCES:
1. U.S. Government Accountability Office. "Defense Navigation Capabilities: DOD is Developing Positioning, Navigation, and Timing Technologies to Complement GPS." GAO-21-320SP; Washington, DC, 2021. https://www.gao.gov/assets/720/714196.pdf
2. Department of the Navy. "Positioning, Navigation, and Timing (PNT); OPNAVINST 9420.1." Office of the Chief of Naval Operations: Washington, DC, 2019. https://www.secnav.navy.mil/doni/Directives/09000%20General%20Ship%20Design%20and%20Support/09-400%20Command%20and%20Surveillance%20Systems%20Support/9420.1C.pdf
3. Integrated Solutions for Systems (IS4S) Team. "ASPN and ntOS: An Open-Source Ecosystem for Building Navigation Systems." Proceedings of the International Technical Meeting of the Institute of Navigation: ION GNSS+, Denver, CO, pp 1121-1132, 2023. https://www.ion.org/publications/abstract.cfm?articleID=17172
4. U.S, Department of Defense. "Summary of the Joint All-Domain Command and Control Strategy." U.S. Department of Defense, Mar. 2022, media.defense.gov/2022/Mar/17/2002958406/-1/-1/1/SUMMARY-OF-THE-JOINT-ALL-DOMAIN-COMMAND-AND-CONTROL-STRATEGY.pdf.
KEYWORDS: Assured Positioning, Navigation, and Timing; APNT; GPS-Based Positioning, Navigation, and Timing Service (GPNTS); Alternate PNT; Common Operating Picture; Human-Machine Interface (HMI); User Experience (UX); Data Integration; Data Visualization; Decision Support; Operational Workflows; Information Architecture; Data Analytics; Situational Awareness; Mission Management; Software Architecture
| 9/7/26 | Q. | For DON26BX05-NP004, when must an offeror satisfy the projected CMMC Level 2 (Self) requirement: at proposal submission, before award, or before receiving or handling Phase I CUI? |
| A. | Must be CMMC Level 2 (Self) at time of award. | |
| 9/7/26 | Q. | Does the Government anticipate facilitating access to Fleet operators or providing operator personas, concept of operations (CONOPS), or mission context documentation for user experience and human-machine interface design during Phase I? Or should offerors plan to propose and work with surrogate users representative of GPNTS operator roles? |
| A. | The Government will not be facilitating access to fleet operators or personnel. Phase 1 performers can use surrogate data and adhere to best practices in Human Machine teaming | |
| 9/7/26 | Q. | The topic lists a projected CMMC Level 2 (Self-Assessment) requirement. Must offerors demonstrate full compliance with NIST SP 800-171 (as assessed by an acceptable SPRS score) at the time of proposal submission or at time of award, or is a current SPRS self-assessment score with an approved Plan of Action and Milestones acceptable at time of award? Additionally, is there a minimum acceptable SPRS score required for proposal eligibility or award? |
| A. | CMMC Level 2 (Self assesment) must be complete at time of award. | |
| 9/1/26 | Q. | Prior answers confirm Phase I may be performed entirely with representative unclassified, simulated, or synthetic data. Looking ahead: does the Government anticipate that Phase II performance on this topic will require a facility clearance or personnel security clearances, or is Phase II also expected to be performable at the unclassified level with GPNTS ICDs provided as Government-furnished information? |
| A. | No, a facility clearance is not expected for a Phase II | |
| 9/1/26 | Q. | Does the Government expect Phase I operator evaluation activities on this topic (task-based usability measurement with human participants) to require a human research protection program or institutional review board determination? If so, does the sponsoring command provide or sponsor such a determination, or accept an offeror-obtained determination? |
| A. | No, the Government does not expect any human research to be performed under this SBIR. | |
| 8/31/26 | Q. | Confirming: a commercially derived data-integration and decision-support platform, adapted rather than purpose-built, is squarely responsive — the topic says so, but a confirmed answer is requested |
| A. | Confirmed; use of commercially derived data integration and decision support platform is responsive. | |
| 8/28/26 | Q. | Confirm NP004 Phase I remains unclassified throughout (unlike NP003, this topic page does not carry the ITAR banner). If any APNT threat taxonomy is CUI, what unclassified stand-in should Phase I use? |
| A. | All NP004 Phase I data and activity is controlled unclassified information. There is no plan for work at higher classification. In Phase 1, vendors may use synthetic data that adheres to open-source standards (ASPN/pntOS). | |
| 8/28/26 | Q. | Is a commercial container runtime on simulated data acceptable for the Phase I demo if the architecture is designed for Platform One / Iron Bank in Phase II, or does the Government want an Iron Bank base image in the Phase I demo itself? |
| A. | Phase I can use synthetic data that conforms to open-source standards. | |
| 8/28/26 | Q. | When the Government says the ETV display should be ECDIS-like, is that a UX familiarity target for Phase I, or should the prototype implement specific ECDIS data standards (for example S-57/S-52/NMEA)? |
| A. | This is a UX familiarity target. These standards are what the ET is trained to use, providing a UX that is similar will decrease the need for additional specialized training. | |
| 8/28/26 | Q. | For Phase I synthetic data, which publicly available ASPN schema / pntOS plugin versions (ASPN.us, pntOS.com) are acceptable, and should uncleared Phase I performers assume GPNTS-unique message types will remain unavailable until Phase II? |
| A. | In Phase 1, any synthetic data that conforms to ASPN / pntOS is acceptable. Phase II performers will have access to GPNTS message types. | |
| 8/26/26 | Q. | 1. Beyond APNT and PNT-related data, what additional operational data sources should offerors consider integrating to enhance operator situational awareness and decision support (e.g., weather, mission planning data, route information, platform health/status, threat intelligence, or operational tasking data)?
2. Are there existing Navy doctrine, tactics, techniques and procedures (TTPs), operational guidance, rulesets, confidence thresholds, or recovery procedures that the Government expects offerors to leverage when generating recommendations and courses of action? 3. What operator recommendations, alerts, or recovery actions are considered most valuable to mission execution? For example, should the system prioritize APNT degradation awareness, alternative source selection, confidence assessment, threat response guidance, mission impact assessment, or other operational decision-support functions? 4. Which existing shipboard, shore-based, or mission-support systems should the proposed solution be capable of interfacing with to support a unified operational experience? |
| A. | 1. For Phase I, performers may define a representative set of rules and TTPs for their feasibility demonstration. As GFI, the Government will provide access to relevant documentation and SMEs post-award and in Phase II to ensure alignment with authoritative procedures.
2. The primary goal is to integrate these needs into a single, cohesive workflow. The most valuable capabilities will accelerate anomaly triage (distinguishing faults vs. jamming vs. spoofing) and fallback execution (e.g., selecting an alternate PNT source, confirming INS-only transition). The system must translate complex data into clear actionable recovery options. 3. The primary integration target is the shipboard Navy GPNTS program. While the solution is be a standalone interface, it should follow Navy-standard ECDIS conventions. The architecture must be designed to ingest data from disparate APNT sources via ASPN, pntOS or other message standards. There is no requirement or ability to interface with shore-based or other mission-support systems. 4. The Phase I architecture should be compute platform-independent but designed with future integration in mind (see Iron Bank image link in a previous answer). Performers should assume a flexible, API-first approach capable of handling 3 to 8 simultaneous PNT sources updating at 1 Hz to 10 Hz. Specific pntOS and ASPN version numbers, and GPNTS message details will be provided post-award. For Phase II, GPNTS ICDs will be provided post-award. |
|
| 8/26/26 | Q. | Is there room to increase the overall situational understanding of the output using independent analysis (e.g., assessing the impact of a degraded sensor)? |
| A. | For Phase I, analysis should remain limited primarily to APNT-source data, though it should be indicated on a navigation-style display. At this time, broader mission data is not planned for ingestion. A competitive solution could, however, be modular to potentially accommodate such sources in the future. | |
| 8/25/26 | Q. | 1. Level of APNT data expected in Phase I -
For the Phase I demonstration using representative simulated data, should performers primarily model processed source-level outputs such as health, integrity, confidence, availability, degradation, and threat indicators, or should the demonstration also ingest lower-level PNT measurements comparable to raw ASPN/pntOS measurement messages?
Is Phase I intended to demonstrate normalization and analytics over processed APNT status information, or interpretation of underlying PNT measurement data as well? 2. Anomaly diagnosis responsibility - The Government identified anomaly triage, including distinguishing between hardware faults, jamming, and spoofing, as a primary decision-support function. Should performers expect the underlying APNT systems to provide anomaly or threat indicators that the proposed capability correlates, or is the proposed capability expected to independently classify the anomaly from patterns across multiple PNT-source inputs? For Phase I, is a representative correlation approach using simulated source-level indicators sufficient to establish feasibility? 3. Composite confidence approach - For the Phase I feasibility demonstration, is a transparent analytical approach to composite confidence, such as configured rules, weighting, and correlation of source-provided health, integrity, and confidence indicators, acceptable? Or does the Government expect Phase I performers to develop and validate a statistical, machine-learning, or navigation-domain confidence-fusion algorithm? 4. Phase I recovery / fallback decision logic - For the representative Phase I scenario, may performers define a bounded set of representative fallback and degraded-operation decision rules, such as transition to an alternate PNT source or INS-only mode, and validate those rules with Government SMEs? Or will the Government provide authoritative procedures, TTPs, or decision logic that should govern the recommended courses of action? 5. Sub-second latency boundary - Does the sub-second end-to-end processing and rendering requirement apply to ingestion, operational-state update, anomaly/status presentation, and the initial recommended course of action? May more detailed AI-generated rationale and supporting evidence be presented immediately afterward through operator drill-down, or must the complete recommendation, confidence, rationale, and evidence package also be generated within the same sub-second interval? |
| A. | 1. The solution is expected to do both. The architecture must be capable of faithfully visualizing source-level confidence and health generated by existing systems while also utilizing analytics to derive a correlated, composite confidence assessment from underlying data patterns.
2. While it should ingest and display any source-provided indicators, a key value is its ability to correlate patterns across multiple disparate sources to derive a composite assessment. 3. While a rules-based approach is acceptable for Phase I (per previous question), performers are encouraged to propose and establish the feasibility of more advanced techniques, including statistical or machine-learning algorithms, provided they are explainable and can run in the constrained edge environment. 4. Yes. The sub-second latency requirement applies to the end-to-end chain, from data ingestion to the presentation of alerts and initial recommended courses of action, to ensure the operator's picture is synchronized with the tactical environment. 5. Good distinction - detailed rationale and evidence may be presented after the initial alert via operator drill-down. The initial alert must be sub-second, but the full evidence package does not need to be generated in that same interval. This "progressive disclosure" is critical to avoid overwhelming the operator while still ensuring trust and explainability. |
|
| 8/25/26 | Q. | 1. How many awards do you expect to make based on this topic?
2. What representative data, artifacts, models, or mission traces will be available to performers for the positioning, navigation, and timing decision support prototype? 3. What government-furnished interfaces, environments, or software versions must the prototype support in Phase I and Phase II? 4. What evaluation metrics will matter most at selection: accuracy, latency, operator workload, explainability, integration effort, or transition readiness? 5. Will performers be able to use unclassified or synthetic data for the Phase I feasibility demonstration? 6. Are there required hardware, sensor, platform, or edge-compute constraints that should be assumed before proposal submission? 7. Who is the intended transition owner or operational end user, and can proposers cite that office as the target customer? |
| A. | 1. The number of awards is subject to funding availability and the quality of the proposals received. The Government will select the most promising solutions that meet the objectives outlined in the SBIR topic.
2. Representative data sets will be provided in Phase II. Phase I can use open source developed data streams adhering to standards, to demonstrate the UX and HMI components of the solution. 3. The Phase I architecture should be compute platform-independent but designed with future integration in mind (see Iron Bank image link in a previous answer). Performers should assume a flexible, API-first approach capable of handling 3 to 8 simultaneous PNT sources updating at 1 Hz to 10 Hz. Specific pntOS and ASPN version numbers, and GPNTS message details will be provided post-award. For Phase II, GPNTS ICDs will be provided post-award. 4. The core objective is to solve the operator's cognitive workload and fragmentation challenge. Therefore, metrics directly measuring improvements in operator effectiveness are critical. Preferred quantitative measures include speed to decision during an anomaly, threat comprehension accuracy, decision accuracy (e.g., correct fallback selection), and reduced cognitive workload. 5. Yes. Phase I does not require live integration with actual Navy tactical systems or live classified data. Performers must establish feasibility using representative, unclassified, simulated, or synthetic data. 6. Yes. The capability—including all UI rendering, analytics, and any AI/ML inference—must be architected to run entirely locally and 100% air-gapped aboard individual ships. There should be no reliance on connectivity to a remote Navy data center, shore-based infrastructure, or external cloud. 7. As described in the Topic, the transition owner is the GPNTS program of record. See previous answers for ETSW details. |
|
| 8/21/26 | Q. | 1. What data will actually be available?
What GPNTS, ASPN/pntOS, alternate-PNT, and situational-awareness interfaces/data products will be available to the Phase II prototype, including confidence/integrity metadata? 2. What does NAVWAR mean by confidence and operational impact? Is the solution expected merely to visualize confidence/health generated by existing systems, or derive/correlate an independent confidence assessment and map it to mission impact? 3. What decisions should the system help the operator make? For the highest-priority contested-PNT scenarios, what specific operator decisions, recovery actions, or COAs should the capability accelerate or improve? |
| A. | 1. For Phase II, the performer will be given GPNTS ICDs as necessary regarding technical interfaces and the data types that are accepted by the system.
2. The solution is expected to do both. It must faithfully visualize the source-level confidence and health generated by existing individual systems, while also utilizing analytics to derive a correlated, composite confidence assessment. Mapping that assessment to operational and mission impacts is desired but the level of detail that will be available to this solution is still under review so defining a general approach during Phase I is sufficient. 3. The capability should primarily accelerate anomaly triage (rapidly distinguishing between a hardware fault, jamming, or spoofing) and fallback execution. Specific decisions include selecting an alternate PNT source, confirming a transition to INS-only mode, or initiating a degraded-operations workflow. |
|
| 8/20/26 | Q. | 1. Recommendation traceability and explainability
When the capability identifies a degradation, operational impact, or recommended course of action, does the Government expect the system to provide the operator with the underlying data, confidence, reasoning, or other evidence supporting that conclusion? 2. Deployment architecture for isolated operational environments The topic references containerization for on-premises isolated runtimes. Should performers plan for the capability, including any AI/ML inference and analytics, to run locally in isolated operational environments such as aboard individual ships operating in contested electromagnetic environments where reliable connectivity to a remote Navy data center may not be available? Alternatively, does the Government envision deployment primarily within a Navy-controlled on-premises data center? 3. GPNTS / ASPN / pntOS interface details The Government indicated that Phase II integration should target GPNTS and that APNT information may arrive through ASPN or pntOS message standards. Are there specific ASPN or pntOS versions, message types, interfaces, data rates, or other integration assumptions that performers should use when designing the Phase I architecture? 4. Real-time performance requirements Are there target update rates, processing latency, alerting latency, or other real-time performance requirements for ingesting APNT information and presenting changes in system status, confidence, threats, degradations, operational impacts, or recommended courses of action? 5. Phase II evaluation metrics The Phase II description calls for measurable improvements in operator situational awareness, information accessibility, decision-making effectiveness, workflow efficiency, confidence assessment, or overall operator effectiveness. Does the Government have preferred quantitative measures, baseline workflows, representative scenarios, or acceptance criteria that performers should plan to use for evaluation? 6. ECDIS-style interface integration The Government indicated that the intended ETV user is familiar with Navy-standard ECDIS interfaces and that the optimal display should reduce training requirements. Should performers plan to integrate the capability into an existing GPNTS or ECDIS user interface, develop a separate interface that follows Navy ECDIS conventions, or may performers propose either approach? 7. Historical analysis and replay Should the capability retain historical APNT state, events, confidence changes, degradations, and operator actions so users can review or replay how an operational condition developed over time, or should performers focus primarily on the current operational picture? |
| A. | 1. Yes. When the system recommends a course of action, it is expected to provide the operator with the underlying rationale, composite confidence levels, and supporting evidence. This explainability is essential for the operator to trust the system’s recommendation. While the ability to access that traceability information is important, it is also important to have only the minimum subset of information initially presented to the operator.
2. The capability—including all UI rendering, analytics, and AI/ML inference—must run entirely locally and 100% air-gapped aboard individual ships. There should be absolutely no reliance on connectivity to a remote Navy data center, shore-based infrastructure, or external cloud. 3. For Phase I architecture design, performers should assume a flexible, API-first approach capable of handling 3 to 8 simultaneous PNT sources updating at 1 Hz to 10 Hz. Specific pntOS, ASPN and GPNTS specific version numbers and schemas will be provided post-award; architectures should prioritize modularity to adapt to evolving message types. 4. The architecture should support typical source update rates of 1 Hz to 10 Hz and must maintain sub-second end-to-end processing and rendering latency. Alerts and recommended courses of action must be presented in near-real-time to ensure the operator's common operating picture is entirely synchronized with the tactical environment. 5. Preferred quantitative measures include speed to decision during an anomaly, threat comprehension accuracy, decision accuracy (correct fallback selection), and reduced cognitive workload. The baseline workflow is the current environment of monitoring multiple fragmented physical displays. A potential representative scenario is a shipboard transit (e.g., a Destroyer) through a GPS-degraded or spoofed strait. 6. Performers may propose either approach—a modular service that integrates into an existing presentation layer, or a separate standalone companion interface. In either scenario, the interface design, layout, and symbology should follow Navy standard ECDIS conventions (plus the added capabilities) to ensure positive transfer of training for the ET/ETSW. 7. While the primary focus must be delivering the current real-time operational picture to accelerate immediate decision-making, retaining historical APNT states, events, and operator actions for short-term replay or post-event review is highly desirable and supports the auditable history requirement. |
|
| 8/19/26 | Q. | Decision traceability: Is preservation of an auditable history linking the detected condition, supporting source data, recommended recovery action, operator decision, resulting action, and outcome considered within scope or desirable for the Phase I operator workflow? |
| A. | Yes. The preservation of an auditable history and decision trace is considered highly desirable. This traceability is critical for establishing operator trust in the decision-support system and provides the ability to review or explain why specific actions were taken during a contested environment scenario. | |
| 8/19/26 | Q. | Operational context: May the solution combine APNT status with broader operational context—such as mission phase, route, platform condition, dependencies, and operational priorities—to determine operational impact and present recovery options, or should Phase I analysis remain limited primarily to APNT-source data? |
| A. | Phase I analysis should remain limited primarily to APNT-source data but be indicated on a navigation display. At this time there is not data regarding larger mission phase available to ingest into the software solution. | |
| 7/1/26 | Q. | Governed action routing: May the proposed solution create and route recommended recovery actions or workflow steps for operator review and approval after identifying an APNT degradation, provided the operator retains final decision authority, or should the Phase I capability remain limited to presenting informational decision aids? |
| A. | For Phase I, the capability should remain limited to presenting informational decision aids. | |
| 8/8/26 | Q. | 1. Information presented to the operator
Are there specific categories of information that the Government considers essential to the final operator experience, such as system health, navigation confidence, detected threats, degradations, operational impacts, alternate sources, and recommended recovery actions, or should performers determine the appropriate information and organization during Phase I?
2. Existing workflow or interface Is this capability intended to improve or replace a particular existing Navy operator interface or workflow, or should performers determine during Phase I how information from multiple existing systems should be brought together into a unified workflow? 3. Measuring operator effectiveness Are there particular measures the Government expects performers to use when evaluating improvements to operator effectiveness, such as time to understand a condition, correct identification of a problem, ability to assess confidence, correct response selection, workload, or time needed to find supporting information? 4. Phase I breadth Should Phase I focus deeply on one representative Navy user group and operational use case, or does the Government expect performers to address multiple platforms, user communities, or assured positioning/navigation/timing use cases during Phase I? 5. Expected Phase I software maturity The Phase I description asks performers to establish feasibility, while Phase II calls for development and integration of a working prototype in a representative operational environment. What level of software maturity does the Government expect by the end of Phase I: design concepts and feasibility evidence, a working software demonstration using representative data, or another level of implementation? 6. Phase I integration approach For the anticipated integration approach required in Phase I, does the Government expect performers to identify specific Navy interfaces and data formats, or is a platform-independent architecture together with a plan for selecting and implementing the appropriate Navy interfaces sufficient? 7. Containerization The topic mentions containerization for isolated on-premise runtimes. Is containerized deployment expected to be implemented during Phase I, or is the intent that the proposed software architecture support secure containerized deployment during later integration phases? |
| A. | 1. The Government considers system health, navigation confidence, detected threats/degradations, operational impacts, and recommended recovery actions (decision aids) to be essential components of the final interface. However, the specific visual hierarchy, organization, and presentation of this data must be determined and validated by the performer during Phase I through human-centered design practices.
2. The goal is to unify information from multiple existing systems into a single, cohesive workflow, rather than replacing a single legacy system. Operators currently monitor several fragmented displays; performers must determine during Phase I the most effective way to aggregate and visualize these disparate streams into a unified common operating picture. 3. Yes. Performers should design evaluations around key cognitive and performance metrics as defined by state of the art activity and development in the field of human centered design. They include, but are not limited to, speed to decision, accuracy of the operator’s understanding of the degradation, decision accuracy and transfer of training. 4. For Phase I, a deep focus on a single, highly representative shipboard operational use case (e.g., a Destroyer transit through a GPS-degraded strait, focusing on the navigation situational awareness interface) is preferred over a shallow attempt to address multiple disparate platforms. Demonstrating deep feasibility on one core use case provides a stronger foundation for Phase II scaling. 5. By the end of Phase I, the Government expects comprehensive design concepts, clear feasibility evidence, and a low to medium fidelity software demonstration running on representative simulated data. 6. A platform-independent, modular software architecture paired with a robust plan for selecting and mapping to Navy interfaces (such as ASPN and pntOS) is sufficient for Phase I. The architecture should emphasize modularity (e.g., loose coupling, API-first design) so it can easily adapt to specific Navy data formats as they are defined in Phase II. 7. While actual deployment to Navy hardware will occur in Phase II, the software architecture proposed in Phase I must be designed from the ground up to support containerization (e.g., Docker, Kubernetes). Demonstrating a containerized proof-of-concept running in an isolated runtime during the Phase I final demo is highly encouraged, as it validates the feasibility of rapid, secure deployment to shipboard host environments. Reference DoD Platform One (https://p1.dso.mil/) Iron Bank for approved images. |
|
| 8/8/26 | Q. | 1. Overall solution scope The topic identifies a broad range of possible approaches, including data integration, human-machine interfaces, user-experience design, common operating pictures, decision-support systems, analytics, workflow automation, artificial intelligence assistance, and mission-management software. Is the Government intentionally open to multiple different software approaches to solving the operator-awareness problem, rather than seeking one particular type of solution? 2. Purpose-built versus adapted commercial solutions The topic states that mature commercial technologies may be adapted and that solutions do not need to be purpose-built for assured positioning, navigation, and timing applications. Are newly developed, purpose-built software solutions also fully within scope when they address the stated operator-awareness and decision-support objectives? 3. Primary operator problem What are the most important operator problems the Government wants performers to address? For example, should the primary focus be understanding system status and confidence, identifying threats and degradations, understanding operational impacts, determining recovery options, or integrating these needs into one operator workflow? 4. Intended users What Navy personnel or operator roles are the intended primary users of this capability? Are there particular watchstations, platform types, operational communities, or other user groups that Phase I performers should focus on? 5. Navy operator access during Phase I Will the Government help Phase I performers identify and connect with representative Navy operators and subject-matter experts for requirements discovery, interface feedback, and usability evaluation? 6. Operator research and usability testing The Phase I description calls for establishing feasibility through relevant operational use cases and expected improvements to operator effectiveness. Is it appropriate for Phase I performers to establish these through structured operator interviews, interface prototyping, a working software demonstration using representative simulated data, and usability evaluation with representative Navy users? 7. Phase I data and system integration Does Phase I require integration with actual Navy positioning, navigation, timing, or situational-awareness systems or data, or may performers establish feasibility using representative simulated data with integration to approved Navy systems deferred to Phase II? 8. Systems and data sources The topic references the GPS-Based Positioning, Navigation, and Timing Service, assured positioning/navigation/timing capabilities, situational-awareness systems, All-Source Positioning and Navigation, and the positioning/navigation/timing operating system. Should Phase I performers focus on any particular systems or data sources, or is identifying the appropriate integration targets part of the Phase I effort? |
| A. | 1. Yes. The Government is intentionally keeping the scope open to various innovative software approaches to take advantage of commercial advances in this field. The core objective is to solve the operator cognitive workload and fragmentation challenge. Any software-enabled capability—whether focused on advanced UX/HMI design, decision-support algorithms, data virtualization, or workflow automation—is highly responsive, provided it delivers a unified, "single pane of glass" interface that improves the operator's situational awareness and decision-making speed.
2. The topic states that mature commercial technologies may be adapted and that solutions do not need to be purpose-built for assured positioning, navigation, and timing applications. Are newly developed, purpose-built software solutions also fully within scope when they address the stated operator-awareness and decision-support objectives? 3. The primary problem is integrating all of these needs into one cohesive operator workflow. Currently, operators are overwhelmed by disparate interfaces. A highly successful solution must ingest status, confidence, and degradation data, and then translate that complex information into clear operational impacts and actionable recovery options (such as "switch to an alternate source" or "degrade to fallback mode") within a single, unified interface. 4. The intended user of the interface would be an ETV (electronics technician – navigation). The station is not on a watch floor but is manned if there are navigation issues or during transit of contested environments. The ETV would be most familiar with interacting with Navy standard ECDIS (Electronic Chart Display and Information System) type interfaces so to reduce training requirements, the optimal display would meet those requirements. 5. Yes, we will help selected performers access this type of information/interaction. 6. Yes, a Phase I approach could follow that plan. Do note that there is also innovation required on the ingestion of disparate types of APNT data sources and how to standardize those types of data for assessment, analytics and display. 7. Phase I does not require live integration with actual Navy tactical systems or live classification-level data. Performers may establish feasibility using representative, unclassified simulated or synthetic data. Full physical and software integration with live Navy hardware and systems (like GPNTS) would be deferred to the Phase II prototyping effort. 8. Phase I performers should plan for integration into the Navy GPNTS program. The data sources would include other types of messages from potentially disparate APNT sources via ASPN or pntOS message standards. |
** 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.
|