HR001122S0015.pdf

Broad Agency Announcement

Air Combat Evolution (ACE) Technical Area 4 Phases 2 and 3

STRATEGIC TECHNOLOGY OFFICE

HR001122S0015

February 1, 2022

TABLE OF CONTENTS

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

A. Program Overview B. Program Structure and Technical Approach C. Technical Objectives for Phase 2, Phase 3, and the Additional Aircraft Options D. Proposal Assumptions E. Program Metrics, Deliverables, and Milestones F. Major Review Descriptions and Expectations

II. Award Information A. General Award Information B. Fundamental Research

III. Eligibility Information A. Eligible Applicants B. Organizational Conflicts of Interest C. Cost Sharing/Matching

IV. Application and Submission Information A. Address to Request Application Package B. Content and Form of Application Submission

V. Application Review Information A. Evaluation Criteria B. Review of Proposals

VI. Award Administration Information A. Selection Notices and Notifications B. Administrative and National Policy Requirements C. Reporting D. Electronic Systems E. DARPA Embedded Entrepreneurship Initiative (EEI)

VII. Agency Contacts VIII. Other Information

IX. APPENDIX 1: PROPOSAL SLIDE SUMMARY

X. APPENDIX 2: VOLUME 1 COVER SHEET TEMPLATE

XI. APPENDIX 3: PROPOSAL COST SLIDE SUMMARY

XII. APPENDIX 4: SECURITY CLASSIFICATION GUIDE (SCG) REQUEST FORM

PART I: OVERVIEW INFORMATION

Federal Agency Name – Defense Advanced Research Projects Agency (DARPA), Strategic Technology Office (STO) Funding Opportunity Title – Air Combat Evolution (ACE) Technical Area 4 Phases 2 and 3 Announcement Type –Initial announcement Funding Opportunity Number – HR001122S0015 Catalog of Federal Domestic Assistance Numbers (CFDA) – Not applicable Dates o Posting Date – February 1, 2022 o Questions Due Date and Time – February 15, 2022 2:00 p.m. (Eastern Time) o Proposal Due Date and Time – March 18, 2022 2:00 p.m. (Eastern Time)

Anticipated individual awards – A single award is anticipated.

Types of instruments that may be awarded – Procurement Contract or Other Transaction.

Any cost sharing requirements – None Agency contact

The BAA Coordinator for this effort can be reached at:

HR001122S0015@darpa.mil

DARPA/STO

ATTN: HR001122S0015

675 North Randolph Street Arlington, VA 22203-2114

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

This publication constitutes a Broad Agency Announcement (BAA) as contemplated in Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016 and 2 CFR § 200.203. Any resultant award negotiations will follow all pertinent law and regulation and any negotiations and/or awards for procurement contracts will use procedures under FAR 15.4, Contract Pricing, as specified in the BAA.

The Defense Advanced Research Projects Agency (DARPA) is soliciting innovative proposals for the Air Combat Evolution (ACE) program to convert existing F-16 aircraft into human-on-the-loop, safety-sandboxed testbed aircraft to support autonomy development and experimentation.

A. Program Overview

1. ACE Program Background

DARPA is developing a new warfighting concept called Mosaic Warfare, which is an approach to combined arms maneuver, wherein capabilities traditionally provided to close a monolithic kill chain dependent upon a single, eminently capable platform are instead provided by a heterogeneous set of manned and unmanned systems. When properly orchestrated, these dynamically composed webs of heterogeneous kill chains deliver a range of necessary effects.

In the Mosaic Warfare vision, humans are expected to fight in close collaboration with autonomous weapon systems in complex environments (such as those described by coupled, nonlinear, heterogeneous, and adaptable agents) with tactics informed by artificial intelligence (AI). Future warfare involving manned platforms directing a larger number of proliferated unmanned systems in all operating domains cannot be realized without operator trust in combat autonomy. Today’s warfighters operate within Service cultures that tend to distrust complex autonomy and utilize autonomous systems sub-optimally in limited, supporting roles (e.g.

logistics or intelligence, surveillance, and reconnaissance only).

The ACE program will increase trust in combat autonomy using human-machine collaborative dogfighting as its challenge problem, which also serves as a representation of an entry point into complex human-machine collaboration. ACE will apply existing AI technologies to the dogfight problem in experiments of increasing realism. In parallel, ACE will implement methods to measure, calibrate, increase and predict human trust in combat autonomy performance. Finally, the program will scale the tactical application of automating a dogfight to more complex, heterogeneous, multi-aircraft, operational level simulated scenarios informed by live data, laying the groundwork for future live, campaign-level Mosaic Warfare experimentation.

The ACE program effort comprises four technical areas (TAs). This solicitation is for TA4. It is expected that coordination with the TA1 and TA2 performers as well as the Experimentation

Integration Team (EIT) will be required to achieve performance objectives. A description of each relevant technical area and the EIT follows the figure.

Figure 1 shows the relationship between the different ACE program Technical Areas. The ACE program is constructed to address four primary technical challenges:

1. Technical Area 1: Build combat autonomy for local (individual and team tactical) behaviors

