N241-007 TITLE: Multi-Information Distribution System for Software Defined Radios
OUSD (R&E) CRITICAL TECHNOLOGY AREA(S): Advanced Computing and Software; Integrated Network Systems-of-Systems; Sustainment
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: Research, design, develop, and test (Pilot) a Development, Security, and Operations (DSO) Pipeline for a Software Defined Radio (SDR) Capability.
DESCRIPTION: This SBIR topic will focus on process and cultural innovation for PMA/PMW-101 adopting DSO in accordance with (IAW) DoD CIO Software Factory Guidance. PMA/PMW-101 is moving towards a SDR leveraging Government and Industry Partner Third-Party Applications. The intent is to create a PMA/PMW-101 Sandbox for third-party vendors to innovate, modify, improve, and expand upon the PMA/PMW-101 Software Baseline. The project will improve and provide rigor to PMA/PMW-101's engineering support structure, governance, and technical authority to include software performance, Cyber Security, regression testing, verification, and validation.
Innovation: Implement Continuous Authority to Operate (cATO) and Zero Trust (ZT) policies into PMA/PMW-101's DSO Pipeline. Define, standardize, and implement Application Program Interface (API) IAW DoD Guidance and follow Software Acquisition Pathways. Once the software reaches the end of the DSO Pipeline, the software will be Cyber Security compliant and have minimal risk to the Fleet.
Speed to the Fleet: A key aspect to DSO is pushing a low-risk, cyber secure, deployable software product to customers (i.e., aircraft, ships, etc.) for integration into their System of Systems.
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 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. Reference: National Industrial Security Program Executive Agent and Operating Manual (NISP), 32 U.S.C. § 2004.20 et seq. (1993). https://www.ecfr.gov/current/title-32/subtitle-B/chapter-XX/part-2004
PHASE I: Research and develop approaches on the adoption of DSO cATO & ZT policies, Application Programming Interface (API) DoD Guidance and Software Acquisition Pathways via the following:
1. Identify PMA/PMW-101 software capabilities to transition into DSO Environment .
2. Identify DSO Environment(s) into which to transition.
3. Identify DSO Environment Tools needed with a training path.
4. Identify the process to execute DSO to include a "Sandbox".
5. Develop a transition strategy to go from "On-Premise" to the "DSO Environment".
6. Determine the feasibility of the conceptualized approaches.
The Phase I effort will include prototype plans to be developed under Phase II.
PHASE II: Develop a prototype that is capable of the following:
1. Pilot – The identified Software Suite to transition selected capabilities into the desired DSO Environment(s) and connect/interface with other selected DSO Environments.
2. Provide PMA/PMW-101 training with regard to DSO Architecture, Engineering, Operations, Security, and Agile Project Management (i.e., Scrum, Scrum at Scale, Large Scale Scrum, etc.).
Work in Phase II may become classified. Please see note in Description paragraph.
PHASE III DUAL USE APPLICATIONS: Connect and interface PMA/PMW-101's DSO with other DoD DSO Pipelines/Software Factories in compliance with Department of Defense (DoD) Chief Information Office (CIO) Software Factory Guidance. PMA/PMW-101 will provide Program Office funding and support to solidify cATO, and ZT Policies in their DSO Pipeline. Leverage the DSO Pipeline to include the Sandbox for rapid, secure, third-party application prototype and fielding. For example, a third-party vendor would check their software into the Sandbox, verify that the software was compatible with the baseline executable, API, Interface Control Document (ICD), and Security Checks within DoD Policy facilitating risk reduction and maturation of third-party vendor software into our Product Line. This effort saves money, time, and the amount of human resources required to adopt and field innovative products leveraging the U.S. industrial base.
Commercial DSO Environments such as Amazon Web Services and others can leverage the architecture, business rules, and interfaces developed in this effort.
REFERENCES:
KEYWORDS: Development, Security and Operations; DevSecOps; DSO; Innovation; Continuous Authority to Operate; cATO; Zero Trust; ZT; Process Improvement; Agile; Overmatch Software Armory; Open System Architecture (OSA)
** TOPIC NOTICE ** |
The Navy Topic above is an "unofficial" copy from the Navy Topics in the DoD 24.1 SBIR BAA. Please see the official DoD Topic website at www.defensesbirsttr.mil/SBIR-STTR/Opportunities/#announcements for any updates. The DoD issued its Navy 24.1 SBIR Topics pre-release on November 28, 2023 which opens to receive proposals on January 3, 2024, and now closes February 21, (12:00pm ET). Direct Contact with Topic Authors: During the pre-release period (November 28, 2023 through January 2, 2024) proposing firms have an opportunity to directly contact the Technical Point of Contact (TPOC) to ask technical questions about the specific BAA topic. Once DoD begins accepting proposals on January 3, 2024 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. SITIS Q&A System: After the pre-release period, until January 24, 2023, at 12:00 PM ET, proposers may submit written questions through SITIS (SBIR/STTR Interactive Topic Information System) at www.dodsbirsttr.mil/topics-app/ by logging in and following instructions. In SITIS, the questioner and respondent remain anonymous but all questions and answers are posted for general viewing. Topics Search Engine: Visit the DoD Topic Search Tool at www.dodsbirsttr.mil/topics-app/ to find topics by keyword across all DoD Components participating in this BAA.
|
| 1/9/24 | Q. | 1. Does PMA/PMW-101 already have a DSO pipeline in which cATO and ZT policies need to be implemented?
2. Has PMA/PMW-101 considered adopting Navy DevSecOps pipelines such as OSA (Overmatch Software Armory) and Black Pearl? If so, why are they not suitable for PMA/PMW-101? 3. Related to the above question, what is unique about MIDS that requires it have its own purpose-built DSO pipeline? 4. Does the envisioned DSO pipeline require hardware (radios) for testing of the MIDS software? 5. What is the classification level of the MIDS software? |
| A. | 1. NO
2. YES, PMA-101 is interested to leveraging the right “DevSecOps” Environment at the right Multi-Level Security (MLS). 3. We DO NOT want to build (Re-invent the wheel) our own DSO Purpose-Built Pipeline, we want to leverage OSA, BP, etc. 4. YES, at the Vendors (3+ different locations) 5. Unclassified, Secret, and Other |