DARPA-BAA-14-33_-_Amendment_1_-_05-16-2014.pdf

Broad Agency Announcement – Amendment 1

Collaborative Operations in Denied Environment (CODE) Program

Tactical Technology Office

DARPA-BAA-14-33

April 25, 2014

Contents Part I: Overview Information Part II: Full Text of Announcement

I. Funding Opportunity Description A. Program Vision B. Program Overview C. Missions D. Technology Focus E. Key Performance Objectives (KPO) F. Track A Program Plan G. Track B Program Plan

II. Award Information III. Eligibility Information

A. Eligible Applicants

2. Non-U.S. Organizations

3. Applicants Considering Classified Submissions B. Procurement Integrity, Standards of Conduct, Ethical Considerations, and Organizational Conflicts of Interest C. Cost Sharing/Matching D. Other Eligibility Criteria

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 and Selection Process

VI. Award Administration Information A. Selection Notices B. Administrative and National Policy Requirements C. Reporting D. Electronic Systems

VII. Agency Contacts VIII. Other Information

A. Intellectual Property - Procurement Contract Proposers B. Non-Procurement Contract Proposers – Noncommercial and Commercial Items (Technical Data and Computer Software) C. All Proposers – Patents D. All Proposers – Intellectual Property Representations E. All Proposers – Proposer’s Day

Appendices

Appendix A1 – Demonstration Platform and Payload Information (Export Controlled)

Appendix B – Mission Scenario 1: Tactical Reconnaissance