2. Technical Area 2: Build and calibrate trust in air combat local behaviors

3. Technical Area 3: Scale performance/trust to global (heterogeneous multi-aircraft) behavior

4. Technical Area 4: Build full-scale air combat experimentation infrastructure

Figure 1. Relationship between the ACE Technical Areas and EIT.

The TA1 performers develop and demonstrate AI algorithms capable of human-level performance in air combat within visual range (WVR) individual and team tactical maneuvering.

Implementation in Phase 1 used government-furnished infrastructure for modeling and simulation (M&S). TA1 performers will graduate to progressively more realistic implementations including live risk-reduction aircraft in Phase 2, and ultimately full-scale combat representative aircraft modified by TA4 in Phase 3.

The TA2 performer models and defines well-calibrated trust, mistrust, and distrust in the autonomous system performance. Human pilots must appropriately trust the performance of the resulting systems to drive acceptance of their use on military aircraft. The TA2 performer is responsible for modeling pilot trust within the context of the ACE program parameters, including the experimental design construct and trust data analytics. They are also responsible for aspects of human-machine interaction methods and human-machine interface (HMI) design and development, working closely with TA1 performers, the TA4 performer, Subject Matter Experts (SMEs), and the Experimentation Integration Team (EIT) to operationalize HMIs that support well-calibrated pilot trust in TA1 AI agents.

To enable the modeling and trust calibration, ACE uses a dual operational task (DOT) paradigm.

In this DOT paradigm, the operator is responsible for dividing attention and workload between two, equally important but mutually exclusive tasks: the dogfight and a simulated mission commander task. The TA4 performer will not be responsible for developing the DOT; however, TA4 performers should ensure appropriate displays and interfaces are available to support the DOT onboard the aircraft.

The TA3 performer is focused on scaling algorithmic approaches to battle management scenarios. No dependencies from TA3 are expected to impact TA4. Close interaction between the TA3 and TA4 performer is not anticipated.

A Government-led independent Experimentation Integration Team (EIT), facilitated by Johns Hopkins University Applied Physics Lab, coordinates the interdependent research activities associated with the different Technical Areas. Due to the complicated integration requirements across multiple performers relying on a common experimentation infrastructure, the EIT will be responsible for the development and maintenance of the necessary Interface Control Documents (ICD) and Application Programming Interfaces (API) associated with M&S, risk reduction aircraft, and full-scale aircraft assessments. Extensive interaction between the TA4 performer and the EIT is expected.

2. Solicitation Details

After a successful Phase 1, the ACE program has entered Phase 2. As such, this solicitation is for TA4 Phase 2 (Base Period) and TA4 Phase 3 (Option 1). The solicitation also includes an additional aircraft hardware option (Option 2), and an additional aircraft mission systems software integration option (Option 3). The purpose of the Phase 2 and Phase 3 efforts are to support autonomous WVR maneuvering and trust research in the ACE program, while the additional aircraft options are designed to support ACE as well as a wider range of autonomy development needs.

Technical Areas 1, 2 and 3 (TA1, TA2, TA3), as well as Phase 1 of Technical Area 4 (TA4), were solicited under prior BAAs (HR001119S0051 and HR001120S0028). Information regarding TA1, TA2, TA3, and TA4 Phase 1 is provided in this BAA for informational and contextual purposes only.

Compliant proposals must address the Phase 2 Base Period, the Phase 3 Option (Option 1), and the additional aircraft hardware option (Option 2). Proposers may choose to submit all, some, or none of the mission systems software integration specified in the additional aircraft mission systems software integration option (Option 3).

3. Program Objectives

The primary objective of TA4 is to develop full-scale aircraft experimentation platforms capable of implementing the ACE algorithms and technologies, including human machine interfaces (HMIs), generated by the ACE TA1 and TA2 performers. The TA4 performer will be responsible for full-scale aircraft modification, providing airworthiness documentation, and testing that includes aircraft interface development, ground test, flight test and experimentation, as well as any specialized maintenance. For the Phase 2 Base Period and the Phase 3 Option (Option 1), the performer will modify two F-16D aircraft making them capable of integrating WVR autonomy algorithms developed in TA1 and TA2 through an interface specified in a Government-controlled ICD. The performer will also modify aircraft to provide appropriate interfaces for the integration of HMIs developed in TA1 and TA2, safety pilot overrides, and a paddle off/on disconnect capability. The performer will facilitate safety and airworthiness reviews to enable supervised, live WVR engagements.

A secondary objective of TA4 is to establish human-on-the-loop experimentation infrastructure needed to accelerate development of autonomous systems. The hardware and software solutions proposed under the additional aircraft hardware option (Option 2) and the additional aircraft mission systems software integration option (Option 3) are expected to establish the desired human-on-the-loop experimentation infrastructure. In human-on-the-loop experimentation, a pilot sits in the seat of the aircraft with access to all the onboard controls and safety overrides, while the autonomy is given aircraft and mission systems control to test new functionality. A pilot is then able to test an autonomy solution in a real-world setting while being able to disengage the autonomy at any time by “paddling” it off and taking over control of the aircraft and mission systems. This allows the pilot to both provide feedback to developers and to act as a safety net or runtime assurance for the autonomy. It is also desirable for the pilot to be able to “paddle” the autonomy back on to seamlessly re-engage after the pilot makes an adjustment or correction. Modifications to government furnished F-16C aircraft in quantities of 2, 4, 6, 8, or 10 aircraft are requested for the additional aircraft hardware option (Option 2), while the additional aircraft mission systems software integration option (Option 3) is expected to apply equally across all modified aircraft with connectivity to the specified mission system. The first two additional aircraft are desired for ACE 2v2 testing.

