TEMPEST Call 03 - ODA2 TO2 SOO Amendment 1.pdf

STATEMENT OF OBJECTIVES (SOO)

FOR

Open Digital Automated Architecture (ODA2)

17 Nov 2020

1.0 OBJECTIVE

The objective of this effort is to develop, demonstrate, and prototype a digital architecture that combines digital engineering, software factories, and current AFRL advanced avionics architecture technologies (to advance warfighting capability for current and future Air Force weapon systems.

2.0 SCOPE

The scope of ODA2 is to use an approach to first identify and prioritize government and commercial data management best practices. It is important to work across the enterprise and understand the current state of digital tools and data capabilities. There is a need to understand the current approaches (best practices), desired future state, identify gaps that exist between the current and future state, and determine what approaches are required to reduce/eliminate these gaps (or risks) across the enterprise. The focus areas of this effort are:

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; 5)

Integration with software factories; and 6) Enterprise digital engineering.

3.0 BACKGROUND

Across the Air Force (and DoD) there are ongoing efforts to leverage DevSecOps (Development, Security, and

Operations), Digital Engineering, and Open Architectures to quickly field advanced capabilities. This effort is designed to bring the pockets of best practices forward, identify gaps, and conduct risk reduction in order to form a digital environment at the enterprise level. This digital environment would be used to show how embedded physical systems can be integrated, with the goal being development, integration, test, and flight environment commonality. This environment will then be used to look at ways to reduce certification time

(airworthiness) for pre‐programs of record, as well as programs of record. The effort would start establishing the infrastructure and initial tools to accelerate this new way of doing business. This effort should align with the

AFMC Digital Campaign and the AFLCMC Government Avionics Reference Architecture (GARA) efforts across the

Air Force, and efforts at the Air Force Test Center and across the enterprise. This effort would fuse several

AFRL/RY technologies, such as multi‐function RF apertures, alternative position, navigation, and timing (Alt‐PNT) and Software‐Defined Receivers (SDR), open architecture standards such as Open Mission Systems, and advanced avionics architectures such as PlatformNxt, exercise digital engineering and agile software development technologies (e.g., containerization) in the context of an existing AFLCMC program (e.g., R‐EGI, SDUE, F‐16, classified), as well as integrate with AFLCMC/EN‐EZ initiatives (GARA, Digital Engineering, etc.).

4.0 TASKS/TECHNICAL REQUIREMENTS

4.1 Open Digital Architecture (ODA)

4.1.1 The contractor will conduct systems engineering task to design, develop, and prototype a reference implementation for integrated capabilities for Continuous Integration/Continuous Deployment (CI/CD), digital engineering, and test using AF virtual platforms such the Air Force CloudOne platform or similar technologies to create a virtual environment for advanced weapon system development. The reference implementation will include a Digital Development Environment (D2E), a Digitally Integrated Collaboration Environment (DICE), and a Digitally Integrated Flight Environment (DIFE).

4.1.2 The contractor will standup a Digital Development Environment (D2E) to support continuous development, modeling, and simulation, integration and test. At a minimum, the D2E will include representative modeling and simulation tools including Model‐Based System Engineering (MBSE), advanced software and system analysis tools approaches, and other capabilities to enable integration, testing, and demonstration.

4.1.2.1 The contractor will establish a CI/CD pipeline to support development activities and long‐term sustainment.

4.1.2.2 The contractor will incorporate continuous integration/continuous deployment concepts (i.e., CI/CD pipeline) for development, integration, and deployment of a system architecture in accordance with DoD initiatives. Such concepts include, but are not limited to software factory processes with specialized embedded hardware to demonstrate automated integration, deployment, and testing within a pipeline.

4.1.2.3 The contractor will establishing an automated pipeline for representative MBSE tools for demonstration as well as instantiating tools within a cloud environment for experimentation. This may include integration with software factory tools or development of new tools/capabilities.

4.1.2.4 The contractor will link data sets to requirements and test cases for the automation and execution of model evaluation and testing.