Appendix C2 – Mission Scenarios 1-3 (Classified SECRET//NOFORN)

Appendix D – CODE Study Report: Open Architectures for Collaborative UAV Autonomy

1 Please refer to Section IV, Sub-section A, “Address to Request Application Package,” for instructions on requesting classified and/or export-controlled appendices.

2 See [1].

Part I: Overview Information Federal Agency Name – Defense Advanced Research Projects Agency

(DARPA), Tactical Technology Office (TTO) Funding Opportunity Title – Collaborative Operations in Denied

Environment (CODE) Program Announcement Type – Initial Announcement Funding Opportunity Number – DARPA-BAA-14-33 Catalog of Federal Domestic Assistance Numbers (CFDA) – Not

Applicable Dates o Proposers’ Day: 04/11/2014 o Posting Date: 04/25/2014 o Deadline to Request Copies of the Classified and Export Controlled

Appendices: 05/02/2014 o Abstract Due Date: 05/02/2014 o Questions Due Date: 05/09/2014 o Proposal Due Date: 06/26/2014 by 2:00 p.m. Eastern Time

Concise description of the funding opportunity: The objectives of CODE are to develop and demonstrate advanced collaborative autonomy algorithms and software to enable existing unmanned aerial platforms to effectively operate in a denied environment.

Total amount of money to be awarded: The total planned budget for award is $14.3M in Phase 1, $15M in Phase 2, and $25M in Phase 3.

Anticipated individual awards – Multiple awards are anticipated.

Types of instruments that may be awarded: Procurement contract or other transaction agreement.

Agency contact o Points of Contact The BAA Coordinator for this effort can be reached at:

DARPA-BAA-14-33@darpa.mil

DARPA/TTO

ATTN: DARPA-BAA 14-33

675 North Randolph Street Arlington, VA 22203-2114

Other – Appendices containing additional export controlled and classified information are available upon request as described in Section IV.A of Part II of this announcement.

Part II: Full Text of Announcement

I. Funding Opportunity Description

The Defense Advanced Research Projects Agency often selects its research efforts through the Broad Agency Announcement (BAA) process. This BAA is being issued, and any resultant selection will be made, using procedures under Federal Acquisition Regulation (FAR) 35.016 and the Department of Defense Grant and Agreement Regulatory System (DoDGARS) Part 22 for Grants and Cooperative Agreements. Any negotiations and/or awards will use procedures under FAR 15.4, Contract Pricing, as specified in the BAA (including DoDGARS Part 22 for Grants and Cooperative Agreements). Proposals received as a result of this BAA shall be evaluated in accordance with evaluation criteria specified herein through a scientific review process.

DARPA BAAs are posted on the Federal Business Opportunities (FedBizOpps) website, http://www.fbo.gov/, and, as applicable, the Grants.gov website at http://www.grants.gov/. The following information is for those wishing to respond to the

BAA.

DARPA is soliciting innovative research proposals in the area of advanced collaborative autonomy for aerial platforms. Proposed research should investigate innovative approaches that enable revolutionary advances in algorithms and software, and, to a lesser extent, devices or systems. Specifically excluded is research that primarily results in evolutionary improvements to the existing state of practice.

A. Program Vision

Over the last 25 years, Unmanned Aircraft (UA, which in this document includes cruise missiles, decoys, and other unmanned aircraft systems (UAS)) have proven to be very valuable tools for performing a wide range of missions from Intelligence, Surveillance, and Reconnaissance (ISR) to tactical strike, and the U.S. Armed Forces have invested heavily in a broad range of systems. However, most of the current inventory is not well matched to the needs of future conflicts, which DARPA anticipates being much less permissive, very dynamic, and characterized by a higher level of threats, contested electromagnetic spectrum, and re-locatable targets. In this environment, our current systems have several challenges:

‐ Systems have very limited ability to autonomously react to changes and either lack the flexibility to adapt to a changing situation (in the case of missiles) or are tightly tied to human operators (for UAS);

‐ Enhancing the survivability features of our current systems using traditional methods would be expensive or impossible;

‐ Systems at the tactical edge are working in isolation – instead of relying on nearby assets to augment their capabilities, they rely on distant strategic assets for critical functions such as navigation, off-board targeting, and communication;

‐ UAS are operated by large crews. This is expensive and incompatible with an organic system able to react quickly to a dynamic situation.

Collaborative autonomy has the potential to significantly increase the capabilities of legacy assets as well as to reduce the cost of future systems by composing heterogeneous teams of UA that can leverage the capabilities of each asset without having to duplicate or integrate capabilities into a single platform. Using collaboration algorithms, UA can provide services to each other, such as:

‐ Geo-locating targets with long distance sensors and guiding less capable systems within their sensor range, ‐ Providing multi-modal sensors and diverse observation angles to improve target identification, ‐ Transmitting critical information through the network, ‐ Providing navigational aid to disadvantaged assets, or ‐ Protecting each other by quantitatively overwhelming defenses and other stratagems.

Through these collaborative behaviors and others, the UA teams can achieve greater mission efficiency by, for example:

‐ increasing area coverage for target detection or rapid task execution, ‐ dynamically assigning tasks, or ‐ optimizing team composition and resource usage based on mission needs.

B. Program Overview

CODE’s top level goals are to:

‐ develop and demonstrate the value of collaborative autonomy in a tactical context;

‐ rapidly transition the capability to the warfighter;

‐ develop an enduring framework to expand the range of missions, platforms, and capabilities that can leverage collaborative autonomy; and ‐ develop an open architecture that enables all members of the rich community of unmanned systems and autonomy researchers to contribute to current and future capabilities.

The Government will use a phased acquisition approach for the CODE program under this BAA (see Figure 1). Phase 1 will be focused on developing CODE system-level mission analysis, system architecture and system design, as well as critical technologies. The first phase includes two tracks: Track A for system integrators and Track B for critical technology developers. Toward the conclusion of Phase 1, Track A system integrators will be invited to submit an updated proposal for Phases 2 and 3, based on the results of their Phase 1 activities as well as incorporating achievements of Track B performers as appropriate. Based on these proposals, DARPA anticipates selecting up to two teams to continue detailed design of their CODE system and conduct initial in-flight demonstrations during Phase 2. At the end of Phase 2, team selections for Phase 3 will be made to develop and demonstrate the full mission capability during three series of flight tests that will be conducted every four to six months. DARPA strongly encourages the use of the Agile methodology to expedite software development and keep up with this test schedule.

Figure 1. Program Schedule

In order to focus the research on autonomy, DARPA will provide the test platforms equipped with the computing environment and the communication gear required, as well as the test range(s) and takeoff and landing pilots. The performers will be requested to provide an Office of the Secretary of Defense (OSD) UAS Control Segment (UCS) compliant control station equipped with the advanced Human Systems Interface (HSI) and any additional payloads not readily available on the test platforms.

Initial information about the platforms and payloads is provided in export-controlled Appendix A. Further information will be provided during Phase 1 as required.

An open and modular software architecture is critical to leveraging the large community of researchers who are developing breakthrough autonomous capabilities today, and who will continue to do so in the future. Although there are numerous standards being developed for UA, none provides an ideal solution for CODE.

Therefore, during Phases 1 and 2, the performers will be required to work collaboratively with the Government to adapt an existing architecture to CODE’s specific needs.

C. Missions

DARPA has selected three missions3 of high interest to the Warfighters that have a high potential to benefit from collaborative autonomy and may offer opportunities for rapid transition on operational platforms. The missions cover the typical sequence of events of a strike mission in a denied environment. A denied environment differs from a more permissive environment in several ways, including:

‐ Long distances;

‐ A congested and contested electro-magnetic spectrum, which is especially challenging to our space-based high bandwidth communication and positioning (GPS) services;

‐ Mobile or rapidly re-locatable targets;

‐ Significant use of decoys, camouflage, and other denial techniques;

‐ High threat levels, where manned assets could be at great risk; and ‐ Highly integrated defenses requiring coordinated actions for defeat.

Details regarding each mission are provided in Appendix B and classified

Appendix C. These missions will be used to assess the value of the proposed collaborative algorithms. This multi-mission assessment will be conducted primarily in simulation. Flight demonstrations, in contrast, will be focused on a single mission. This mission will be selected by DARPA at the end of Phase 1 from among the three missions listed in Appendix B and classified Appendix C, as well as any others that DARPA may select based on Service feedback, performer recommendation, or emerging Phase 1 results.

D. Technology Focus

DARPA has identified four critical technology areas that will be the focus of this program. The following subsections detail the four focus areas and provide examples of concepts that may be of interest. These examples are not meant to bound the research, but rather clarify the type of research sought under this BAA. In general, technical approaches that directly leverage collaborative operations among elements of the team (including UA, command station, and supervisor) might be of interest in contrast to approaches that would favor single agent solutions. For example, if increasing the UA range had operational relevance within the proposer’s technical approach, solutions that would explore the use of formation flight (a collaborative approach) could be of interest, whereas solutions that would improve single vehicle efficiency – for example, adding winglets – would not.

3 DARPA reserves the right to provide updated mission guidance prior to Phase 2, based on the emerging Phase 1 results.

In all cases, the proposed solutions should be sensitive to communication requirements by minimizing to the extent possible the bandwidth required to connect elements of the team. Solutions should also be tolerant of communication disruptions, as this will improve the ability of the team to perform in a denied environment. Finally, proposers should consider the ease of retrofitting the capability into existing platforms and the breadth of applicability of the concept (including computational requirements and specialized hardware). This will facilitate transition and increase the potential impact of the program.

Other technologies that fall outside of the four focus areas, such as secure networked radios, information assurance, tightly coupled distributed apertures, and platform and sensor design, are also important or potentially of high value in the context of a distributed system; however, they are not the focus of the CODE program. Those technologies are either the subject of on-going research and not quite mature enough to be integrated in the near term, or are not uniquely related to collaborative autonomy, and, therefore, do not fit in this program.

1) Single Vehicle Level Autonomy