Technical objectives including details about system requirements are documented in Section I.C, Technical Objectives for Phase 2, Phase 3 and the Additional Aircraft Options. These technical objectives apply for all proposed options unless otherwise indicated.

B. Program Structure and Technical Approach

1. Phase 2 (Base Period - 15 Months)

During the Phase 2 base period the performer will provide the design of a technical solution, perform fabrication, installation, and testing of kits to convert two government furnished F-16D aircraft into human-on-the-loop, safety-sandboxed testbed aircraft which meet the desired attributes of the technical approach outlined in Section I.C, Technical Objectives for Phase 2, Phase 3 and the Additional Aircraft Options.

At a high level, these solutions will include a mission computer that receives state data from the aircraft and which has a safety-sandboxed interface to the flight controls, including a newly-installed autothrottle; an IP datalink that enables control-room access to the mission computer during tests for development purposes; interfaces to a live, virtual, and constructive (LVC) capable datalink; and connections to appropriate displays (either carry-on tablets or repurposing of existing displays), helmet-mounted displays, and control interfaces for the pilot (either through a tablet, hands-on-stick-and-throttle (HOTAS), or other solution) to enable operation of the system, and performance of the DOT. Because the required aircraft modifications constitute a control system, end-to-end latency and jitter of the proposed solutions should be minimized.

Figure 2 shows a notional system architecture for the first two aircraft to be modified during Phase 2 and used during Phase 3.

Figure 2. Notional system architecture diagram for the Phase 2 Base and Phase 3 Option period.

The TA4 performer will work with the existing ACE performers and the EIT to develop software interfaces that provide state information to the mission computer and command information to control the aircraft. The performer will also work with existing ACE performers and the EIT to effectively integrate their HMI into the technical solution. It is expected that a multi-function display (MFD) or tablet interface will be required to display and interact with the dual operational task, and that a helmet-mounted display (HMD) will also be utilized as part of the technical solution. Technical solutions should include a software development kit for third party providers and provide the Government the ability to independently expand message sets.

The performer will provide ground and flight test support for their technical solution and conversion kits. Phase 2 will culminate in a flight test of the modified aircraft which demonstrates the safety features of the technical solution and paddle-on/paddle-off functionality of the autonomy.

The performer will provide an M&S environment, a software-in-the-loop (SIL) simulator, and/or a hardware-in-the-loop (HIL) simulator of their technical solution during Phase 2. The M&S environment will need to enable much faster than real-time execution and should be designed to be compatible with the existing ACE simulation framework. To integrate with the existing framework, the performer is desired to provide relevant documentation, model descriptions, data tables and/or software of a reasonable representation of the aero model, the propulsion model, the flight control system (including any safety trips), and the weights and balances of the aircraft as a function of fuel states and stores (mass, moments-of-inertia, CG locations, etc) of the F-16 C/D. It is expected that the M&S environment will require changes as testing proceeds throughout Phases 2 and 3. The M&S environment, SIL, and HIL should replicate interfaces, latency, jitter, safety trips, and other characteristics of real-world operation as closely as possible to those on the aircraft. Ideally, these will be parameterized and exposed in such a way to enable simple model tuning. The SIL and/or HIL should run in real-time. The SIL and/or HIL should be provided with an API, be able to run on a Linux operating system, be able to be containerized (for the SIL), and be accessible through standard interfaces. Source code and/or configuration files should be accessible to the government and EIT so that any parameters on which the system depends (such as the aero model, flight control system, safety logic) can be accessed and varied.

The SIL and/or HIL will be developed in coordination with the EIT.

Latency and jitter will be characterized for each software and hardware interface. These interfaces are often referred to as “adapters”—for example the “platform adapter” is the interface between the mission computer and the connection to the aircraft bus data where aircraft state information is passed in to the mission computer as observations and flight control inputs are passed back. The adapters will be developed by the TA4 performer in coordination with the EIT.

The Phase 2 base period will consist of non-recurring engineering (NRE) design, kit fabrication, and kit installation. Required reviews/meetings are a kickoff, a Preliminary Design Review (PDR), a Critical Design Review (CDR), and Test Readiness Reviews (TRR) prior to ground or flight test events. Major review descriptions and expectations are included in Section I.F.

The performer is expected to perform the kit installation. However, it is possible that the kit installation could impact or dovetail with other scheduled maintenance or modifications, which could require increased schedule flexibility.

