Attachment 1 SOO.pdf

STATEMENT OF OBJECTIVES (SOO)

FOR

Mission Systems Open Architecture Prototyping, Experimentation, and Demonstration

(MOAPED)

dated 13 Dec 2021

1.0 OBJECTIVE

The objective of this effort is to develop and demonstrate technology and advanced component prototype solutions to evolve and expand emerging open architecture (OA) standards and approaches for current and next-generation Air Force and DoD weapon systems. This effort seeks to identify and reduce barriers to adoption as well as demonstrate and prototype tools, technologies, and prototype solutions to enhance OA standards. As a result of the MOAPED effort, mature, robust open architecture solutions will be provided to rapidly integrate mission systems, facilitate mission system capability evolution, as well as sustained competition across the system life-cycle.

2.0 SCOPE

The scope of the MOAPED effort leverages current advances in open architecture and open system architecture (OSA) standards and approaches, spanning both software and hardware standards at the component, system, and system of system level, and used in mission and flight-critical avionics systems. The scope also encompasses agile development processes, commercial high-speed networking technologies, cybersecurity, cyber resiliency, and cyber survivability, modeling and simulation, and advanced computing paradigms such as cloud infrastructure to enable advanced mission system capability.

3.0 BACKGROUND

Over the last decade, the Department of Defense has made a concerted effort to evolve the way capabilities are fielded by transitioning to a more agile and responsive agency. This effort has revolved around open architectures, beginning with the Software Communications Architecture (SCA) and the Open Systems Joint Task Force (OSJTF) to the Air Force’s Open Mission Systems (OMS) and the Navy’s Future Airborne Capability Environment open system architecture standards. The commitment to open architectures is further supported by several recent actions: 1) Better Buying Power 3, which called out Modular Open Systems Architecture (MOSA); 2) Renewed commitment by the US Congress and DoD to identify, use, and field open architectures in critical weapons through the annual National Defense Authorization Acts (NDAA), specifically a) mandating the evaluation of public standards for development of critical technologies (NDAA 2017); 2) establishing a requirement for modular open system architectures (MOSA) in acquisition programs across the government (NDAA 2017); and c) requiring non-proprietary and open systems approaches compatible with OMS and FACE

(NDAA 2018).

The Resilient and Agile Avionics Branch (AFRL/RYWA) in the Air Force Research Laboratory, Sensors Directorate, has been the leading Air Force Science and Technology (S&T) organization in evolving and maturing of open architecture (OA) standards and their adoption within both S&T and acquisition programs. In partnership with the Open Architecture Management Office, Air Force Life Cycle Management Center (AFLCMC

OAMO) and under the auspices of the Mission System Open Architecture Science and Technology (MOAST) Program, AFRL/RYWA has developed and demonstrated OA technologies for several OA standards, most notably OMS and the Universal Command and Control Interface (UCI). In addition, further contributions were made to the advancement of the Common Open Architecture Radar Processing Specification (COARPs), as well recommendations to other standards such as the US Navy’s Advanced Command and Control (ADV-C2), the OMS/FACE System Development (OFSD) effort, and the Sensor Open System Architecture (SOSA) standards.

Commensurate with the rise of OA and MOSA approaches within the Department of Defense as well as the endorsement of OA as a “game-changer” for weapon system development, research and development across all phases of development is needed to deliver flexible weapon systems with low cost and rapid upgrade capabilities. The MOAPED effort is poised to address challenges associated with fielding a future generation of weapon systems that support rapid integration, modification, and upgrades to enable warfighter capabilities in the field.

4.0 TASKS/TECHNICAL REQUIREMENTS

4.1 Standards Identification, Management, and Improvement

4.1.1 Identification of Open Architecture Standards. The contractor will survey and monitor progress of current and emerging open architecture standards and identify opportunities for applicability to current and future mission systems.

4.1.2 Gap Analysis. The contractor will perform a gap analysis to determine deficiencies in current OA approaches such as technology shortcomings or barriers to standardization. This includes, but is not limited to, documentation, cybersecurity, software-defined platforms, next-generation capabilities, data transports, dissemination and exploitation tools, data collection tools, metric identification, machine learning, integrity/validation, and artificial intelligence.

4.1.3 Feasibility Studies. The contractor will perform feasibility studies to determine if approaches within current OA standards can be applied to current Air Force systems or if they require additional development effort to reach maturation. This includes, but is not limited to, cybersecurity/cyber resiliency/cyber survivability, software-defined platforms, high-speed data transports such as InfiniBand/Remote Direct Memory Access (RDMA), and data transfers.

4.1.4 Interoperability Studies. The contractor will perform interoperability studies to determine if different OA standards are: 1) compatible; 2) contain duplication; 3) and can be used together without conflict. As appropriate, the contractor will demonstrate the interoperability concepts within the lab including, but not limited to, experimentation with the development of mission scenarios and testbeds, or technical reports.

