HR001118S0043-Amendment-01.pdf

Broad Agency Announcement

Adapting Cross-Domain Kill-Webs (ACK)

STRATEGIC TECHNOLOGY OFFICE

HR001118S0043

Amendment 01

August 03, 2018

The purpose of this amendment is to make revisions to language in the following sections, which are highlighted in yellow throughout the document.

Part I. Overview Information, page 3

Part II.I.B.2.a) Task 1, page 12

Part II.I.B.2.b) Task 2, page 13

Part II.III.D. Other Eligibility Criteria, page 23

Part II.IV.B.2.a)(3)B. Section III: Detailed Proposal Information, page 27

TABLE OF CONTENTS

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

A. Program Goal B. Program Overview C. Schedule and Deliverables D. Program Metrics

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 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 of Proposals

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

VII. Agency Contacts VIII. Other Information

IX. APPENDIX 1: PROPOSAL SLIDE SUMMARY

X. APPENDIX 2: VOLUME 1 COVER SHEET TEMPLATE

XI. APPENDIX 3: VOLUME 2 COVER SHEET, CHECKLIST AND SAMPLE

TEMPLATES

PART I: OVERVIEW INFORMATION

Federal Agency Name – Defense Advanced Research Projects Agency (DARPA), Strategic Technology Office (STO) Funding Opportunity Title – Adapting Cross-Domain Kill-Webs (ACK) Announcement Type –Initial announcement.

Funding Opportunity Number – HR001118S0043 Catalog of Federal Domestic Assistance Numbers (CFDA) –Not applicable.

Dates o Posting Date July 20, 2018 o Proposers Day: July 27, 2018 o Teaming Profiles Due: August 3, 2018 o Abstract Due Date and Time: August 17, 2018, 4:00PM Eastern o Last date to request instructions to submit classified proposal material: August

31, 2018 o FAQ/Questions Due Date: September 10, 2018, 4:00PM Eastern o Proposal Due Date and Time: September 28, 2018, 4:00PM Eastern

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

Funds Available (total per phase) o Phase 1 (18 months): $14.3 million o Phase 2 (18 months): $16.2 million o Phase 3 (12 months): $7.2 million

Anticipated individual awards: Multiple awards are anticipated for Task 1 (Technology Development). A single Task 2 (Evaluation) performer is expected.

Proposers that propose to Task 2 may not submit a proposal for Task 1. Proposers may propose to both Task 1 and Task 2, with evidence and justification that the two efforts are sufficiently free of any conflict of interest.

Agency contact The BAA Coordinator for this effort can be reached at:

electronic mail: HR001118S0043@darpa.mil.

Or USPS mail:

DARPA/STO

ATTN: HR001118S0043

675 North Randolph Street Arlington, VA 22203-2114 mailto:HR001118S0043@darpa.mil

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 to assist military decision-makers with rapidly identifying and selecting options for tasking – and retasking – assets within and across organizational boundaries. While the technology developed for this program will apply at both the tactical and operational levels, ACK will focus on providing support for tactical decisions. Specifically, ACK will assist users with selecting sensors, effectors, and support elements across military domains (space, air, land, surface, subsurface, and cyber) to form and adapt kill chains to deliver desired effects on targets.

Emphasis will be on the cross-domain challenges of the problem. Proposed research should investigate innovative approaches that enable revolutionary advances. Specifically excluded is research that primarily results in evolutionary improvements to the existing state of practice.

A. Program Goal

DARPA is developing a new a warfighting concept called Mosaic Warfare, and is investing in technologies to make Mosaic Warfare a reality. At the core of the vision are “system of system” architectures that distribute capabilities across manned and unmanned platforms throughout the battlespace. Warfighters will compose novel kill-chains from these distributed capabilities (the kill web)1 - no longer having to rely on fixed exquisitely engineered kill chains - presenting multiple dilemmas to our adversaries. To enable this future vision, tools (software decision aids) are needed to support the real-time allocation of systems to specific instantiations of kill-chains and to adapt this allocation as the combat situation changes. This must be accomplished for many concurrent operational objectives being undertaken by warfighters across all domains, selecting kill web elements from a shared pool of resources. The goal of the Adapting Cross- Domain Kill-webs (ACK) program is to address this need.

The Services fully embrace the need for cross-domain operations – e.g., the Army’s Multi- Domain Battle (MDB) concepts and the Air Force’s recent focus on Multi-Domain Command and Control (MDC2). Unfortunately, today’s C2 organizations and processes cannot support these new warfighting concepts, especially during joint operations. The Services partially coordinate across domains today when planning missions, but heterogeneous planning and control cells across domains follow manually intensive processes that limit the effectiveness of multi-domain operations. Therefore, coordination is limited, it takes too long to adjust support relationships, and decision makers have little to no ability to develop options, let alone compare them. The end result tends to be static allocation of resources to specific missions, leading to