4.1.2.5 The contractor will demonstrate integrated MBSE tools from other tasks, including repositories, ontologies, etc.

4.1.2.6 The contractor will generate recommendations for improved sharing of MBSE information across the enterprise, such as Advanced Battle Management System ABMS, and the software factories

4.1.2.7 The contractor will identify requirements for tools to enhance development, prototyping, airworthiness approval, and sustainment. The contractor will develop new tools, upgrade existing tools that may apply, and integrate these tools to realize an integrated tool environment to support ODA2 architecture development and adoption. Tools under consideration include, but are not limited, automated compliance verification, platform architecture tools, data collection tools, metric identification, machine learning, integrity/validation, artificial intelligence, digital engineering tools, cyber assessment tools, software factories, and others.

4.1.2.8 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.1.2.9 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.1.3 The contractor will establish a multi‐site Digitally Integrated Collaboration Environment (DICE) to enable technology incubation with a focus on government‐owned baselines and embedded capabilities. The DICE is intended to represent a next‐generation architecture which leverages open architecture standards to the fullest extent possible.

4.1.3.1 The contractor will ensure the DICE will utilize the D2E tools and processes to instantiate a reference architecture.

4.1.3.2 The contractor will ensure the DICE supports Open Mission Systems (OMS) Tier 3 compliance.

4.1.3.3 The contractor will design and implement capability to deploy software (firmware, containers, etc.) from the D2E to the DICE. In this case the DICE would be a deployment endpoint.

4.1.3.4 The contractor will make use of open standards when establishing the DICE. Open standards that are of interest include, but are not limited to, Open Mission Systems (OMS), Unified Command and Control Interface

(UCI), Common Open Architecture Radar Processing Specification (COARPs), and the Open Communication

Systems (OCS) standards.

4.1.3.5 The contractor will use leading‐edge agile software processes such as containerization, Kubernetes, Unikernel, etc. This list is not inclusive.

4.1.3.6 The contractor will demonstrate the ability of models to be validated in CI/CD pipeline and throughout the lifecycle.

4.1.3.7 The contractor will demonstrate model validation techniques against physical systems (i.e., put the twin in Digital Twin). This includes methods and concepts for hardware, firmware, and software.

4.1.3.8 The contractor will work with the government to establish the DICE at multiple locations (WPAFB, Tinker

AFB, etc.).

4.1.3.9 The contractor will work to connect the DICE sites to the D2E for an integrated approach.

4.1.3.10 The contractor will design and implement a mission package of representative software to demonstrate a platform, as well as documentation on how to swap the representative software for actual weapon system hardware.

4.1.3.11 The contractor will design and implement a mission scenario to perform a ground based test of the DICE

(which may include demonstration of the integrated D2E/DICE capabilities).

4.1.3.12 The contractor will design and prototype a software development kit (SDK) and/or platform development kit (PDK) to support integration with DICE.

4.1.4 The contractor will develop a Digitally Integrated Flight Environment (DIFE) to facilitate demonstration of continuous airworthiness of mission capability.

4.1.4.1 The contractor will ensure the DIFE will utilize the D2E tools and processes to instantiate a reference architecture.

4.1.4.2 The contractor will ensure the DIFE supports Open Mission Systems (OMS) Tier 3 compliance.

4.1.4.3 The contractor will ensure the DIFE utilizes the same embedded hardware in the DICE.

4.1.4.4 The contractor will connect multiple DICEs to a DIFE in flight to share data.

4.1.4.5 The contractor will design and execute advanced capability demonstrations on a fielded system (could be direct integration or Pod type concept).

4.1.4.6 The contractor will design and prototype a software development kit (SDK) and/or platform development kit (PDK) to support integration with DIFE. This should leverage to the greatest extent possible the SDK/PDK from the DICE.

4.1.4.7 The contractor will use leading edge agile software and hardware processes such as containerization, Kubernetes, Unikernel, advanced networks, data transfers, automation, validation, testing, etc. This list is not inclusive.