4.1.5 Management of Open Architecture Standards. In collaboration with the Government, the contractor will participate in the Open Architecture Management Standards (OAMS) Governance process. The contractor will continually assess current OAM training modules and training approach and make recommendations for improvements as requested. The contractor will develop an in-depth knowledge of all OAM change packages and update the training modules to reflect changes to the OAM standards. In addition, the contractor will attend OAM meetings (e.g., Chief Engineer Forums, Governance Board, Collaborative Working Group meetings, etc.) as required to develop the in-depth knowledge of all OMS/UCI change packages. In collaboration with the Government, the contractor will provide updates of the training modules.

4.1.6 Improvements to Open Architecture Standards. Research and development (R&D) tasks may result in changes to open architecture (OA) standards and documentation. As required, the contractor will prepare and submit changes to the OA standards and documentation in accordance with the change processes defined by the standards being modified. The government will approve all proposed changes, as well as the artifacts associated with the changes, prior to submission.

4.2 Open Architecture Tool Modernization, Integration, and Maturation

4.2.1 Modernization. The contractor will develop and prototype technology and tools to enhance OA research/adoption/development/sustainment. This includes but is not limited to data transports, dissemination and exploitation tools, data collection tools, metric identification, machine learning, integrity/validation, and artificial intelligence.

4.2.2 Integration. The contractor will investigate existing tools that may enhance OA research initiatives. As appropriate, the contractor will integrate the identified tools into the lab, including but not limited to mission scenarios, integration testbeds, and System Integration Labs (SIL)/Hardware Integration Labs (HIL).

4.2.3 Upgrade/Update Existing Tools. The contractor will upgrade existing tools and resources to ensure continued compliance with the OA specifications as standards mature. The contractor will also research and implement techniques that would reduce evolution time with existing tools.

4.2.4 Ensure Software Quality. The contractor will develop, extend, and modify test code as required to ensure a high level of software quality using repeatable results. This includes, but is not limited to, automated testing frameworks, code quality scanning, configuration management techniques, and test case generation.

4.2.5 Continuous Integration/Continuous Deployment. The contract will review, make recommendations, and incorporate continuous integration/continuous deployment concepts for development, integration, and deployment of open architecture systems.

4.2.6 Digital Engineering. The contractor will review, make recommendations, and incorporate concepts investigate tools that facilitate the Department of Defense’s (DoD’s) Digital Engineering (DE) initiative.

4.2.7 Documentation of Tools and Techniques. The contractor will document applicable tools and techniques.

Documentation includes, but is not limited, to user guides, development guides, UML diagrams and other AF policy required documents as appropriate.

4.2.8 Data Quality/Curation. The contractor will incorporate concepts and investigate methods for cross-cutting data sharing for modeling & simulation, advanced radio frequency (RF) simulation, and other mission system applications including: 1) Sharing – data available when needed and to who needs it; 2) Data quality/curation to increase trust in data; 3) Discovery and understanding of relevant data using proper metadata; 4) Automation of key steps; and 5) Enterprise digital engineering.

4.3 Integrated Solutions for Cybersecurity and Anti-Tamper

4.3.1 The contractor will survey and monitor progress of current and emerging open architecture standards to address cybersecurity, cyber resiliency, cyber survivability, and anti-tamper identify opportunities for applicability to current and future mission systems.

4.3.2 The contractor will investigate approaches to promote adoption of integrated automated cyber defense, anti-tamper, and information sharing within OA standards.

4.3.3 The contractor will demonstrate the technical feasibility of promising OA solutions involving integrated cybersecurity and anti-tamper approaches in a representative application. The contractor will consider implications on mission and flight-critical applications, as well as airworthiness.

4.4 Collaborative Integration, Experimentation, and Advanced Component Demonstration

4.4.1 Advanced Prototyping. The contractor will design and evolve advanced concepts through prototypes as needed to demonstrate the research under these tasks. This includes, but is not limited to, data transports, dissemination and exploitation tools, data collection tools, metric identification, machine learning, integrity/validation, automation, and artificial intelligence.

4.4.2 Relevant Mission Scenario. The contractor will establish and maintain a scenario and demonstration to illustrate the resultant benefits of these capabilities and tasks.

4.4.3 Third-Party Integration. The contractor will organize and participate in third-party software/subsystem integration with the established RYWA Open Architecture test bed, as needed, to demonstrate the relevant open architecture concepts.

4.4.4 Release Demonstration Events. The contractor will participate in or conduct demonstrations of completed capabilities and tools that include established/configured scenarios. These events may require software/hardware builds/documentation and testing prior to demonstration.