1 Here we use the nomenclature that a “kill-web” is the full collection of all capabilities, i.e. the Mosaic, and a “kill-chain” is one specific instantiation to deliver an effect.

operational inefficiency. Since no commander knows at the beginning of a campaign how the battle is going to develop, statically allocated assets may go under-utilized, while others are over-burdened and cannot complete their missions.

ACK will address this challenge by utilizing a decentralized approach to allocating resources to tasks and assigning mission orders to assets, motivated by ideas developed in online commerce, sourcing, and supply chain management. The overall approach developed under ACK will apply at both the tactical and operational levels of battle management and C2. The focus of the program will be on the more dynamic tactical problem, identifying options and adapting joint multi-domain kill-webs during mission execution. It is expected that decision timelines will be on the order of minutes, and the output of ACK will be the selection of the elements of a kill-chain and assignment of roles and responsibilities to each of the elements. Specifically not in scope for ACK are algorithms and software to manage the low-level execution of the assigned tasks (e.g., routing, payload scheduling, etc.).

Figure 1 – In the Mosaic Warfare vision, manned and unmanned platforms across all domains collaborate to form kill-webs and present multiple dilemmas to the adversary.

Figure 1 illustrates some of the key concepts of Mosaic Warfare – manned and unmanned platforms and payloads interoperating and collaborating across domains to form kill-chains and present multiple dilemmas to the adversary. Every platform in the battlespace could offer services to support the formation of a kill-chain, e.g. sensors, weapons (kinetic and non-kinetic), communications, battle management services, etc. As the situation evolves and, say, a new target emerges, the goal of ACK is to support the operators with identifying relevant capabilities that could support them, and then negotiating the use of those capabilities to form an effective cross-domain kill-chain. This must be done is such a way that new needs are balanced with execution of on-going mission orders, and that the joint commander’s objectives are being addressed in a way that most efficiently and effectively utilizes the resources available and within acceptable risk tolerances. It must also take into account that some resources “owned” by a particular Service, unit, or tactical commander may temporarily be tasked to support some other warfighter’s joint mission objective.

To make the goals of ACK more concrete, consider a vignette in which an aircraft detects a target tracking radar (TTR) emission. Based on rules of engagement and mission priorities, the pilot decides that the radar should be destroyed in order to ensure the success of on-going missions (or perhaps the mission was to find and destroy integrated air defenses). The pilot, in the role of consumer, must find what resources are currently available in the battlespace that could support a kill-chain for the destruction of the TTR, and then once identified, must decide which to use. The candidate capability providers, or “suppliers”, when asked to support this particular kill-chain, must determine to what extent they can support the request and whether they should in the context of on-going missions. Figures 2 and 3 illustrate two possible kill-chains that could achieve the objective of eliminating the TTR.

Figure 2 – TTR kill-chain option #1

Both options as shown in Figures 2 and 3 may be available and feasible – but which is “best” will depend on many factors. On the supply side, each supplier must decide whether they have the capacity and can meet the quality of service and timeline demands (among other things).

Further, they have to consider the implications in the context of their other on-going missions.

On the consumer side, the goal is to select the option that provides the highest probability of achieving the mission objective, executes in an acceptable time window, assumes an acceptable level of risk, and is least disruptive to other missions. Clearly, there are multiple competing objectives at play, and for ACK to be successful, it must address this challenge not just for a single engagement, but for multiple consumers operating in parallel. ACK will address the challenge of building a framework to trade off and reason over these objectives.

Figure 3 – TTR kill-chain option #2

Consider Figure 4 in which space assets detect another emitting target, further complicating matters in the vignette. A command and control cell receiving the detections from the space constellation, following its own commander’s guidance, authorities, and the rules of engagement, makes the decision to form a kill-chain to destroy this target. Many of the same suppliers within the battlespace are candidates for the new kill-chain. The example highlights the potential challenges of resource contention across multiple consumers in the face of scarce “supply”.

There are challenges related to both cost and benefit for both consumers and suppliers.

Figure 4 – A new target is detected and a new kill-chain must be formed competing for the same resources within the battlespace.