In order to have an autonomous team of UA, each aircraft has to have a sufficient level of autonomy on its own. This includes autonomous management, both under routine and abnormal conditions, of platform subsystems, mission equipment, and flight trajectories. The following autonomous UA capabilities are of interest:

‐ Ability to analyze the vehicle status data that is traditionally sent to the control station for the pilot to review, such as temperatures, pressures, remaining energy, etc., and define vehicle state and residual capabilities;

‐ Ability to identify and react to common contingencies;

‐ Advanced methods for addressing lost link contingency without immediate mission failure (e.g. maintain custody of target and playback of data when link is restored, automated search while under emission control, or pre-negotiated behaviors in case of lost link to prevent collision with other team members);

‐ Approaches that enable each UA to locally analyze its own sensor feeds and reduce the data set (e.g. from full motion video to still pictures or short snippets) based on mission objectives (e.g. looking for moving vehicles of a certain size) or on inputs from other UA;

‐ Ability to autonomously track moving targets by combining sensor control and aircraft trajectory to maintain optimal sensor performance;

‐ Ability to define and control complex flight trajectories in the same manner as a pilot in a control station – without necessarily having or requiring access to the autopilot inner loops.

2) Human-System Interface

The first step to having a team of assets collaborate is to have a common goal (i.e.

mission objectives). Providing this goal, defining the constraints and operational context, evaluating the progress and remaining activities towards achieving the objectives, and enabling dynamic interactions with the mission commander during mission execution is the role of the Human-System Interface. DARPA is interested in approaches that:

‐ Enable supervisory control of a large group of UA (≥4) that are conducting tactical level operations from a mobile command station4;

‐ Facilitate mission planning, including definition of mission objectives, area of operation, and rules of engagement;

‐ Enable natural interactions between the mission commander and the system;

‐ Provide situational awareness of both the current state (blue and red team, environment including weather, Electro-Magnetic Spectrum, known and suspected threats) and the future state (including probabilistic state for red team, if applicable);

‐ Provide a concise but comprehensive targeting chipset so the mission commander can exercise appropriate levels of human judgment over the use of force or evaluate other options;

‐ Leverage advanced user interfaces/approaches such as those found in video games;

‐ Balance training requirements and capabilities; and ‐ Support bi-directional information flow with mixed initiative (such as minimally-invasive notifications from UA or information pull requests from the Mission Commander).

3) Team Level Autonomy

To benefit from Collaborative Operations, and given a common goal and set of constraints, a UA team needs a common understanding of the operating environment that evolves as data is collected. The accumulation of (pre-processed) data from multiple sources should lead to actionable information through data fusion, analysis (including help from the human team commander), and closed loop control to improve the team’s world model. Based on this model, an action plan leveraging the strength of each team member can be defined. DARPA is interested in collaborative autonomy algorithms and software that:

‐ Fuse data from multiple sources and multiple data types;

‐ Develop a common decision making and world-modeling framework that is robust to poor communications (in terms of bandwidth, quality of service, latency, and availability) and random attrition among the team members;

‐ Dynamically compose teams or sub-teams to achieve mission objectives;

4 We use the term command station here to differentiate from the traditional control station (often referred to as GCS) from which UAS are flown.