Because of the timeframe and scope of the effort in this solicitation, the proposed technical solution is anticipated to rely heavily on prior work. The proposer should clearly identify what parts of their proposed technical solution are prior work versus new work, as well as the heritage of the prior work, especially prior DARPA work. The technical solution should leverage existing high Technical Readiness Level (TRL) solutions and ideally solutions that have a USAF airworthiness certification from prior work.

The proposed technical approach should identify aircraft modifications required by the technical solution, ideally seeking to minimize those modifications and that the modifications be easily reversible when practicable.

The desired timeframe is to have at least one aircraft ready to perform flight test within 15 months of contract award and the second aircraft ready not later than 17 months from contract award.

The performer will be responsible for airworthiness and any security certifications required for the system. The performer will support the ground tests and flight tests required to return the aircraft to flying status after installation of the technical solution. The performer will support data reduction, analysis, and software modification based on ground test and flight test results.

The proposer should include appropriate on-site subject matter expertise during ground and flight checkout of the aircraft modifications. This is expected to occur across approximately a one-month flight window in FY23. The site can be assumed to be Edwards AFB, California or Davis- Monthan AFB, Arizona. Proposers should price the more expensive location.

2. Phase 3 (Option 1 – 15 Months)

The Phase 3 Option period will consist of flight test support of the converted aircraft. At the beginning of Phase 3 the performer will support flight checkout of the two modified F-16D aircraft.

The TA4 performer will be required to support test and safety planning for the 1v1, 2v1, and 2v2 testing windows and competitions. Experiments will be conducted in a live environment using a deliberate build-up approach starting with 1v1, 2v1, and then 2v2 testing events. The use of LVC capabilities will likely be leveraged to enable safe build-up. The performer will need to have appropriate on-site subject matter expertise during live-fly events during Phase 3. This is expected to occur across six, approximately one-month flight windows in FY24. The site can be assumed to be Edwards AFB, California or Davis-Monthan AFB, Arizona. Proposers should price the more expensive location.

For the 2v1 and 2v2 test events, additional manned F-16s may be used as adversary aircraft.

These aircraft will be equipped with the same GFE datalinks as the 2 modified F-16D aircraft. If the additional aircraft options are executed and the first two aircraft are ready, it is highly desirable to use those two aircraft in this role.

Proposers should include unspecified software changes in their bid for Phase 3. It is expected that lessons learned during transition from Phase 2 to Phase 3 will necessitate software changes as well as lessons learned throughout the various flight tests during Phase 3. The TA4 performer should be ready to rapidly modify software to support the program as required during Phase 3.

3. Additional Aircraft Hardware Option (Option 2 – Notionally 21 months)

The additional aircraft options will convert USAF F-16C aircraft (GFE) that have been equipped with the APG-83 radar into human-on-the-loop, safety-sandboxed testbed aircraft to support autonomy development and experimentation. The additional aircraft hardware option will consist of NRE design, kit fabrication, and kit installation. Required reviews/meetings are a kickoff, a Preliminary Design Review (PDR), a Critical Design Review (CDR), and Test Readiness Reviews (TRR) prior to ground or flight test events. Major review descriptions and expectations are included in Section I.F.

At a high-level, this option will replicate the modifications that were made to the first two F-16D aircraft but on F-16C aircraft, and will add additional hardware connectivity by integrating the mission computer with additional mission systems at the physical layer. This option is only for the physical layer and will not require the performer to modify software to create interfaces at the logical layer. The performer will design and perform physical integration (power and appropriate cabling for data) for the following mission systems in a manner that enables software modifications for paddle-on/paddle-off autonomous control over these systems for human-on-the-loop autonomy experimentation. While software modification is not a part of this option, a high level description of how paddle-on/paddle-off autonomous control could be achieved given the wiring solution is required:

Northrop Grumman APG-83 Active Electronically Scanned Array (AESA) fire control radar

Lockheed Martin Legion Pod

ALQ-213

Angry Kitten Pod Link-16 Targeting pods such as the Lockheed Martin Sniper pod or the Northrup Grumman

LITENING pod

Figure 3 shows a notional system architecture for the additional aircraft option.

Figure 3. Notional system architecture diagram for the additional aircraft options.

Desired attributes of the technical approach are outlined in Section I.C, Technical Objectives for Phase 2, Phase 3 and the Additional Aircraft Options. The performer will provide hardware kits and installation for F-16C aircraft. This option includes hardware interconnects to desired mission systems listed in Table 1. Kit costs and installation will be provided for quantities of 2, 4, 6, 8, and 10 additional aircraft. The performer will be responsible for airworthiness and any security certifications required for the system.

The performer will support the ground and flight tests required to return the aircraft to flying status after installation of the technical solution. Ideally, the aircraft will return to flight with software modifications made under the additional aircraft mission systems software integration option (Option 3) complete so that both hardware and software modifications can be tested. The performer will support data reduction, analysis, and software modification based on ground test and flight test results.

Due to the variability in the anticipated solutions for the additional aircraft hardware option (Option 2), proposers should indicate the desired length of the option and when it should be executed in order to achieve program objectives. It is notionally assumed that the start date for work on the additional aircraft hardware option, if executed, will be approximately 9 months after Phase 2 contract award and will last 21 months.