There are three major technical challenges to realizing the ACK goals. First, in real-time (and at planning time), planners and operators have little or no insight into what capabilities are available across domains and what capacity they may be able to offer. Second, within each domain, commanders task their capabilities to service their own missions, making it challenging to trade off the “value” or “cost” of supporting new missions originating from another domain versus their own current set of missions2. Third, given a set of cross-domain kill-chain options, a mechanism is needed to support meaningful comparison of the diverse options and to select the “best” (as determined by a multi-objective optimization problem factoring the values and costs discussed above, the expected effectiveness of the kill-chain options, risk, etc.).

ACK will enable multiple warfighters to define distributed effects and adapt them at up to combat speed using a shared set of resources. This will create greater lethality by pairing the right sensor and weapon together for a given target and operational problem. This will create greater resilience by enabling rapid substitutions if a capability is lost. It will produce greater efficiency by enabling better sharing of resources across domains and Services to balance tasking loads.

Further, ACK technology could help with the protection of sensitive capabilities by allowing service providers to offer capabilities across domains in terms of the effects they can provide, without exposing any details regarding how those effects will be achieved (i.e. without revealing sources and methods). If the program is successful, the technology developed under ACK will be an important enabler for the new joint multi-domain concepts that the Services are pursuing at both the operational and tactical levels.

B. Program Overview

1. ACK Approach and Challenges The ACK program will develop a decentralized framework to match suppliers that offer capabilities (sensing, weapons, non-kinetic effects, communications, etc.) in any domain to consumers (entities with operational mission objectives and the authority to build kill chains).

While the successful deployment of distributed marketplaces in the world of E-commerce motivates the ACK program, new technologies are required in order to use these approaches to support military decision-making. Specifically, commercial approaches heavily leverage the simplifying power of currency, which provides a tangible, common “value-function” that can be used by all parties to express costs and preferences. This is highly problematic in a military context. Motivated by the success of electronic marketplaces, DARPA is seeking to develop a means of efficiently connecting warfighters in need of support with other warfighters with the ability to provide that support without relying upon bidding mechanisms built around the use of a common currency (or static, doctrinal force structure and resource allocation).

The key insight of the ACK program is based upon the observation that there already exist processes for coordinating across domains using human liaisons. While slow and inefficient, 2 ACK will not address or be limited by potential doctrinal or cultural barriers that may currently exist, but ACK will provide new technology options that could help policy and doctrine makers build confidence with this new concept for warfighting.

these human-centered processes do not rely upon the use of currency. The fundamental hypothesis of the program is that modern representational and reasoning capabilities may be leveraged to create virtual liaisons that will be both faster and more rigorous than their human counterparts.

Borrowing an analogy from operational level C2 of the air domain (as implemented in today’s Air Operations Centers) where onsite liaison officers represent other domains and services, ACK will develop software agents called “virtual liaisons”. Virtual liaisons will represent sets of suppliers (capabilities) as appropriate for the operational domain. Conceptually, a virtual liaison may represent a wide variety of entities, from a broad agency level, such as a space constellation’s ground operations enterprise, all the way down to the single payload level, such as a sensor on an unmanned air platform. To build an effects chain, C2 nodes (consumers) present their operational objectives (service needs) to suppliers through the virtual liaisons to negotiate the use of services to achieve effects.

Figure 5 – Overview of the ACK framework for decentralized construction of kill-chains.

Figure 5 illustrates the ACK framework and process for the decentralized construction of kill-chains. The figure focuses on one particular decision maker (consumer) – the fighter pilot from the earlier vignette. Consistent with the program focus, the context is military decision-making.

The specific details of the engagement are not as important as the fact that the pilot must make decisions in a complex environment with limited knowledge about the situation across the battlespace. Typically, there will be a large set of on-going missions, and the decision maker will only have detailed knowledge of a small set of them. These missions are executing as a part of a larger plan, which was developed in accordance with and at the direction of, a joint commander to whom the decision maker reports.

In this illustrative vignette, the process is triggered when an event occurs requiring the formation of a new kill-web – e.g., a new target is detected. Following the decision to prosecute the target, ACK will present the decision maker with a set of potential “plays”, i.e. high-level templates for classes of kill-chains that might be formed to address the target (e.g., kinetic versus non-kinetic).

The plays will specify all the information required to form a kill-chain, i.e. the elements required, quality of service required from each, etc. It is important that the plays not over-specify the elements of the kill-chain, though – they should be as general as possible, leaving ACK more freedom to source the elements widely and to be as flexible as possible with the type of effect used and the approach for delivering it. That is, they should not specify specific sensor classes, weapon types, communication networks, etc., instead, specifications should be in terms of desired effects, quality of service, etc.