‐ Improve team performance in range, endurance, navigation, communication, and all steps of a strike mission (find, fix, track, target, engage, assess - F2T2EA);

‐ Enable mission execution independently of space or other non-organic assets (such as communication or GPS satellites, Joint Surveillance Target Attack Radar System, Airborne Warning and Control System, etc.); and

‐ Accommodate large (not necessarily Gaussian) uncertainty and dynamic changes (due, for example, to team attrition, sudden jamming, or appearance or disappearance of threats).

4) Open Architecture

Open architecture has long been recognized as potentially beneficial to the Government and Industry by, among other things, increasing the potential pool of performers and programs. A larger pool of performers benefits the Government by increasing competition. A larger number of programs benefits Industry by increasing the number of opportunities to compete as well as the number of programs that are candidates to buy their products. This is especially true in the autonomy domain where a very large, diverse community of performers exists. Therefore, developing an open modular architecture (or, to the extent possible, adapting an existing one) is a requirement for the CODE program.

Ideally, the architecture would have the following attributes:

‐ Absolutely no proprietary restrictions on the interfaces and module definitions (i.e., “what” a module does). In contrast, “how” a module does something, if entirely developed at private expense, can remain proprietary;

‐ Adherence to existing or emerging standards to the fullest extent possible (such as STANAG 4586, STANAG 4559, STANAG 3277, COT, UCI, or UCS) with as few modifications as possible;

‐ Adherence to recognized software practices, especially as related to the quality of supporting documentation for flight safety certification and information assurance, including automated unit tests, stress tests, and auto-generation of standard software quality metrics;

‐ Highly modular with ability to extend capabilities, number of agents, and number of contributors;

‐ Significant library of existing modules that support collaborative autonomy or ability to rapidly leverage or integrate such library(ies);

‐ Significant pool of developers familiar with software environment, operating system, and existing modules;

‐ No license fees required for developers or the Government for any part of the architecture;

‐ Ability to support multiple levels of security for receiving, handling, or creating classified data;

‐ Rich development environment (developers’ tool kit, examples, automated tests);

and

‐ High performance (low computation and communication overhead, real time guarantees).

E. Key Performance Objectives (KPO)

The following performance attributes capture the areas in which significant improvements over state-of-the-art capabilities are sought:

‐ Mission efficiency, ‐ Communication requirements, ‐ Manning, ‐ Command station, ‐ Openness of the architecture, ‐ Transition-ability, ‐ Multi mission capability.

These high level objectives need to be translated into Measures of Performance

(MoP). The proposers are expected to propose initial MoP that are correlated to their technical approach. These will be iterated during Phase 1, approved by DARPA, and used in trade studies.

1) Mission Efficiency

This is a relative measure compared to a baseline capability or, if it doesn’t exist, comparing a collaborative approach to a non-collaborative approach. Mission efficiency can be measured using a mix of parameters depending on the mission, such as:

‐ Normalized cost of the mission (e.g. $/km2; $/target);

‐ Timing (e.g. how long does it take to complete the mission; how long does it take to react to a sudden event?);

‐ Cost to the adversary (e.g. how much does it cost the adversary to deny us mission success?).

Further details are provided in Appendix B and classified Appendix C. In all cases, CODE should provide improvement by a factor of 2 or more over the reference5.

2) Communication Requirements

Minimizing communication requirements between all nodes, especially bandwidth, is important, as lower bandwidth will be easier to maintain in denied environments and could also enable the use of existing low bandwidth waveforms.

DARPA recognizes that, alternatively, the distance between nodes could be traded in favor of higher local bandwidth. Since this could be a valid technical approach that

5 For the proposal, the proposers may select the reference based on their best judgment and understanding of the mission. During Phase 1, DARPA may provide a different reference.

possibly leverages collaborative behaviors, DARPA does not want to preclude it by placing an arbitrary upper limit on all communications between nodes. However, for crew safety reasons, DARPA assumes that the command station is further apart than the bulk of the team and that communications with the command station will require more resources. Therefore, DARPA is interested in solutions in which the average bandwidth to and from the command station is less than 50 kbit/s.

3) Manning

DARPA is interested in solutions that require one person or less (i.e. the UA team management may not be the only task required of the supervisor) to manage a mission, except for the launch and recovery segments, which may use more personnel as needed.

4) Command Station

The CODE command station should:

‐ Demonstrate that a single person can effectively control a UA team from a moving vehicle (ground, air, surface, or undersea);

‐ Show that the system is useable in a tactical environment;

‐ Demonstrate the ability to rapidly define mission parameters;

‐ Demonstrate the ability to iterate mission plan;

‐ Demonstrate the ability to easily visualize the current operating picture (including blue and red teams and environment);

‐ Demonstrate the ability to rapidly regain situational awareness in case of temporary distraction of the commander;

‐ Demonstrate connectivity and information exchange with field nodes and other local or global users.

5) Openness of the Architecture

