DON26BZ05-NV076 TITLE: Open, Layered, Yielding Modular Platform for Unified Systems
COMPONENT TECHNOLOGY PRIORITY AREA(S): Sustainment
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: Transform maritime domain awareness and operational efficiency by developing a unified, modular, and open architecture platform that integrates shipboard systems and technologies.
DESCRIPTION: The current operational portfolio encompasses a large and diverse set of systems, many of which were developed piecemeal over time. This fragmented development history poses significant challenges to both sustainment and modernization efforts. The use of multiple, disparate systems performing similar or identical functions has resulted in a complex and costly "logistics tail", extensive technical documentation, and redundant training programs. This duplication increases costs, reduces efficiency, and heightens the risk of obsolescence. Additionally, the lack of commonality between systems hinders the integration of new capabilities and technologies, as each system requires unique modifications. This slows innovation and limits the ability to leverage advancements in automation, artificial intelligence (AI), and digital engineering. Ultimately, the lack of interoperability within portfolio creates a fragmented, inefficient, and costly development and sustainment environment, negatively impacting warfighter readiness and effectiveness.
To address these challenges, PMA-213 is developing a portfolio-wide architecture, referred to as Zeus, which functions as a system of systems (SoS). Zeus will provide a modular and open digital and hardware framework capable of delivering varying levels of service and functionality based on specific mission requirements. This architecture will enable data fusion, redundancy, and seamless integration of individual apertures and below-deck infrastructure, tailored to each ship’s mission set. By adopting an open and modular design, Zeus will support future cost savings, accelerated modernization, and enhanced interoperability across the fleet. OLYMPUS is a sub-project of Zeus focusing on the below deck ship infrastructure.
OLYMPUS will enhance situational awareness, streamline decision-making, and improve fleet-wide interoperability through advanced data fusion, real-time analytics, and secure communication networks. By leveraging cutting-edge technologies such as AI, machine learning (ML), and digital engineering, OLYMPUS will ensure naval operations are resilient, adaptive, and capable of addressing emerging threats in complex and context environments.
In addition to operational benefits, OLYMPUS aims to achieve significant long-term cost savings and cost avoidance across portfolio by increasing commonality in parts, enabling quantity buys, and simplifying maintenance requirements. For example, standardizing hardware procurement to allow the purchase of twenty-five (25) computers for use across five systems, rather than five different computers for five systems. These efficiencies will impact all air-capable fleet platforms, including CVNs, L-Class ships, and DDGs, optimizing readiness and sustainment across the fleet.
The transition of OLYMPUS technology and architecture will primarily occur through routine sustainment efforts and technology refreshes within. With government ownership of the majority of data rights for the affected portfolio, the technology developed through this SBIR effort can be gradually fielded over time via Engineering Change Proposals (ECPs). This approach ensures a smooth and cost-effective transition while enabling the Navy to modernize its systems and maintain maritime superiority.
PHASE I: Assess the technical, operational, and economic feasibility of the OLYMPUS system. Key activities include:
1. Preliminary Analysis and Scope Definition:
Conduct a detailed analysis to define the scope, objectives, and requirements of the feasibility study. Evaluate existing technologies and their compatibility with the proposed modular and open architecture system.
2. High-Level System Design and Architecture:
Develop a high-level design and architecture for the OLYMPUS system, outlining its modular framework, data fusion capabilities, and integration pathways for shipboard systems.
3. Proof-of-Concept (PoC) Demonstrations:
Perform PoC demonstrations for critical components to validate initial concepts and assess their functionality in representative operational scenarios.
4. Comprehensive Risk Assessment:
Identify potential technical, operational, and integration challenges. Develop mitigation strategies to address risks associated with system development and deployment.
5. Feasibility Report:
Compile findings into a detailed feasibility report, including technical recommendations, risk mitigation strategies, and a roadmap for Phase II development. The report will provide actionable insights to guide the next phase of the effort.
The Phase I effort will include prototype plans to be developed under Phase II.
PHASE II: Develop and test a prototype of the OLYMPUS system to validate its design and performance. This includes designing and building a prototype system based on the high-level architecture established in Phase I and integrating key components such as sensors, processing units, user interfaces, and communication networks. Laboratory and field testing will be conducted to evaluate system performance, interoperability, and resilience. Based on test results and stakeholder feedback, the system design will be refined. Detailed technical documentation and training materials will be developed to support system deployment and operation. A comprehensive test report will be prepared to summarize the findings and provide recommendations for full-scale deployment.
PHASE III DUAL USE APPLICATIONS: Transition the OLYMPUS system from prototype to operational deployment. Activities will focus on final system refinement, production readiness, and integration into operational environments. The system will be deployed in coordination with transition partners to support operational evaluation and adoption. Manufacturing, installation, and configuration processes will be established to support scalable deployment. Training and technical support will be provided to ensure effective system operation and sustainment. Feedback from operational use will be incorporated to support continuous improvement. Documentation developed during Phase II will be finalized to support long-term operation, maintenance, and sustainment, and deployment outcomes will inform broader implementation and commercialization efforts.
The OLYMPUS system has strong commercial potential in private sector applications that require integrated sensing, data processing, and reliable communication capabilities to support monitoring, decision-making, and operational efficiency. Potential dual-use applications include infrastructure monitoring, industrial operations, transportation systems, and emergency response environments where real-time data integration and system resilience are critical. The system’s modular architecture supports adaptation to commercial use cases with minimal modification, enabling scalability across multiple industries. Commercial deployment opportunities exist in environments that require improved situational awareness, system reliability, and coordinated operations. Lessons learned through DoW deployment and operational testing will support commercialization by reducing technical risk and demonstrating system effectiveness in demanding operational environments.
REFERENCES:
KEYWORDS: MOSA; Systems Engineering; Ship; Common; Computing; Interfaces; Architecture
| 9/2/26 | Q. | 1. For the currently fielded AN/SPN-35C and AN/SPN-46 systems, what is the existing below-deck computing environment, including the processor/board architecture (e.g., VME), operating system, and application software language(s)? This is needed to scope the rehosting effort and select a representative environment for the POC.
2. Please confirm the intended OLYMPUS system boundary. Does OLYMPUS encompass the below-deck processing, displays, networking, and power systems associated with the listed systems, while leaving the topside apertures/antennas, RF front ends, and their existing interfaces to the below-deck equipment unchanged? If the system boundary differs by platform, please identify those differences. 3. The listed systems are safety-of-flight rated. For application software rehosted onto common compute, does the Government expect re-qualification of the rehosted function, and will the applicable software safety or airworthiness criteria be identified to the Phase I awardee? |
| A. | 1. For planning purposes, assume the AN/SPN-35C and AN/SPN-46 below-deck environments are legacy, heterogeneous (there is currently a mix of Linux and Windows within each system), real-time systems with VME-era processing, VxWorks-based components, and a software baseline containing significant C code plus additional radar-processing and display/control software. The rehosting effort involves modernization of a mixed real-time environment, not a single uniform hardware/software stack. Final note, we want to move to a Linux only (no Windows) environment.
2. Yes, that is correct. The system boundary does not encompass the topside apertures/antennas or the existing interfaces with them. That is true across all the systems. 3. Once fielded it would be a major change so it would require requalification. Yes, standards will be provided. However, they do not necessarily need to be fully implemented or vetted initially as this is focused on prototyping. The architecture certainly needs to account for it, but implementation can deviate within reason. |
|
| 9/2/26 | Q. | 1. Is there an existing modular open systems standard the platform is expected to conform to, for example FACE, SOSA or HOST, or is the architecture open in the general sense?
2. Is the unification across systems, across data, across interfaces, or all three? 3. Is there an incumbent system this is intended to replace or wrap? 4. Given the ITAR restriction, are there constraints on the citizenship or residency of the performing team beyond the standard foreign-person rule? |
| A. | 1. No, the architecture is currently open to be defined however we want. Existing standards can be used, it just requires justification to support the selection of an existing or newly developed concept.
2. The unification is primarily interfaces initially. Currently the systems do not share much data or interact with each other functionally. That being said, part of the purpose of this effort is to allow for that in the future. We do want to drive to as much commonality of parts as we can though for logistics/sustainment reasons. 3. This concept is new. The incumbents are the existing legacy systems (SPN-35, SPN-41, etc.). 4. Other than the standard export-control rule for foreign persons, we are not aware of an additional blanket citizenship or residency restriction that automatically applies to all performing team members solely because the effort is ITAR-restricted. However, any team member who is a foreign person may be limited or prohibited from participating in portions of the work involving ITAR-controlled technical data, software, hardware, or defense services unless the required U.S. Government authorization is in place. Applicants are responsible for ensuring compliance with ITAR/EAR and should review the solicitation for any agency-specific limits, including SBIR eligibility and U.S.-performance requirements. Applicants are responsible for determining and complying with all applicable export-control requirements. |
|
| 8/31/26 | Q. | 1: For the SPN-35 priority system, does “emulate” mean preserve required functions through rehosting/recoding, or run existing legacy binaries with minimal modification?
2: What SPN-35 GFI is expected to be available in Phase I—source code, binaries, interface documentation, operating environment, and test data? 3: Should Phase I primarily compare candidate MOSA/open architectures and select one, or is developing a new architecture equally preferred if existing approaches do not fit the portfolio? |
| A. | 1. “Emulating” the SPN-35 means preserving the required functions. We want to host the software in a modern containerized software environment to facilitate cyber compliance and future upgrades. One of the major desired outcomes is a common development environment which requires the software be modernized.
2. We will provide the source code, interface documentation, and any additional data as it is needed and available. 3. There is obvious advantage in selecting an existing architecture if one is found to be acceptable for our application. However, we do not want to make major compromises at the outset if there is nothing that fits well, thus necessitating the development of a new one. We do not want to reinvent the wheel unless it is necessary in which case that is the desired path. |
|
| 8/27/26 | Q. | 1: To what extent is OLYMPUS expected to host existing legacy mission-system software on common compute hardware versus providing a standardized architecture for newly developed or modified applications?
2: What existing Zeus/OLYMPUS architecture artifacts, interface standards, or technical constraints are already government-defined and will be made available to the Phase I awardee? 3: For the Phase I PoC, what representative shipboard systems, interfaces, or workload types should offerors use to demonstrate interoperability and feasibility? |
| A. | 1. OLYMPUS needs to be able to emulate the existing systems. There will be some level of work required to take the existing SW and rehost it in a modern environment. The key is to maintain current function even if that involves a bit of recoding.
2. Unfortunately, we do not have any. That is part of the challenge. There are many MOSA architectures out there. We are not partial to any of them specifically. We need to have one defined that reflects the needs of our portfolio and environment. That could be using one that already exists or a new one, the key is that it is selected based on our needs. 3. The systems we are looking to drive to the OLYMPUS architecture are the USN-3(V)1, URN-32, SPN-35, SPN-41, SPN-46, and UPX-50. The SPN-35 is the priority out of that list. Many of the systems have info in the public domain to identify interfaces. The systems are all non-cooperative and focused on their own operation. There is some minimal data passing between them, but it is limited and there is no data fusion or queueing going on. |
|
| 8/26/26 | Q. | 1. OLYMPUS architecture definition -
Can the Phase I performer fully define the technical OLYMPUS architecture, or are there existing OLYMPUS technical requirements, interfaces, or standards that the performer must use?
2. Representative system interfaces - Can Phase I use representative shipboard system interfaces, data formats, and communication methods, or are there specific existing Navy interfaces or formats that the performer must represent? 3. Phase I integration demonstration - Can Phase I demonstrate OLYMPUS using simulated shipboard systems that exchange representative data through the proposed interfaces, or must Phase I integrate with existing Navy hardware or software? 4. Data fusion and analytics - Can OLYMPUS provide the common real-time data infrastructure that separate applications use for data fusion and analytics, or must the OLYMPUS platform itself perform data fusion or analytics? 5. Phase I performance requirements - Are there required Phase I targets for data rate, latency, number of connected systems, message loss, or other performance measures, or should the performer define representative workloads and success thresholds? 6. Security and network requirements - Can Phase I use a representative wired IP network and software security approach, or are there specific Navy networking, cybersecurity, or communication standards that the Phase I proof of concept must implement? |
| A. | 1. Yes, there are no existing standards to reference.
2. The objective overall is to minimize the amount of non-common equipment between the different systems (compute, power, networking, etc.). Initially there will be limited GFI so representative is fine. 3. Yes. Simulated/Representative systems is what is expected. 4. There is no data fusion happening. The systems are all stand-alone operations. 5. The most stringent latency requirements among the systems is in the area of 12ms and the highest data frequencies are around 5 Hz. Beyond that, the systems are generally relatively old, so system performance of modern equipment will easily outpace existing performance. These systems are safety of flight rated so that also is a contributor to the overall data quality environment. 6. Yes. There is no specific standard required for the initial prototype. However, the long term plan is to network these systems together and potentially connect them with other things which would increase the cyber threat surface meaningfully. So developing the computational and network architecture with that in mind is important to minimize future threat risk |
|
| 8/19/26 | Q. | Existing architecture/interfaces Are Zeus/OLYMPUS interface standards, data models, MOSA profiles, reference architectures, or representative interface descriptions available for Phase I feasibility work? |
| A. | No, they do not exist, which is part of the challenge. There are many MOSA architectures out there. We are not partial to any of them specifically. We need to have one defined that reflects the needs of our portfolio and environment. That could be using one that already exists or a new one, the key is that it is selected based on our needs. | |
| 7/1/26 | Q. | Software-only feasibility Would a software-centric modular integration, data-fusion, situational-awareness, and decision-support architecture operating across representative or Government-furnished shipboard computing, sensors, and communications hardware satisfy the Phase I objective, or must the proposed SBIR solution itself include development of new hardware? |
| A. | Representative hardware is fine. The objective is to have an architecture that allows for hardware to easily be changed over time, so the initial prototypes would be included in that. |
** 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.
|