4.4.5 Compliance Verification and Assessment. The contractor will apply, leverage, or when required, develop methods to assess compliance to applicable OA standards as part of demonstration events of OA implementations. The contractor will also apply verification methods (e.g., Inspection, Demonstration, Analysis, Test) to assess OA standards compliance. Lastly, the contractor will develop metrics to evaluate OA implementations.

4.4.6 Develop and Operate Research Networks and Platforms. The contractor will develop, operate, and maintain research networks as necessary for tool prototype design, development, and evaluation.

4.4.7 Adhere to Security Standards. The contractor will ensure the networks adhere to applicable security standards and meet requirements as designed in prototype and as required by AF policy.

4.4.8 Integration of Software. The contractor will design, develop, integrate and test software for research and development on the identified research networks to ensure the networks compatibility and readiness to complete this TO.

4.4.9 Update or Improve Performance. The contractor will provide materials, replacement components, and parts in a timely manner in an effort to prevent or eliminate malfunctions, enhance or update capabilities, or improve performance requirements.

4.4.10 Ensure Quality and Accreditation of Research Networks. The contractor will perform system backups, commercial software upgrades, and prepare or update computer security certification and accreditation packages as appropriate to ensure the networks compatibility and readiness to complete this TO.

4.4.11 Configuration of Networks and Platforms. The contractor will plan, execute, and manage all tasks required to configure the research networks and platforms for evaluation of identified advanced technologies to ensure the networks compatibility and readiness to complete this TO.

4.4.12 Enhance Research Platforms. The contractor will purchase, develop in-house, or construct any additional hardware, firmware, or software required for successful completion of this TO. This includes, but is not limited to, complying with all requirements for properly processing all acquired, developed, or constructed hardware, firmware, and software.

4.4.13 Testing and Data Collection. Once configured, the contractor will execute all tests, collect and store associated data, and perform post data processing as requested.

4.4.14 Documentation of Research Networks and Platforms. The contractor will document and record network descriptions, layouts, and features as appropriate for the type of network or platform under consideration.

4.5 Associate Contract Agreements

4.5.1 The Contractor shall enter into Associate Contractor Agreements (ACA) for any portion of the contract requiring joint participation in the accomplishment of the Government’s requirement. The agreements shall include the basis for sharing information, data, technical knowledge, expertise, and/or resources essential to the integration of the Mission Systems Open Architecture Prototyping, Experimentation, and Demonstration (MOAPED) program, which shall ensure the greatest degree of cooperation for the development of the program to meet the terms of the contract.

4.5.2 The following contractors are associate contractors with whom agreements are required.

Contractor Address Program/Contract Number

TBD TBD TBD

5.0 MANAGEMENT

5.1 Program Administrative and Financial Functions. The contractor will follow program management processes to administer the program (functionally and financially) including, at a minimum, scheduling and tracking milestones and activities; managing subcontracts and Contract Data Requirements Lists (CDRLs);

reporting program technical, schedule, and cost status; planning, forecasting, and recommending funding or funding changes; and documenting technical breakthroughs or discoveries.

5.2 Management at Various Facilities. The contractor will support R&D on site (i.e., at a government facility) and off site (i.e., at the contractor’s facility), as appropriate.

5.3 Risk Management. The contractor will maintain a risk management process throughout the program identifying, analyzing, assessing, mitigating, and monitoring technical, schedule, and cost risks which will be included as part of the monthly status report.

6.0 DELIVERABLES

Data will be delivered in accordance with the CDRLs, DD Form 1423-1. The contractor will document all technical work accomplished and information gained during the performance of this acquisition. This documentation will include all pertinent observations, the nature of any problems, positive and negative results, design criteria established (where applicable), procedures followed, processes developed, lessons learned, and so forth. The contractor will document the details of all technical work to permit full understanding of the techniques and procedures used in evolving the technology or processes developed.

Separate design, engineering, or process specifications delivered during this acquisition will be cross-referenced to permit a full understanding of the total acquisition. Final software and hardware (including source code, firmware, libraries, and executables) developed on this effort will be delivered, with unlimited rights and with software in a format acceptable to both parties, at the end of the technical period of performance.

7.0 TECHNICAL REVIEWS

The contractor will hold a kickoff meeting at AFRL within 30 days after contract award. The contractor will host quarterly program management reviews and conduct ad hoc reviews as required with the government, stakeholders, and associate contractors. The contractor will involve required contractors, subcontractors, AFRL, and other research personnel as appropriate.

8.0 SECURITY