The proposed architecture should maximize the level of openness as measured by a framework such as the Open Architecture Assessment Tool (OAAT6). The OAAT is an analytic tool that evaluates responses to a set of interrelated questions to provide program managers with an objective and evidence-based assessment of the degree that a program exhibits openness. The degree that openness is implemented is presented in terms of business/programmatic and technical criteria. The business/programmatic criteria include questions that address: Open Architecture, Modular Open Design, Interface Design and Management, Treatment of Proprietary Elements, Open Business Practices, Peer Review Rights, and Technology Insertion. The technical criteria cover the essential Open Architecture (OA) design tenets of Interoperability, Composability, Reusability, Maintainability and Extensibility.

6 For more details see https://acc.dau.mil/CommunityBrowser.aspx?id=121180&lang=en‐US

Within this framework, CODE’s objective will be to score HIGH, and preferably 4 and 4.

6) Transition-ability

Transition of the capabilities developed and demonstrated under CODE will be greatly facilitated if the system is easy and economical to implement. One measure of the ease of implementation is the recurring cost of any upgrade required for existing systems.

The total cost for upgrading a sufficient number of systems to perform each of the missions described in Appendix B and classified Appendix C 10 times should be compared to the costs of the reference case and be less than 10% of the reference cost.

7) Multi Mission Capability

Developing capabilities that are broadly applicable and easily portable to as many mission types as possible is highly desirable to control non-recurring cost. For CODE, this objective can be measured by the degree of commonality of the software between the three missions. DARPA is setting a goal of 90% commonality measured in software lines of code (SLOC) or equivalent.

Furthermore, the proposers may propose other missions in addition to those provided in this BAA that would be able to directly leverage the software modules.

F. Track A Program Plan

1) Overview

For Track A, the CODE program will be conducted in three phases:

‐ Phase 1: System Requirements Definition and Preliminary System Design ‐ Phase 2: Risk Reduction, Critical Design Review, and limited flight tests ‐ Phase 3: System Fabrication, Integration, and Demonstration

Each phase will progressively mature the design and technologies required to validate the ability to achieve the program goals and key performance objectives described above. Figure 1 illustrates the program schedule with anticipated major milestones highlighted. The following sections describe the specific objectives of each phase.

2) Phase 1

Phase 1 is a 15 month effort covering the System Requirements Definition and Preliminary System Design. The top-level Phase 1 objectives for Track A are as follows:

‐ Complete conceptual design of the operational system (OS) ‐ Derive demonstration system (DS) requirements and complete preliminary design of demonstration system ‐ Support development of operational architecture

Operational Systems Design

The performers will hold a series of concept design reviews (OS-CoDR) of the Operational System(s) that are responsive to the missions presented in Appendix B and classified Appendix C (Mission Definition) starting three months after award and updated at every major review. The concept design should cover the full life cycle of the approach from system development (preferably upgrading existing UA) through Verification and Validation (V&V) and Test and Evaluation (T&E) of the new capability, deployment of the assets to theater, and mission execution (including launch and recovery).

The performers will refine the MoP from their proposal and will present them at the first OS-CoDR for DARPA’s approval.

The performers will conduct design trade studies on the critical technologies identified in Section D above with the objective to assess alternative technical approaches, including the approaches from the Track B performers, using the KPO and the derived MoP to guide the trades.

The performers shall attend quarterly Technical Interchange Meetings (TIM) where the Track B performers will present their progress. These meetings will be held in the Northern Virginia area over no more than three days per TIM.

The performers will develop a simulation environment capable of validating their design’s ability to meet the KPO. This simulation should use, to the extent possible, Government sanctioned models and have sufficient level of fidelity to yield credible conclusions.

The performers will develop a comprehensive transition plan that defines the path to upgrading/developing the systems they use in their OS concept design. These plans should highlight the technical data needed to implement the modifications and how they plan to obtain it (e.g. collaboration with the original equipment manufacturer (OEM) or the Program Executive Office (PEO) if Government owned).

Technology Maturation Plan

The performers will develop a detailed Technology Maturation Plan (TMP) that provides the Government with the fiscal and technical information necessary to support Phase 2 and Phase 3 program planning. The TMP will provide an integrated basis for all risk reduction activities that will be performed.

The TMP will:

‐ Identify and assess the major technical and system integration risks of the critical technologies and key performance objectives of the program;

‐ Identify the major risk reduction tests and demonstrations required to validate the mission capabilities; and

‐ Define credible intermediate performance, including success metrics, schedule, and resources needed (funding, government furnished equipment (GFE), government furnished information (GFI), range, etc.).

Demonstration System Design

In parallel to the design of the Operational System(s), the performers will develop the design of the Demonstration System (DS). The DS design should be directly traceable to the OS concept design, but may require special considerations for early testing on the demonstration platforms (see export-controlled Appendix A for more details), including the DS software architecture, the demonstration command station, and any specialized payload(s) not already integrated in the GFE platforms that are required to demonstrate the selected collaborative behaviors and other autonomy algorithms.