Once the operator selects a play (or multiple plays), ACK will transmit “bid requests” to the virtual liaisons throughout the battlespace (Step #3 in Figure 5) for each of the classes of service needed across the selected plays. At this point the virtual liaisons will have to decide whether they have resources available that could service the specific request and at what “cost” (making cost meaningful in the cross-domain Mosaic Warfare context is a key challenge for the ACK program). The virtual liaisons return “offers” (Step #4) to the consumer node, at which point the consumer node will adjudicate the offers in the context of the selected play(s) and form the “best” kill-chain (defining what it means to be the “best” kill-chain is another key challenge).

The process as shown in Figure 5 is a suggestion – proposers are encouraged to offer alternative approaches (for example, the “negotiations” represented by Steps 3-4-5 in the figure could be iterated, though bandwidth and the challenges of contested communications should be considered). Finally, multiple consumers within the battlespace competing for the same resources introduces additional challenges, and ACK should address these.

The key technical challenges that the ACK program needs to address in order to realize this objective include:

Creating the ability for suppliers to represent their capabilities, and for consumers to describe their requirements in a way that supports both the rapid identification of potential solutions to operational needs and the expeditious exploration of the costs, benefits and constraints of potential solutions. These representations should be general enough that they could be expanded to a wide range of asset and mission classes, while flexible and adaptive to accommodate new assets and missions not yet conceived.

Implementing virtual liaisons that can use these representations to identify the most promising suppliers (in the case that the virtual liaison represents more than one supplier)

– and “supply chains” (in the case that multiple entities are required) – available to achieve a requested effect or execute a requested task. The virtual liaison should fill out as many details as possible regarding quality of service, timeline, etc., before presentation to decision makers (“consumers” / C2 nodes).

Enabling the rapid and effective comparison of diverse options and making recommendations for the acceptance of offers, the allocation of the selected capabilities to a recommended play, the plan to execute the play, and the resulting assignment of tasks back to selected services.

2. ACK Program Structure The ACK program will consist of two major tasks: technology development (Task 1) and evaluation (Task 2). The Task 1 performers will develop end-to-end solutions that address all of the major challenges described above.

a) Task 1 Task 1 performers will

Develop a framework for capability representations necessary to support the ACK program concept and populate them consistent with the scenarios developed by the Task 2 performer. This will include the ability to represent capabilities in sufficient detail to allow the C2 node to reason over alternatives (e.g., quality of service, availability timelines, likelihood of success, etc.). This will also include the ability for users to construct a library of kill-chain “plays” (and the software for managing and interacting with them) – i.e. possible high-level (not overly prescriptive) approaches to achieving a desired effect on a target class. DARPA is not interested in a proposer’s ability to build “good” plays - experts can do that after the technology is developed and proven. DARPA is interested in proposals that offer the ability to construct such playbooks quickly, especially if subject matter experts can do it quickly and easily. For example, the ability to construct plays on mission planning timelines utilizing a “DevOps”-style methodology.

Develop the bid request and offer language and message sets for C2 node / virtual liaison coordination across domains to attempt to fill out all of the roles for a chosen kill-chain “play”. DARPA is looking for proposals allowing users to describe rapidly the requirements, constraints, limitations, etc. of particular techniques so that the virtual liaisons can assign a cost.

Develop the supplier-side virtual liaison offer generation algorithms and software for adjudicating bid requests (which includes the decision whether or not to make an offer), as well as the algorithms to accept a commitment and shuffle the current commitments for a specific resource. This valuation should take into account not just overall capacity and capability of the asset but also its current tasking. The valuation should be dynamic and take into account the time window for services requested in the bid as compared with the capability’s existing orders and projected future loading predicted at the requested bid time.

Develop the consumer-side C2 node algorithms and software for adjudicating amongst the offered capabilities in order to select the “best” kill-chain composed of the offered resources. This should include both ACK-specific algorithms for developing recommendations based upon a set of offers, as well as technical analysis capability that can score the offers and resulting plays against the original mission objective.

While the emphasis is not on sophisticated Human-Machine Interfaces, develop a supporting user interface that enables an operator the ability to visualize options and recommendations and select a final plan.

Task 1 performers will deliver software agents (C2 nodes and virtual liaisons) to run independently for each “node” in a simulation infrastructure developed by the Task 2 performer (the evaluator). For ACK purposes, proposers can assume the existence of a channel whose capacity is consistent with today’s tactical data links (e.g., Link-16) for passing bid and offer messages.