4. Additional Aircraft Mission Systems Software Integration Option (Option 3)

The additional aircraft mission systems software integration option covers software integration of mission systems with the mission computer. Specifically, the ability to read data from and send commands to the following mission systems (assumes hardware connections are in place from Option 2):

Northrop Grumman APG-83 Active Electronically Scanned Array (AESA) fire control radar

Lockheed Martin Legion Pod

ALQ-213

Angry Kitten Pod Link-16 Targeting pods such as the Lockheed Martin Sniper pod or the Northrup Grumman

LITENING pod

Proposers may choose to propose solutions to all, some, or none of the mission systems listed.

Please be aware that these mission systems may be protected in part or in whole at a classified level in corresponding Security Classification Guides (SCGs). For example, the F-16 MULTI- MISSION FIGHTER SECURITY CLASSIFICATION GUIDE governs F-16s and provides classification guidance for parts and systems associated with the F-16. To request the F-16 SCG and other associated SCGs please fill out the Security Classification Guide Request Form in Appendix 4. Note: Some SCGs are COLLATERAL and will require a Facility Clearance (FCL) to receive the classified SCGs. UNCLASSIFIED SCGs will be emailed to the UNCLASSIFIED email provided in the SCG request form.

Each mission system integration will allow the mission computer to send the full set of control inputs to and receive the full set of data feeds from the specified mission system. It is desired to enable at least the same level of functionality a pilot has for control of each mission system.

Proposers should identify the input and output methodologies (1553, Ethernet, etc.), anticipated data sets, frame rate, real-time, operating system, tools, etc. for their proposed integration with each mission system as well as any functions that would not be automated or require interaction with the mission computer, aircraft and/or the pilot (e.g. initialization, calibration, etc.).

Proposers are encouraged to focus their responses on their interface(s) with the mission systems rather than the performance of the mission systems.

Proposers should describe the system safety elements of each mission system integration such as disconnects, performance limitations, etc. Safety overrides need to be designed to enable the pilot to disengage all autonomous functions for the mission systems as a whole. It is recommended that this use a similar HOTAS action as in Section I.C. Technical Objective 7:

Paddle Off and On Capability. This would provide a single HOTAS action that disengages all autonomy functionality.

Ideal solutions will enable seamless paddle off/on capabilities for all of the mission systems.

This means that a pilot can seamlessly toggle-on and toggle-off the autonomy for all mission systems at once, with control for the toggled-off systems reverting to traditional pilot control.

Additionally, the technical solution will have the ability to individually toggle on or off autonomy functionality for each of the controlled mission systems. For example, if the pilot likes the way the autonomy is managing radar and flying the aircraft but does not like the way the autonomy is handling the targeting, the pilot should be able to independently disengage the autonomy’s control of targeting without impacting the autonomy’s control of the radar and flight controls. Likewise, the pilot should be able to independently disengage the flight controls without affecting the autonomy’s control of the radar and targeting.

Proposers should strive to provide solutions that enable the displays in the cockpit to continue to be populated as expected by the pilot while the mission computer is controlling the mission system in the autonomous mode. This enables the pilot to have situational awareness of what the autonomy is doing by monitoring the same displays the pilot has experience with. This does not preclude development of additional enhanced displays that can be displayed on the tablet interfaces.

Proposers should ensure that all mission systems data can be recorded by the mission computer at all times, whether the pilot is flying or the autonomy is engaged.

Proposers should identify all aircraft modifications required for each mission system integration, ideally seeking to minimize those modifications. It is desired that the modifications enable A/B style operations so each mission system could be operated in an autonomy-enabled mode, or an “unmodified, operationally representative” mode if required for other testing purposes.

The approach to integrating the software, safety sandbox, and toggle-on/off functionality may dictate particular hardware interconnect requirements and/or modification of an OFP. Details regarding these considerations and their impacts should be provided in the proposal.

Due to the variability in the anticipated solutions for the additional aircraft mission systems software integration option (Option 3), proposers should indicate the desired length of the option and when it should be executed in order to achieve program objectives.

C. Technical Objectives for Phase 2, Phase 3, and the Additional Aircraft Options

This section discusses the technical objectives. The proposer’s technical solution and statement of work (SOW) should address as many of these objectives as possible. The proposer should include a table in their proposal that specifies the extent to which the technical solution will meet each objective (completely, partially, or not at all). These objectives apply to all options unless otherwise specified.

1. Technical Objective 1: Overall technical solution elements and attributes

The proposer will identify a reasonable location to house all required components and include an analysis of size, weight, and power (SWAP) considerations. Podded solutions are less desirable than internal solutions. Solutions which utilize the ammo drum are less desirable than podded solutions.

The proposed technical solution will consist of the following elements at a minimum:

1. Control of the flight controls from the mission computer. The proposed technical solution’s interface to the flight controls will include control of roll, pitch, yaw, throttle (autothrottle modification), and speedbrake. Additionally, the performer should identify and implement other kinds of control modes that would be useful for autonomous operations. As an example, the following types of flight control modes beyond the already present F-16 flight control laws, are desired (not to preclude other control modes):