(These payloads should not be developmental. They should be sufficiently mature to not add risk to the program and should only require minor modification to be integrated in the demonstration platform).

This task should start by deriving the requirements of the DS from the OS design and TMP. Six months after award (MAA), the performers should hold the DS Systems Requirements Review (DS-SRR) and DS-CoDR. Special consideration should be given to the need for the DS Command Station to interface with the simulation environment and allow the injection of simulated assets during live testing. The Government currently plans to provide two demonstration platforms in Phase 2 and up to six demonstration platforms in Phase 3 for flight testing (see Appendix A for details on demonstration platforms). Demonstrations may include additional flight test assets via simulation if the performer desires to demonstrate the ability to control a greater number of assets. In addition, the DS design approach should consider the Government’s desire to conduct rapid capability demonstrations in Phase 3 at six month intervals.

Nine MAA, the performers should hold an interim DS Design Review reflecting progress that has been made towards PDR since CoDR/SRR.

Fourteen MAA, the performers should hold the DS Preliminary Design Review

(DS-PDR).

OS- Open Architecture

An architecture featuring all the attributes enumerated above (Part II. Section I.D.4) is not available at this time (see Appendix D for more details regarding architectures reviewed). DARPA intends to define the CODE architecture during Phase 1 in a collaborative manner with a team led by the Government and leveraging the expertise of all the performers. The performers should take an active role in this activity and plan to implement the outcome in the DS during Phases 2 and 3. At a minimum, quarterly face-to-face meetings will be held in conjunction with the Track B TIM.

Additional meetings will be defined by team consensus and are likely to include frequent teleconferences.

3) Phase 2

Phase 2 will be a 12-month effort conducted by up to two performer teams selected among the Phase 1 Track A performers. It will be focused on the detailed design of the DS, including the DS-Critical Design Review (DS-CDR), the first software release, and initial flight tests. An updated TMP will be presented at the DS-CDR to provide updated risk reduction activities.

In Phase 2, the Track A performers will execute their Phase 2 TMP, implement an early version of the OS open architecture and merge the efforts of the Track B performers that they chose to include on their team (if any).

Performers should use best commercial practices for rapid software development, such as Agile methodology, and leverage the simulation environment developed in Phase 1 for frequent and progressive validation of the software.

Phase 2 will include the first software release that will be flight tested on the GFE platforms to validate its capabilities. It is envisioned that this software release will focus on single vehicle level autonomy (as defined in Part II. Section I.D.1) while continuing to develop the collaborative algorithms in the simulation environment.

Prior to flight testing, the performers should develop or adapt a hardware-in-the-loop test environment and complete comprehensive testing. Results from these tests will be presented at the Flight Readiness Review (FRR). Prior to the FRR, the performers should support coordination meetings with range authorities and platform providers.

Based on the results of their Phase 2 risk reduction activities, the performer should update their TMP for Phase 3. In parallel, the performers will continue to mature their CODE operational concept, incorporating any impacts from risk reduction results.

At the end of Phase 2, DARPA intends to select a single performer based on Phase 2 performance, including flight testing, remaining risks, and KPO.

4) Phase 3

Phase 3 will be an 18 month effort awarded to a single performer selected from the Phase 2 performers. It will be executed in accordance with the performer’s TMP. It should include multiple software releases to be flight-tested with increasingly more complete capabilities, culminating with a flight demonstration of the full mission capability for the selected mission. Capabilities related to additional missions should be demonstrated in simulation only. DARPA will provide up to six platforms outfitted with computing environment and communication subsystems supporting the selected architecture. The platforms will be equipped with performer selected payloads, which could be GFE or performer provided if the desired capability is not available (see export-controlled Appendix A for more details).

DARPA expects to conduct flight test events every four to six months during Phase 3. The last flight test series may be conducted on a different platform to prove portability, or to better match the operational system envisioned for the proposed OS.

5) Phase 1 Deliverables

All presentations shall be submitted no less than one full working day prior to the meeting.

Deliverable Due date Description Kick off meeting presentation

1 MAA Presentation that summarizes Phase 1 plan, highlighting changes made since proposal submission and describing a detailed plan for the first three months of Phase 1

OS-CoDR slides

3 MAA and updated at every major review

Presentation that defines the conceptual design of the proposed operational system(s) responsive to the missions and the results of any trade studies completed to validate the approach. It should include a feasibility analysis, a preliminary risk assessment, a functional analysis (top-level block diagrams), and a preliminary assessment of the design against the KPO and derived MoP.

MoP definition

Initial 3 MAA Final 6 MAA

Report or annotated briefing that explains the logic for selecting Measures of Performance and the methodology for calculating them

TMP Initial 6 MAA Updated quarterly

Report that defines the technology maturation plan and includes current risk assessment and progress on the risk waterfalls

TIM report <1 month after

TIM