A risk for Task 1 performers is that they will not be able to develop sufficiently rich and general plan templates (or plays) for kill-chain construction and a language for requesting effects in a way that could be satisfied by a wide variety of capabilities across domains. If the plays and requests are too narrow, the set of feasible cross-domain kill-chains may be small and show little improvement over the baseline. Approaches should allow subject matter experts to quickly develop and edit plays on mission planning timelines. Further, request mechanisms should be framed in terms of desired effects and not overly prescriptive.

Multiple Task 1 performers are expected. Proposers that propose to Task 1 may not submit a proposal to Task 2.

b) Task 2 The evaluator (Task 2) is a critical role on ACK. The quality of evaluations will only be as good as the quality of the scenarios and supporting models provided by the evaluator. The Task 2 performer will:

Define multi-domain scenarios and the test plan for each evaluation event. These scenarios need to be representative in the sense that they reflect the need to make time-critical decisions across a variety of military domains, but “realism” in the sense of accurate representations of existing systems is not essential for assessing the ability of ACK technologies to support decision-making. Scenarios MUST be unclassified, and DARPA security will review them prior to release to the larger ACK community.

Create multi-domain capability models as digital artifacts, along with supporting documentation, and share them with the Task 1 performers. Again, the intention of this item is NOT to achieve high levels of realism and/or accurate details. Task 1 technologies need to be model driven and the Task 2 provider will have to support this need, using unclassified models that DARPA security will review prior to use.

Supply the evaluation test bed.

Conduct the evaluations; analyze data, reports out on results.

Ensure fair comparison between competing Task 1 performer capabilities.

Evaluating the ability of C2 applications to improve military effectiveness typically requires the use of simulations that model the dynamics of military engagements, and DARPA expects the Task 2 performer to leverage existing modeling and simulation (M&S) capabilities for this purpose. However, most currently existing mature M&S capabilities are single-domain focused, with other domains represented at low fidelity (only where the other domains intersect with the primary domain). For this reason, DARPA expects the Task 2 performer will need to extend or integrate single-domain simulators to build a multi-domain testbed sufficient for ACK evaluations in Phase 2.

Evaluations in a simulated battlespace are not required in the Phase 1 test bed. Given the ACK program focus upon cross-domain coordination, DARPA wants to ensure that Phase 1 does not limit evaluations to a single domain that is well-supported by M&S. In order to support this goal, and given the assumption that realistic multi-domain simulations are going to take time to acquire and develop, DARPA expects that during Phase 1, the Task 2 performer will conduct static model-based evaluations of kill-chain assignments as produced by Task 1 performer prototypes. DARPA expects Task 1 applications to take as inputs digital representations of the battlespace, including its current state. Rather than being evaluated in simulation, Task 2 subject matter experts may evaluate the outputs of these applications by using appropriate tools.

Proposers to Task 2 must clearly describe their approach to developing multi-domain scenarios in a way that can credibly meet the program schedule and objectives.

Task 2 is critical to the success of the ACK program and offers significant challenges of its own.

There are two primary risks for Task 2. First, there is a risk that the Task 2 performer will not be able to construct sufficiently rich scenarios to enable fair evaluation of the Task 1 performer solutions. Second, developing the M&S-based testbed with sufficient fidelity for meaningful evaluation is potentially a large task and a major risk. Success will require leveraging existing capability and careful management of scope. DARPA expects the Task 2 performer to integrate and extend existing simulations and represent cross-domain capabilities with just enough fidelity to accomplish the goals of the ACK program evaluations.

Task 1 performers will integrate with the evaluation testbed using Task 2 performer-provided application programmers interfaces (APIs). All performers (Task 1 and Task 2) will participate in the definition of the APIs through team-wide working groups run by the ACK government team (starting from an initial API definition proposed by the Task 2 team).

A single Task 2 performer is expected. Proposers that propose to Task 2 may not submit a proposal for Task 1.

Figure 6 – The ACK program will consist of two major tasks conducted over three phases.

Figure 6 depicts a high-level schedule for the anticipated four-year (three phase) ACK program.

Phases 1 and 2 will emphasize the tactical battle management problem, moving from static evaluation of recommendations in Phase 1, to dynamic evaluations in the Task 2-developed M&S-based testbed in Phase 2. The government expects to carry multiple competing Task 1 performers through Phase 2. Pending an agreement with the Air Force, in Phase 3 the emphasis will shift to operational-level C2 (with a single Task 1 performer) in anticipation of a capstone demonstration in support of Air Force Multi-Domain Command and Control (MDC2) objectives.

3. ACK Program Phasing

a) Phase 1