a. Flight states (for example heading, speed, and altitude (HSA))

b. Trajectory following (climb/dive profiles, route following, ground and collision avoidance trajectories, etc.)

c. Pitch: Gamma, Pitch rate (Nz assumed)

d. Roll: Roll Rate, Roll Angle

e. Throttle: Power Lever Angle Command, Speed Command

2. Software capable of enabling third party autonomy applications on the mission computer to control the aircraft flight controls and mission systems as specified in the remaining technical objectives.

3. Hardware connections from the mission computer to aircraft mission systems. Read/write hardware access is desired for all mission systems listed in Technical Objective 5 unless otherwise specified.

4. Software on the mission computer will be designed in a modular fashion. Source code for all software developed to run on the mission computer is desired. This will include adapters for each external-facing component (aircraft flight controls, 1553 interconnect, etc.). The performer will identify an open mission systems (OMS) compliant interface specification. Delivery of a non-proprietary solution including a non-proprietary critical abstraction layer (CAL) is desired.

5. A safety sandbox as described in Technical Objective 3.

6. Data from aircraft state, mission computer, applications and aircraft systems to be provided to the autonomy application, recorded onboard, transmitted to a ground control station and available for live, virtual and constructive (LVC) operations. This data is anticipated to be contributed to a repository. The proposed technical solution will include data-gathering capabilities for the repository, that is the recording, labeling and offboarding of flight, aircraft, mission computer and application data. The proposed data gathering process should be documented in the proposal.

7. Interface with center pedestal display unit (CDU) (may or may not be installed).

8. Helmet with helmet mounted display (HMD), such as the Thales Scorpion Helmet.

9. Two tablet displays per cockpit that would be aircrew carry-on equipment (via Ethernet ports with RJ45-to-USB converters for ejection seat considerations, two required per cockpit).

10. Interface to a GFE time and space position information (TSPI) pod, such as Cubic Secure LVC Advanced Training Environment (SLATE) or Collins Aerospace Common Range Integrated Instrumentation System (CRIIS).

2. Technical Objective 2: The technical solution should be hosted in a mission computer allowing inflight software changes without impacting airworthiness.

An objective for the technical solution is that all software should be able to run on a mission computer and tablets with no impact on the airworthiness of the aircraft. The system should be architected such that any modification can be made to the software running on the mission computer or tablets without requiring an airworthiness review. Software running on the mission computer should be able to be changed during flight without compromising the safety of the system. If there is a component of the modification that is safety-critical, it should be isolated in processing either internal or external to the mission computer and architected to ensure no upstream airworthiness impacts on the mission computer.

The following are additional objectives for the mission computer:

1. Be open architecture and standards-based. Adhere to a VPX standard or other standard which enables swappable upgrades to the compute cards.

2. Include read access for the aircraft’s 1553 buses. Write access is desired but not required.

If write access is included, it would need to be terminated anytime the system is disengaged (disengagement transitions this to read-only access).

3. Include sufficient input/output (I/O) for the flight controls and the aircraft systems listed in Technical Objective 5.

4. Have a proven multi-level security (MLS) certification strategy for the proposed solution.

5. Be capable of hosting real-time and non-real-time operations.

6. Be capable of running x86-based operating systems.

7. Be capable of interfacing with two onboard tablets.

8. Have easy physical access to allow for plane-side loading of software and data downloads post-mission.

9. The mission computer must be able to be powered on for ground operations to include preflight checks that involve hooking up an external computer to the onboard mission computer. One example would be ensuring Ethernet ports are easily accessible that will allow for external computers to connect to the mission computer or connected network switch using secure shell (SSH).

10. Have a minimum of four unused Ethernet ports for future expansion (may be part of a network switch external to, but connected to the mission computer). All Ethernet and switches should be capable of at least 10 Gb/s.

11. Must include dedicated processing for autonomy algorithms using at least two single board computers (SBC) with each SBC having a minimum performance comparable to or better than a 9th Generation Intel Xeon E-2276ME SBC. Single-threaded performance is the main consideration. Additionally, 32GB or more of RAM and at least 256GB of storage are desired for the SBC.

12. Network-attached storage (NAS) is also required with at least 4TB of storage onboard.

13. Have unused expansion slots (four desired, if feasible within SWAP constraints). The number of available unused VPX slots should be specified. It is desirable to have expansion capability without having to add an additional chassis in a future upgrade.

Proposers should characterize any spare hardware and software resources that might be available to/in the mission computer in their proposed technical solution. As a note, upgrading the processors in the CDU may also be considered as an option if shown to meet program needs.

3. Technical Objective 3: Safety Sandbox

The converted F-16 aircraft technical solution must have a safety sandbox/runtime assurance capability. In this context, a safety sandbox is a component of the technical solution in which system behaviors are bound to remain inside pre-defined safety limits allowing rapid but safe experimentations. When the autonomous system behaviors reach the established safety limits, they are to be automatically limited or may be disengaged with control being passed back to the pilot.