Report or annotated briefing that summarizes findings and recommendations from Track B TIM

Trade studies

<1 month after completion of study

Report or annotated briefing that describes trades conducted, indicating which critical technology and KPO are impacted

Open Architecture Meetings

<1 month after meeting

Report or annotated briefing that documents findings and recommendations from the Open Architecture Meetings. This report should not contain any proprietary or competition sensitive information.

Transition plan

12 MAA Report or annotated briefing and presentation that detail the plan to rapidly and economically transition capabilities to warfighter

DS-

SRR/CoDR

6 MAA Presentation that details the conceptual design for the demonstration system with emphasis on the architecture, the software development plan, and any unique hardware required to emulate the operational capability.

The SRR should include a preliminary software development plan including V&V; preliminary software requirement specifications (functional and performance); and a requirement traceability matrix.

DS-Interim

DR

9 MAA Presentation that shows progress made towards PDR.

DS-PDR 14 MAA Presentation that details the preliminary design of the demonstration system and management plan (including budget and schedule) for Phase 2/3 explaining how program objectives will be met. Critical program documents should be summarized and available at the review including: released Software Development Plan including processes, tools, and metrics to measure progress; plan to facilitate integration of third party software; Released Software Requirement Specification down to the Computer Software Configuration Item (CSCI); and preliminary Interface Control Document.

Schedule Quarterly Integrated Schedule for Phase 1 with details for next three months

Phase 1 final report

Final 15 MAA Report that details all Phase 1 activities, capturing the top-level results of all technology trade studies, design performance analyses, and the design for both the operational and demonstration systems.

Progress report

Bi-weekly Teleconference to discuss progress over the last two weeks and upcoming events for the next two weeks.

Report may be accompanied by supporting file as needed.

Technical and financial status report

Monthly Report that provides updated technical, financial, and schedule updates. Report shall be delivered via e-mail or regular mail to DARPA directly and not merely placed in an online database.

G. Track B Program Plan

1) Overview

DARPA currently plans to provide direct funding for Track B only for Phase 1. It is desired that the selected Track B efforts are completed within 12 months of award to provide adequate time for collaboration with Track A performers and possible incorporation into their Phase 2 and Phase 3 plan and proposal.

The objective of Track B is to develop and mature critical enabling technologies in the areas described in Part II. Section I.D (single vehicle autonomy, collaborative autonomy, supervisory interface, and open architecture) that enable a Track A performer to meet the KPO identified in Section I.E.

Track B Performers should execute their proposed Technology Maturation Plan (see proposal format – Part II. Section IV.B.3) and mature the critical technology to a level that supports incorporation into a Track A system at the end of the Track B effort.

Maturation approaches may include simulation, HIL testing, laboratory experiments, and/or flight demonstrations.

DARPA anticipates that the output of these efforts is mostly algorithms and software, except possibly for the supervisory interface which may include a hardware component.

DARPA strongly encourages the Track B proposers to achieve the highest level of maturity for their technology possible by Month 12. Working prototypes, models, or test data are highly encouraged such that Track A incorporation in the Track A Phase 2 and 3 plan is feasible and low risk.

Close collaboration between the Track A and Track B performers will be critical to the program. To that end, Track B performers will be requested to present at quarterly Technical Interchange Meetings (TIM) held in the Northern VA area (Months 2, 5, 8, and

11) where the Track A teams and the Government team will be attending the technical presentations. Programmatic aspects of the program will be reviewed in private meetings with only the Government team in attendance.

Concurrent to the TIM, the Government will hold Open Architecture Meetings

(OAM). Participation of Track B performers in these meetings is important to facilitate incorporation of their critical technologies into Track A integrated efforts.

2) Deliverables

Deliverable Due date Description Kick off meeting presentation

1 MAA Presentation that summarizes the Phase 1 plan, highlighting changes made since proposal submission and detailing the first three months of Phase 1

TIM 3, 6, 9, 12

MAA

Briefing that presents technical achievements and plans.

Trade studies

<1 month after completion of study

Report or annotated briefing that describes the trades conducted, indicating which critical technology and KPO are impacted

OAM report <1 month after meeting

Report or annotated briefing that documents findings and recommendations from Open Architecture Meetings. This report should not contain any proprietary or competition sensitive information.

Schedule Quarterly Integrated Schedule for Phase 1, with details for the next three months

Final report Final 12 MAA Report that details all Phase 1 activities, capturing the top-level results of all technology trade studies, design performance analyses, and risk reduction activities.

Critical Technology Software module(s)

12 MAA Software module(s) that are required to implement the proposed critical capability and that are verified and ready for rapid integration into CODE OA.

Progress report

Bi-weekly Teleconference to discuss progress over the last two weeks and upcoming events for the next two weeks.

Report may be accompanied by supporting file as needed.

Test plan(s) > 2 weeks prior start of test

As required per TMP. Report that defines test objectives, approach, and quantitative success criteria.

Test report(s)

< 1 month after test