ACK Phase 1 will last 18 months, with two evaluations tentatively planned for the 9th month and the 17th month of the Phase. Working in conjunction with the government and informed by the Task 1 teams, the Task 2 will develop and document details of the evaluations. Both Phase 1 evaluations will be “static” in the sense that they will be assessed by human experts working for and with the Task 2 contractors and will not be evaluated in a simulated environment.

In order to allow the Task 1 technology developers to prepare for evaluations, the Task 2 proposer will need to provide specific details of the evaluations (e.g., input data types and formats, expected outputs, scoring methodologies, metrics, etc. and examples) to the Task 1 contractors well in advance of the events. The Task 2 contractor should provide this information to the Task 1 teams as soon as possible, but in no case later than five full months before the scheduled evaluations. In addition, the high-level details (e.g. domains, capabilities, vignettes) need to be reviewed and approved by DARPA management with sufficient lead-time to account for feedback and guidance from the government.

Task 2 proposals need to include sufficient detail regarding the high-level details of the scenario being planned for the first evaluation event to allow the government to provide initial feedback at the kick-off meeting. Another review of the plans for the first evaluation will be made at month 3 of the phase, with the expectation that final details will be provided to all program participants in month 4. As Task 1 teams use this information to prepare for the first evaluation, the Task 2 team will turn its attention to preparing for the second evaluation, with a target of presenting the high-level plans for initial review during the sixth month of the program. Task 2 proposals should clearly explain their basis of confidence for being able to meet these targets.

In Phase 1, Task 1 performers will begin development on all of the functionality outlined in Section 2 above. Table 1 lists key program metrics for Phases 1 and 2. The government expect Task 1 performers to conduct rigorous internal evaluations of their software during this Phase.

DARPA expects to incorporate concepts developed for these internal assessments as they work with the Task 2 performer to develop additional metrics to facilitate assessment of technical progress throughout the life of the program.

In addition to developing evaluation plans and conducting evaluations during Phase 1, the Task 2 performer will implement the evaluation testbed that they will use to conduct evaluations during Phases 2 and 3. Task 2 proposals should provide a clear and compelling basis for confidence that the proposer can provide a usable capability by the start of Phase 2. Proposals should also explain how the Task 2 performer will make the testbed environment available to Task 1 teams for development and testing purposes. DARPA has a strong preference for high levels of high-quality access. If a proposer plans to provide testbed access over a wide-area network (e.g., the Internet), they must clearly state their company’s policy with respect to providing access to the testbed to other ACK performers and explain how this will not be a hindrance to development and test efforts.

b) Phase 2 Assuming satisfactory technical progress against the program metrics, the government expects all performers to carry on from Phase 1 to Phase 2. ACK Phase 2 will also last for 18 months, but it will contain three assessment events, spaced roughly six months apart. During this phase, evaluations will shift to using the simulation-based testbed developed by the Task 2 contractor.

The first planned program-wide assessment will be an “integration event,” which will be conducted by the Task 2 contractor to ensure that Task 1 performers are able to integrate into the testbed environment and supply the data required by the Task 2 team to collect performance metrics. The Task 2 teams will supply details of this event to the Task 1 performers no later than the third month of ACK Phase 2. DARPA expects the Task 1 performers to continue to conduct internal technical assessments during Phase 2.

The second and third assessments conducted in Phase 2 will be formal evaluation events, focused upon the ability of Task 2 teams to achieve – and exceed – the metrics listed below in Table 1, as well as any other metrics identified by the government during the program. As in Phase 1, DARPA expects the Task 2 performer to provide evaluation details no less than five months in advance of an evaluation event, with preliminary reviews by the government taking place roughly six months before each test (allowing time to incorporate feedback from the government prior to delivery 5 months in advance). In addition, the simulation software used in the testbed will be “locked down” (feature complete) no less than three months before the first two assessment events. Code for the final evaluation of this phase will be feature complete five months before the event, which will be held at roughly the seventeenth month of the phase.

c) Phase 3 Prior to the start of this phase, and based upon the results of the evaluations conducted during Phase 2, DARPA will decide to exercise the Phase 3 option of one of the Task 1 contractors to proceed to Phase 3. Assuming satisfactory progress, DARPA expects the Task 2 performer to continue to Phase 3. Phase 3 will last 12 months and culminate in a capstone demonstration to potential military adopters in a still-to-be-determined venue, leveraging the ACK testbed capabilities.

DARPA expects the primary efforts of the Task 2 team to focus upon designing and implementing the demonstration scenario, based upon direction from the government and interests of the potential adopters. This will likely include installing the testbed software in a third-party facility and adapting scenarios developed by other military organizations for purposed of demonstrating the impact of ACK technology.