8.1 Program Security Requirements. In order for individuals to work on classified portions of this effort, the contractor will ensure that all individuals are U.S. citizens, understanding that they may be required to have Top Secret Eligibility based on a SSBI/SBPR (T5 investigation). The contractor will require that all SCI and SAP work be conducted within an accredited Special Access Program Facility (SAPF) and/or a Sensitive Compartmented Information Facility (SCIF). The government will outline specific security details and requirements The contractor will ensure that all classified efforts comply with National Industrial Security Program Operating Manual (NISPOM) and other regulations/policies that may apply to this contract, such as DoD Manual 5205.07 (Volumes 1–4); Air Force Manual (AFMAN) 16-703 V3; SAF/AAZ Memorandum “Air Force Special Access Programs Nomination Process (SAPNP)” (30 Sep 2013); Under Secretary of Defense for Intelligence (USD(I)) Memorandum, “Special Access Programs Nomination Process” (20 May 2013); DoD Security Assistance Policy Coordinating Office (SAPCO) Memorandum, “Transition to the Risk Management Framework (RMF)” (18 Dec 2013); Joint Special Access Program Implementation Guide (JSIG) (9 Oct 2013);

Intelligence Community Directives (ICDs) 704 and 705; other applicable SCI regulations and policies; other applicable Security Classification Guides (SCGs); and other applicable regulations/policies and subsequent revisions. Access to Joint Worldwide Intelligence Communications System (JWICS) is authorized for performance of SCI work, users shall be briefed NATO SECRET IAW the NISPOM, Para 10-706, prior to access).

The Contractor shall participate with the Government in the development of a Security and Technology Protection Plan (S&T) to include the identification of Critical Program Information (CPI), and shall also participate with the Government in determining countermeasures needed to safeguard the CPI throughout the acquisition process. The Contractor shall plan for and execute S&T protection in accordance with the S&T and program guidance.

8.2 Operational Security (OPSEC). General Operations Security (OPSEC) procedures, policies and awareness are required in an effort to reduce program vulnerability from successful adversary collection and exploitation of critical information. OPSEC will be applied throughout the life cycle of the contract. The Critical Information List (CIL) and the RY OPSEC Plan will be provided upon request by AFRL/RYOY Information Protection Office.

While working on the government installation, OPSEC guidance and OPSEC training will be provided by AFRL/RYOY Information Protection Office. This training will ensure contractors are familiar with RY’s CIL and RY’s OPSEC Plan as it pertains to their contract. The contractor shall apply OPSEC in their management of their current program IAW AFI 10-701 Operations Security and WPAFB Supplement to AFI-10-701.

8.3 Security Training. The contractor will participate in the U.S. Government’s (USG’s) in-house and web-based security training program under the terms of the contract. The USG will provide the contractor with access to the online system. The contractor will take specialized security training as deemed applicable by USG.

8.4 Security Duties. The contractor will be required to perform normal services under this contract between the hours of 0600-1800 excluding Federal Holidays. The contractor shall perform the following security tasks incidental to R&D efforts: End of day security; open, operate and close classified facilities; activate and deactivate alarms which requires access to alarm codes and alarm panel; facilitate access to classified information which will require combinations to locks for safes and doors during normal workhours and extended duty days. This may also include, at the discretion of the government, responsibility for performing after-hours alarm response which may require 24/7 building access in accordance with AF and DoD requirements. The government maintains the overall responsibility for all security related activities and is incumbent upon the contractor to officially communicate to the government these objectives and requirements have been appropriately completed in a timely and efficient manner.

8.5 Program Protection Plan. All DoD contractors (including subcontractors) shall supplement their current security practices by requiring any personnel involved in executing this contract where critical program information (CPI) has been identified to protect the CPI to the standards articulated in the Program Protection Plan and in accordance with DoDI 5200.39. Upon contract award, all identified DoD contractors (including subcontractors) shall acknowledge and meet the requirements stated by the Program Manager for the protection of CPI. The DoD contractor must immediately notify the U.S. Government upon the discovery of any nonconformance with CPI protection. Applicable PPPs include, but are not limited to, the following:

“Standards Management Program Protection Plan”, Open Architecture Management Office, Air Force Lifecycle Management Center (AFLCMC), Wright-Patterson AFB OH, dated 1 Jan 2019.

9.0 SAFETY

The contractor will comply with all Air Force, federal, state, and local safety and environmental regulations.

The contractor will develop and have an approved Safety Plan (AFI 91-202 AFRL Sup 1) before any experiment may be conducted outside of a laboratory environment. The contractor will comply with safety requirements contained in MIL-STD 882E, Section 4, “General Requirements,” for any deliverable system or hardware. The contractor will identify safety-critical components of those systems or hardware and software interfaces with those components. The contractor will test and verify the safety-critical hardware and software for safety acceptance.

10.0 BASE SUPPORT

AFRL/RYWA will provide the contractor with laboratory space, equipment (on a non-interference basis), and computer/network access for conducting this effort, if proposed.

8.0 SECURITY