4.1.4.8 The contractor will demonstrate model validation techniques against the physical systems in the DIFE using the data produced (created manual or automated in the D2E) to demonstrate integrated D2E/DICE/DIFE capabilities.

4.1.4.9 The contractor will work to connect the DIFE to the D2E and DICE(s) for an integrated approach.

4.1.4.10 The contractor will design and implement a mission package of representative software to demonstrate a platform, as well as documentation on how to exchange the representative software (hardware models, virtualized operational flight programs, simulators, emulators, etc.) for actual weapon system hardware, i.e.

hardware‐in‐the‐loop (HIL) testing.

4.1.4.11 The contractor will design and implement a mission scenario to perform a ground based test of the

DIFE, which may include demonstration of the integrated D2E/DICE/DIFE capabilities.

4.1.5 The contractor will demonstrate how the ODA2 reduces testing time/cost, integration costs, and rapid upgrades.

4.1.6 The contractor will ensure commonality between the D2E (development environment), DICE (integration environment), and DIFE (flight/test environment).

4.2 Alignment with Enterprise Digital Activities

4.2.1 The contractor will incorporate concepts and approaches that leverage the AF’s Government Avionics

Reference Architecture to the greatest extent possible.

4.2.2 The contractor will incorporate concepts and approaches that leverage the AFMC’s Digital Campaign initiative to the greatest extent possible.

4.2.3 The contractor will show how the AF DevStar methodology would work with the proposed integrated ODA2.

4.2.4 The contractor will leverage existing work with cloud infrastructure within the DoD (i.e., CloudOne).

4.2.5 The contractor will identify applicable OA standards and investigate their applicability to enable rapid development, integration, and deployment of capability within the ODA2.

4.2.6 The contractor will analyze, develop, and present recommendations for incorporation of other digital activities across the government or commercial solution spaces.

4.3 Collaborative Integration and Experimentation

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

4.3.2 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.3.3 Relevant Mission Scenario. The contractor will establish and maintain a scenario and demonstration to illustrate the resultant benefits of these capabilities and tasks.

4.3.4 Third‐party Integration. The contractor will organize and participate in third‐party software/subsystem integration with the established test beds within AFRL/RYWA, as needed, to demonstrate the relevant open architecture concepts.

4.3.5 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.3.6 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.3.7 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.3.8 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.3.9 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.3.10 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.3.11 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.3.12 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.3.13 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.4 Associate Contractor Agreements

4.4.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 Open Digital Automated Architecture program, which shall ensure the greatest degree of cooperation for the development of the program to meet the terms of the contract.

4.4.2 Provide a copy of such agreement to the Contracting Officer for review before execution of the document by the cooperating contractors.

4.4.3 ACAs will include the following general information:

Identify the associate contractors and their relationships.

Identify the program involved and the relevant Government contracts of the associate contractors

Describe the associate contractor interfaces by general subject matter

Specify the categories of information to be exchanged or support to be provided

Include the expiration date (or event) of the ACA.

Identify potential conflicts between relevant Government contracts and the ACA; include agreements on protection of proprietary data and restrictions on employees.

4.4.4 The Contractor is not relieved of any contract requirements or entitled to any adjustments to the contract terms because of a failure to resolve a disagreement with an associate contractor

4.4.5 Liability for the improper disclosure of any proprietary data contained in or referenced by any agreement shall rest with the parties to the agreement, and not the Government

4.4.6 All costs associated with the agreements are included in the negotiated cost of this contract. Agreements may be amended as required by the Government during the performance of this contract.

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

Contractor Address Program/Contract Number

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 SCI

DCID 6/4 Top Secret Eligibility based on a SSBI/SBPR. 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 in future TOs.

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 Joint Air Force‐Army‐

Navy (JAFAN) 6/0 (Revision 1); DoD Directive 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); JAFAN 6/3 Implementation Guide, Version 1 (Sep 2006); 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).

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; PlatformNxt (PNxt) Program

Protection Plan (PPP), AFRL/RY, dated 10 May 2018.

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.