In addition to incorporating new models for the Phase 3 capstone scenario, the Task 1 performer will focus technology development during this phase on usability by military personnel. This should include both support for end-users (e.g. “suppliers” and “consumers”) and support for model developers / potential adopters who will need to be able to extend ACK capability models in the field as new capabilities come online.

C. Schedule and Deliverables

Technical Deliverables MAC Event Location T1 - Tech T2 – Eval

1 Phase 1 Kick-off Team Program Plans w/ Emphasis on Phase 1

3 Design Review Performer Algorithm & system design for Eval #1

-Eval #1 scenarios, models, & testbed overview -Test Plan for Eval #1

6 Quarterly Rev Team Status and plans 9 Evaluation #1 Performer Deliver software to T2 Report of Eval #1

12 Design Review Performer Algorithms & system design for Eval #2

-Eval #2 scenarios, models, & testbed -Test Plan for Eval #2

15 Quarterly Rev Team Status and plans -Status and plans -Design review for Phase 2 M&S testbed

Ph as e

18 Evaluation #2 Performer Deliver software to T2 Report of Eval #2

19 Phase 2 Kick-off Team Program Plan w/ Emphasis on Phase 2

-Program Plans w/ Emphasis on Phase 2 -Integration Schedule

21 Design Review Performer -Algorithm review -System design for integration test

-Eval #3 scenario and models

- Testbed sim code feature complete -Test Plan for Integration Test

24 Integration Test Team Deliver software to T2 Report on integration testing

27 Design Review Performer Status and plans -Status and plans -Test Plan for Eval #3

30 Evaluation #3 Team Deliver software to T2 -Report of Eval #3 -Testbed sim code feature complete

33 Design Review Performer Status and plans -Status and plans -Test Plan for Eval #4

Ph as e

36 Evaluation #4 Team Deliver software to T2 -Report of Eval #4 37 Phase 3 Kick-off Team Phase 3 Program Plans 39 Quarterly Rev Performer Initial concepts for Capstone Demo 42 Design Review Team Final design of Capstone Demo

45/46 Dry Run Team Final code integrationPh as e

47/48 Capstone Demo Team Capstone Demo

The table above summarizes key events and deliverables. At the design reviews, Task 1 performers will be expected to review the algorithms they plan to implement for the next formal evaluation (or capstone in Phase 3), and the Task 2 performer will be expected to review the test plan for the next formal evaluation (or demo plan for the capstone in Phase 3). The Task 2 performer will host evaluations in order to evaluate Task 1 software. For the location column below, “Team” indicates that all of the performers will come together at a single location, designated by the program office, to present/share their deliverables. “Performer” in the location column indicates that the program office will travel to each performer’s location to review the deliverables.

D. Program Metrics In order 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 program metrics in Table 1 that may serve as the basis for determining whether satisfactory progress is being made to warrant continued funding of the program. Although the following program metrics are specified, proposers should note that the government has identified these goals with the intention of bounding the scope of effort, while affording the maximum flexibility, creativity, and innovation in proposing solutions to the stated problem.

The government will use the metrics in Table 1 to assess the algorithms and prototypes developed by the Task 1 performers during each of the evaluation events (as constructed by the Task 2 performer). As with any experiment to evaluate progress on the development of battle management command and control decision aids, reaching specific targets is not possible without a sufficiently rich set of scenarios on which to evaluate the algorithms. Specifically, the scenarios must be built in such a way that a variety of cross-domain solutions are available for any given event (in order to test the algorithms ability to find and select the “best” option), and the scenarios should be dense with on-going missions (presenting resource management challenges).

Metric Phase 1 Goal Phase 2 Goal

Number of domains 3 4

Number of feasible recommendations > 1 > 3