Report that documents the results of any test performed, including major findings and comparison of results to expected outcome.

Technical and financial status report

Monthly Report that provides updated technical, financial, and schedule updates. Report shall be delivered via e-mail or regular mail to DARPA directly and not merely placed in an online database.

II. Award Information

A. Number of awards

Multiple awards are anticipated for Phase 1 Tracks A and B. The amount of resources made available under this BAA will depend on the quality of the proposals received and the availability of funds. Track A efforts are expected to be allocated between $3,000,000 and $4,500,000. Track B efforts are expected to be allocated between $400,000 and $700,000 per award.

The Government reserves the right to select for negotiation all, some, one, or none of the proposals received in response to this solicitation, and to make awards without discussions with proposers. The Government also reserves the right to conduct discussions if it is later determined to be necessary. If warranted, portions of resulting awards may be segregated into pre-priced options. Additionally, DARPA reserves the right to accept proposals in their entirety or to select only portions of proposals for award.

In the event that DARPA desires to award only portions of a proposal, negotiations may be opened with that proposer. The Government reserves the right to fund proposals in phases with options for continued work at the end of one or more of the phases.

Awards under this BAA will be made to proposers on the basis of the evaluation criteria listed below (see section labeled “Application Review Information”, Sec. V.), and program balance to provide overall value to the Government. The Government reserves the right to request any additional, necessary documentation once it makes the award instrument determination. Such additional information may include but is not limited to Representations and Certifications. The Government reserves the right to remove proposers from award consideration should the parties fail to reach agreement on award terms, conditions and cost/price within a reasonable time or the proposer fails to provide requested additional information in a timely manner. Proposals identified for negotiation may result in a procurement contract, grant, cooperative agreement, or other transaction, depending upon the nature of the work proposed, the required degree of interaction between parties, whether or not the research is classified as Fundamental Research, and other factors.

In all cases, the Government contracting officer shall have sole discretion to select award instrument type and to negotiate all instrument terms and conditions with selectees. Proposers are advised that if they propose grants or cooperative agreements, the Government contracting officer may select other award instruments, as he/she deems appropriate. DARPA will apply publication or other restrictions, as necessary, if it determines that the research resulting from the proposed effort will present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Any award resulting from such a determination will include a requirement for DARPA permission before publishing any information or results on the program. For more information on publication restrictions, see the section below on Fundamental Research.

B. Phase 1, Phase 2, and Phase 3 proposals and awards

Proposers shall prepare Phase 1 proposals in accordance with the proposal format instructions detailed under Section IV. Track A performers should ensure that their Phase 1 proposals take into account all deliverables listed under Part II Section I.F.5 of this BAA, and Track B performers should ensure that their Phase 1 proposals take into account all deliverables listed under Part II Section I.G.2 of this BAA.

Prior to PDR during Phase 1, the Government will request Phase 1 Track A performers to update and expand their proposals to include Phases 2 and 3. Track A performers will be strongly encouraged to incorporate Task B technologies in their system design. It is anticipated that proposals will be due by the PDR timeframe and that the PDR technical data will be part of the technical evaluation. The proposal will also include detailed system development plans, costs and schedules. Detailed proposal guidance will be provided two months prior to PDR.

Submission of proposal for Phases 2 and 3 is optional and associated proposal preparation costs will not be reimbursed under Phase 1 awards. The decision to continue the program into Phases 2 and 3 is the prerogative of the Government and will be based upon availability of funds, the determination that performers have made sufficient progress towards meeting program performance objectives, maturing the required technologies and addressing risks, and scientific review of the proposals. Evaluations of Phase 2 and 3 proposals will be based on evaluation criteria to be specified in the proposal request and will include consideration of Phase 1 performance.

C. Fundamental Research

It is DoD policy that the publication of products of fundamental research will remain unrestricted to the maximum extent possible. National Security Decision Directive (NSDD) 189 established the national policy for controlling the flow of scientific, technical, and engineering information produced in federally funded fundamental research at colleges, universities, and laboratories. The Directive defines fundamental research as follows:

'''Fundamental research' means basic and applied research in science and engineering, the results of which ordinarily are published and shared broadly within the scientific community, as distinguished from proprietary research and from industrial development, design, production, and product utilization, the results of which ordinarily are restricted for proprietary or national security reasons."

As of the date of publication of this BAA, the Government expects that program goals as described herein either cannot be met by proposers intending to perform fundamental research or the proposed research is anticipated to present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Therefore, the Government anticipates restrictions on the resultant research that will require the contractor to seek DARPA permission before publishing any information or results relative to the program.

Proposers should indicate in their proposal whether they believe the scope of the research included in their proposal is fundamental or not. While proposers should clearly explain the intended results of their research, the Government shall have sole discretion to select award instrument type and to negotiate all instrument terms and conditions with selectees. Appropriate clauses will be included in resultant awards for non-fundamental research to prescribe publication requirements and other restrictions, as appropriate.

Fo…