The autonomous system’s behavior should be capable of being constantly monitored by both the runtime assurance monitor (the safety sandbox) and the pilot. When performance is undesired or development objectives require it, the pilot may manually suspend and/or terminate the autonomy controlling the aircraft and systems; returning the aircraft to a baseline configuration under the pilot’s control.

The safety sandbox should also have physical components in the cockpit that the pilot interacts with. In particular, safety overrides need to be designed to enable the pilot to disengage all autonomous functions (both flight control and mission systems) with a single switch (paddle may be a good option).

Additionally, the ability to individually toggle on or off autonomy components is desired. An example would be if the pilot likes the way the autonomy is managing radar and targeting but does not like the flight path the autonomy is directing, the pilot should be able to independently disengage the ability for the autonomy to control the flight path without impacting the autonomy’s control of the radar. Likewise, if the pilot likes the way the autonomy is flying the aircraft but wants to override the usage of the radar, it should be possible to independently disengage the autonomous radar control and take over radar management functions in a simple manner.

The ability to take over all safety-critical functions will be possible with HOTAS.

The safety sandbox will have a defined envelope for autonomous operations. If certain flight regions need to be restricted due to aircraft handling characteristics (as an example, regions of higher departure susceptibility), these should be indicated in a clear way that shows the full F-16 aircraft envelope and then the envelope of the proposed solution. Significant changes to the baseline F-16 aircraft envelope are not expected in this work. An example of an envelope restriction is shown in Figure 4 where the gray region represents the aircraft envelope, the blue region represents the autonomy system engaged region and the orange region represents the automatic autonomy disengagement region. Safety sandbox limits must be either statically defined ahead of time or dynamically calculated. The safety limits will be made available on the mission computer as part of the aircraft state space, and will be available to the M&S environment, SIL, and HIL to the maximum extent practicable.

Figure 4. Example safety sandbox showing engaged and disengaged regions. The intent is to restrict the envelope as minimally as possible in angle-of-attack (AOA), calibrated airspeed (KCAS), Mach, and other factor parameters.

The safety sandbox must show the pilot who is in control of a given function at any given time.

This should be able to be clearly displayed and the pilot should be notified when any system is disengaged through the safety sandbox or if the system trips off. The notifications will be clear and unambiguous to ensure flight safety and expressed through the HMI.

Proposers should describe the extent to which the safety sandbox is expected to restrict the aircraft operating envelope. While safety is the primary consideration, a secondary consideration is to otherwise minimize restrictions on the operating envelope.

4. Technical Objective 4: A technical solution that is usable on multiple F-16 variants

It is anticipated that the first two aircraft to be converted are F-16Ds. These two-seat aircraft are anticipated to be Block 30 and Block 32 with hybrid flight control computers (HFLCCs) and center display units in one or both seats. Proposers should specify any particular equipment or software assumed to be installed on the aircraft beyond those listed above. For example, if the solution requires the installation of an automatic ground collision avoidance system (Auto

GCAS).

However, operational F-16s in the U.S. Air Force (USAF) come in many variants. They can generally be broken into F-16C models (single seat), F-16D models (two seats), and pre and post-block aircraft. Additionally, not all aircraft within a block are configured the same due to ongoing upgrades across the fleet. A single squadron often contains multiple aircraft variants.

It is desirable for the technical solution to be viable on both C and D model F-16s and both pre-block (Blocks 30 and 32) and post-block (Blocks 40, 42, 50, and 52) aircraft. Proposers should identify the specific variant(s) of F-16 aircraft on which their proposed technical solution is anticipated to be viable without modification. It is not necessary to show how the proposed technical solution would work on these additional F-16s variants, only to identify those variants to which the proposed technical solution will be viable without significant modifications.

Proposers should also identify if their proposed technical solution is reasonably transferable to other types of F-16s or other aircraft. A high-level discussion should be included to identify what is required to transfer the proposed technical solution to other types of F-16s or other aircraft.

Again, it is not necessary to show how the proposed technical solution would work on these additional F-16s variants, only to identify those variants to which the proposed technical solution will reasonably transfer. At most, proposers should include a sentence or two explaining the changes necessary.

While the extent to which the proposed technical solution addresses the USAF F-16 fleet (i.e.

which and how many type(s) of F-16 aircraft the proposed technical solution could be applied to) is important, cross-block applicability is less important than proposing a high technical readiness level (TRL) solution that leverages prior work, especially if portions of the prior work have been certified as airworthy by the USAF.

5. Technical Objective 5: The technical solution will include hardware interfaces to F-16 mission systems.

Proposers should propose hardware communications connections (both Ethernet and 1553 wiring as applicable) between the mission computer and appropriate aircraft stations (wing, chin, pylons, etc.) and locations for the mission systems listed below.

The mission computer should be capable of sending control inputs to and receiving data feeds from the aircraft mission systems listed in Table 1 (read/write access is assumed unless specified otherwise) as specified for each option.

Table 1. Mission computer interfaces to mission systems.

Mission System Description Phase 2 Base and Phase 3 Option (first two F-

16D aircraft)

Additional Aircraft Options (follow-on F-

16C aircraft) 1553 Interconnect (read-write desired but read-only acceptable)