Relative effectiveness of recommendations (e.g., # pop-up targets successfully prosecuted relative to baseline)

50% improvement 100% improvement

Avg. ratio dropped missions / dropped missions in baseline

< 1 < 0.5

Max. processing time to generate recommendations

< 3s < 3s

Scalability (# consumers / # suppliers) 3 / 50 5 / 100

Table 1 – ACK program metrics

Metric Observations:

The “number of domains” (drawn from, e.g., air, space, land, maritime, cyber) metric is intended to drive the exploration of a variety of cross-domain challenges.

Assuming the scenario is sufficiently rich, the ACK algorithms should be able to discover and form multiple kill chain options, as measured in “number of feasible recommendations.”

Mission effectiveness of kill chain recommendations is operationally critical and ACK approaches should find options that are at least as good as options constructed manually (as is done today) – “relative effectiveness of recommendations” will measure the ACK approaches’ improvement in mission effectiveness over baseline. For example, in a scenario testing ACK’s ability to prosecute pop-up targets, the number of targets successfully prosecuted indicates absolute mission effectiveness, and in this case, the relative mission effectiveness is the percentage improvement in number of targets prosecuted over the manual baseline.

It is important that ACK solutions (recommended kill chains) are constructed in such a way that is minimally disruptive to on-going missions – this will be measured as the ratio of the average number of dropped missions using ACK to the average number of dropped missions using a baseline approach. This metric is to accommodate the need to minimize disruption to baseline missions and standing orders.

Given the tactical nature of the problem, it is desirable that computation time not be a bottleneck – “maximum processing time to generate recommendations” will specifically measure CPU time (assuming a tactical edge class processor – specifics to be determined) for the ACK algorithms to generate a kill chain recommendation. This metric does not include delays introduced by the data links.

Finally, “scalability” assesses the ability of the solutions to handle scenarios with a large number of options to consider, and multiple “competing” consumers, within the processing time goals.

In Table 1, several of the metrics require comparison to a baseline. The Task 2 performer (evaluator) will define a baseline approach inspired by today’s practice of defining fixed support relationships and mission priority schemes.

Table 1 does not specify metrics for the Phase 3 capstone demonstration. The government expects the Task 2 performer to work with potential transition partners to define acceptable performance criterion and a context in order to evaluate the Task 1 prototype for suitability to transition.

II. Award Information

A. General Award Information

DARPA anticipates multiple awards. The amount of resources made available under this BAA will depend on the quality of the proposals received and the availability of funds. For planning purposes, the Government has budgeted the following funding levels (for both Tasks), by Phase, for awards under this BAA (these amounts are approximate, subject to change, and does not include funding set aside for the Government support):

Phase 1 (18 months): $14.3 million Phase 2 (18 months): $16.2 million Phase 3 (12 months): $7.2 million

All proposers (for both tasks) should include Phase 1 as the base, and Phases 2 and 3 as priced options in their proposal.

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, as applicable.

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 (see Section VI.B.4., “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/or cost/price within a reasonable time, and the proposer fails to timely provide requested additional information. Proposals identified for negotiation may result in a procurement contract, 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.

Proposers looking for innovative, commercial-like contractual arrangements are encouraged to consider requesting Other Transactions. To understand the flexibility and options associated with Other Transactions, consult http://www.darpa.mil/work-with-us/contract-management#OtherTransactions.

In accordance with 10 U.S.C. § 2371b(f), the Government may award a follow-on production contract or Other Transaction (OT) for any OT awarded under this BAA if: (1) that participant in the OT, or a recognized successor in interest to the OT, successfully completed the entire prototype project provided for in the OT, as modified; and (2) the OT provides for the award of a follow-on production contract or OT to the participant, or a recognized successor in interest to the OT.

In all cases, the Government contracting officer shall have sole discretion to select award instrument type, regardless of instrument type proposed, and to negotiate all instrument terms and conditions with selectees. 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 http://www.darpa.mil/work-with-us/contract-management#OtherTransactions program. For more information on publication restrictions, see the section below on Fundamental Research.

B. 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 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 may be met by proposers intending to perform fundamental research and proposers not intending to perform fundamental research or the proposed research may present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Based on the nature of the performer and the nature of the work, the Government anticipates that some awards will include restrictions on the resultant research that will require the awardee 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. This clause can be found at http://www.darpa.mil/work-with-us/additional-baa.

For certain research projects, it may be possible that although the research being performed by the awardee is restricted research, a subawardee may be conducting fundamental research. In those cases, it is the awardee’s responsibility to explain in their proposal why its subawardee’s effort is fundamental research

III. Eligibility Information

A. Eligible Applicants

All responsible sources capable of satisfying the Government's needs may submit a proposal that shall be considered by DARPA.

http://www.darpa.mil/work-with-us/additional-baa

1. Federally Funded Research and Development Centers (FFRDCs) and Government Entities

a) FFRDCs FFRDCs are subject to applicable direct competition limitations and cannot propose to this BAA in any capacity unless they meet the following conditions: (1) FFRDCs must clearly demonstrate that the proposed work is not otherwise available from the private sector. (2) FFRDCs must provide a letter on official letterhead from their sponsoring organization citing the specific authority establishing their eligibility to propose to Government solicitations and compete with industry, and their compliance with the associated FFRDC sponsor agreement’s terms and conditions. This information is required for FFRDCs proposing to be awardees or subawardees.

b)…