H, S H, S

TSPI pods, such as Cubic SLATE or Collins Aerospace CRIIS H, S H, S

IP Datalink (with encryptor or built-in encryption) H, S H, S

Mission System Description Phase 2 Base and Phase 3 Option (first two F-

16D aircraft)

Additional Aircraft Options (follow-on F-

16C aircraft) Lockheed Martin Legion Pod Ethernet connection H H, S

Northrop Grumman APG-83 Active Electronically Scanned Array (AESA) fire control radar

No H, S

ALQ-213 H* H, S

Angry Kitten Pod H* H, S

Link-16 H* H, S

Targeting pods such as the Lockheed Martin Sniper pod or the Northrup Grumman LITENING pod

H* H, S

Note: H indicates that a hardware interconnect is desired, S indicates that a software interface is also desired, No indicates no connection is desired, H* indicates that hardware interfaces are desired for these systems for the F-16D aircraft being modified for Phases 2 and 3, but should only be pursued if they have minimal impact to the schedule

6. Technical Objective 6: The technical solution will be designed to accommodate a safety pilot and an evaluation pilot (applies only to Phase 2 and Phase 3 option)

For ACE TA4 Phase 2 and Phase 3 research, a two-seat F-16 variant is needed to allow for a safety pilot and an evaluation pilot. This is to enable the evaluation pilot to perform a dual-operational task created by another technical area that consists of a pilot performing a dual-operational management task while simultaneously monitoring an AI algorithm performing WVR maneuvering, colloquially known as dogfighting. The safety pilot will ensure safe execution and monitor the aircraft and the evaluation pilot. System design should consider the seat position and setup for both the safety pilot and evaluation pilot, to include safety overrides, displays (both safety displays and those required for a given task), and location of switches.

7. Technical Objective 7: Paddle Off and On Capability

A capability to turn the autonomy off and on inflight, smoothly switching between autonomous and piloted control is desired. Ideally, the pilot can test autonomy solutions in a real-world setting while being able to disengage the autonomy at any time by “paddling off” and taking control of the aircraft and mission systems. This allows the pilot to both provide feedback to developers and to act as a safety net or runtime assurance for the autonomy. It is also beneficial for the pilot to be able to paddle the autonomy back on, seamlessly re-engaging after the pilot has made adjustments or corrections.

D. Proposal Assumptions

The following assumptions should be used in preparing the proposal:

1. There will always be a pilot onboard the aircraft.

2. The airworthiness will be obtained through the USAF at a demonstration value level. The airworthiness effort will be limited to assessing the technical capability of maintaining the integrity of the safety sandbox and integration with the aircraft and ultimately the baseline configuration of the platform when the safety sandbox is active. Specifically, it will not address the autonomous agent software or other software running in the safety sandbox.

3. The performer will support all USAF airworthiness efforts. The performer will provide documentation in support of the airworthiness process. The performer will support testing required by the airworthiness effort.

4. The performer will support all security certification requirements.

5. The aircraft will be provided as GFE.

6. The aircraft mission systems listed will be provided as GFE. Aircraft may have some, none, or all of these systems.

7. Pilots, aircraft, and operation and maintenance of the aircraft will be provided by the

USAF.

8. Source code is an expected deliverable for all software running on the mission computer and in the various simulation environments.

9. The government will obtain at least government purpose rights in noncommercial technical data, noncommercial computer software, and noncommercial computer software documentation. Any claims for intellectual property rights shall be explicitly stated in the proposal.

Additional assumptions should be listed explicitly within the proposal.

E. Program Metrics, Deliverables, and Milestones

For the Government to evaluate the effectiveness of a proposed solution in achieving the stated program objectives, proposers should note that the Government hereby promulgates the following program metrics, deliverables and milestones that may serve as the basis for determining whether satisfactory progress is being made to warrant continued funding of the program. Although the following notional program metrics, deliverables, and milestones are specified, performers should note that the Government intends these goals to bound the scope of effort, while affording the maximum flexibility, creativity, and innovation in proposing solutions to the stated problem. Proposals should cite the quantitative and qualitative success criteria that the proposed effort will achieve by the time of each Phase’s program metric measurement.

Proposers may adjust the schedule of the deliverables to reflect expected timelines and are encouraged to adjust the milestones and deliverables to meet program objectives. A notional high-level schedule is shown in Figure 5.

FY 2022 FY 2023 FY 2024

Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4

Task Phase 2 Base Period: 15 Months Phase 3 Option 1: 15 Months

Air Combat Evolution (ACE) F-16 Aircraft

• Full-scale (FS) technical solution design, modification, airworthiness, training, and testing

• This is the Phase 2 base and Phase 3 option

Additional Aircraft Option 2: 21 Months

Additional Aircraft Option 2

• Additional Aircraft Hardware Integration

1v1 Testing

1v1 Comp.

2v1 Testing

Kick Off

Flight Demo

2v2 Comp.

2v2 Testing

PDR CDR

Fab Kit & Mod Aircraft 1&2

Airworthiness Complete

2v1 Comp.

Flight Testing