HR001117S0046.pdf

Broad Agency Announcement Cross Domain Maritime Surveillance and Targeting Phase 2

STRATEGIC TECHNOLOGY OFFICE

HR001117S0046

September 11, 2017

CDMaST Phase 2

TABLE OF CONTENTS

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

1. FUNDING OPPORTUNITY DESCRIPTION

1.1 PROGRAM OVERVIEW

1.2 PROGRAM STRUCTURE

1.3 PROGRAM METRICS

2. AWARD INFORMATION

2.1 GENERAL AWARD INFORMATION

2.2 FUNDAMENTAL RESEARCH

3. ELIGIBILITY INFORMATION

3.1 ELIGIBLE APPLICANTS

3.2 ORGANIZATIONAL CONFLICTS OF INTEREST

3.3 COST SHARING/MATCHING

3.4 OTHER ELIGIBILITY CRITERIA

4. APPLICATION AND SUBMISSION INFORMATION

4.1 ADDRESS TO REQUEST APPLICATION PACKAGE

4.2 CONTENT AND FORM OF APPLICATION SUBMISSION

4.3 FORMATTING CHARACTERISTICS

4.4 SUBMISSION DATES AND TIMES

4.5 FUNDING RESTRICTIONS

4.6 OTHER SUBMISSION REQUIREMENTS

5. APPLICATION REVIEW INFORMATION

5.1 EVALUATION CRITERIA

5.2 REVIEW AND SELECTION PROCESS

6. AWARD ADMINISTRATION INFORMATION

6.1 SELECTION NOTICES AND NOTIFICATIONS

6.2 ADMINISTRATIVE AND NATIONAL POLICY REQUIREMENTS

6.3 REPORTING

6.4 ELECTRONIC SYSTEMS

7. AGENCY CONTACTS

8. OTHER INFORMATION

8.1 INTELLECTUAL PROPERTY

9. APPENDIX 1: PROPOSAL SLIDE SUMMARY

10. APPENDIX 2: CLASSIFIED ADDENDUM REQUEST FORM

11. APPENDIX 3: VOLUME 1 COVER SHEET TEMPLATE

12. APPENDIX 4: VOLUME 2 COVER SHEET, CHECKLIST AND SAMPLE

TEMPLATES

PART I: OVERVIEW INFORMATION

Federal Agency Name – Defense Advanced Research Projects Agency (DARPA), Strategic Technology Office

Funding Opportunity Title – Cross Domain Maritime Surveillance and Targeting (CDMaST) Phase 2

Announcement Type – Initial announcement Funding Opportunity Number – HR001117S0046 Catalog of Federal Domestic Assistance Numbers (CFDA) – Not applicable Dates o Industry day: September 8, 2017 o Posting date: September 11, 2017 o Questions due: September 26, 2017 o Questions and answers posted: October 11, 2017 o Proposal due date: November 1, 2017 o BAA closing date: March 10, 2018

Anticipated individual awards – One award is anticipated.

Anticipated funding amount – $45,000,000 Types of instruments that may be awarded - Procurement contract or other transaction.

Any cost sharing requirements – None Agency contact o Points of Contact The BAA Coordinator for this effort may be reached at:

HR001117S0046@darpa.mil

DARPA/STO

ATTN: HR001117S0046

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

PART II: FULL TEXT OF ANNOUNCEMENT

1. 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.

This BAA solicits proposals for Phase 2 of the Defense Advanced Research Projects Agency (DARPA) Cross Domain Maritime Surveillance and Targeting (CDMaST) program.

Participation in CDMaST Phase 1 is not required to be considered for award in CDMaST Phase 2.

CDMaST Phase 2 is divided into two parts: Phase 2A, which consists of 30 months and Phase 2B, which is anticipated to be an 18-month period of performance. In the Phase 2 proposal submissions, proposers should provide fully detailed proposals for the Phase 2A only. For Phase 2B, proposers should include a high-level statement of work (SOW) and rough order of magnitude (ROM) cost. Section 1.2 provides additional details on this division. DARPA intends to request updated technical and cost proposals for Phase 2B prior to the completion of Phase 2A. Request for proposals for Phase 2B will be solicited from the Phase 2A performer(s).

DARPA anticipates a single award for CDMaST Phase 2. This BAA describes three separate Technical Areas (TA). However, proposers must propose to the full scope, meaning all 3 technical areas, of the BAA as DARPA considers the TAs highly dependent on each other.

DARPA intends to make approximately $45,000,000 available to the performer for CDMaST Phase 2.

1.1 PROGRAM OVERVIEW

1.1.1 Overall Program Objective

The DARPA CDMaST program seeks to demonstrate a new approach to naval warfare consisting of highly distributed manned and unmanned Systems of Systems (SoS) acting collaboratively to control the seas. Specifically, the goal is to demonstrate the ability to conduct third-party, cross-domain (i.e., above, on, and under the ocean) targeting to hold enemy ships and submarines at risk over wide, contested areas while showing significantly increased military effectiveness, adaptability, and cost imposition to opponents.

This DARPA program is unique in that the objective is not to develop and demonstrate a specific technology but to develop and demonstrate a new warfighting concept. Specifically, we are trying to transform the future of sea control through implementation of as highly distributed system of systems approach.

To develop this warfighting concept, DARPA has drawn from the CDMaST Phase I effort and other study efforts to define an architecture construct (see classified addendum) to be used to demonstrate and explore the maritime SoS warfighting concept. This BAA seeks a prime awardee and associated team members to execute the SoS engineering to detail, compose, test, and demonstrate wide area kill chains.

DARPA anticipates the effort will entail integration of new applications and technology to support transition of the concept. Notionally, these applications and technology will encompass services such as communications; battle management; command and control (C2); position, navigation, and timing (PNT); logistics, along with sensors; manned and unmanned platforms;

and weapons systems. Performer teams should take a comprehensive approach to identifying and overcoming the challenges associated with tying these systems together as a function warfighting system.

Program deliverables are oriented towards supporting the transition of a warfighting concept rather than transition of a specific technology. Consequently, deliverables should include technical SoS engineering documentation, engineering analysis, test and experimentation results, along with media and materials clearly articulating the operational concept and impact of the SoS concept.

1.1.2 Program Background

Today, concentrated force created by carrier battle groups and high-end nuclear submarines is the basis of U.S. sea control strategy. Battle groups face an increasingly difficult environment where numerous long-range anti-ship missiles asymmetrically threaten multi-billion dollar-manned assets. The U.S. continues to dominate the undersea environment using the capabilities of submarines; however, the U.S. fundamentally lacks the number of submarines needed to provide the coverage and capacity of weapons to pace the rapidly evolving threat. Further, adversaries are greatly increasing their fixed and mobile anti-submarine capabilities in an effort to diminish the U.S. undersea advantage.

The approach of the CDMaST program is to move away from a centralized defensive battlegroup posture to a more distributed and agile approach in order to hold the opponent at risk over large areas (~1,000,000 square kilometers). The concept is to disaggregate and distribute combat functions across many lower cost systems, taking advantage of all warfare domains to threaten the opponent and force them on defense. The approach will involve using a combination of manned and unmanned systems to form an SoS architecture that is able to conduct wide area, cross-domain surveillance and targeting which will enable prompt, pervasive, offensive capabilities.

To be successful, CDMaST implementation must be asymmetric in nature causing the opponent to expend more resources trying to defeat the lesser cost systems. New net-enabled systems and technologies are emerging; these systems and technologies can enable a disaggregated SoS approach when integrated in a collaborative network. These elements include new anti-surface missiles and undersea weapon systems that greatly improve the range and speed of response.

Additionally, unmanned, long-endurance air, surface, and undersea vehicles along with pre-positioned seafloor systems have emerged; these systems provide time on station and payload capacity that is tactically useful. Individually, these new technologies are not sufficient to affect the battlespace greatly. However, combined with manned platforms, these systems can form a comprehensive SoS architecture, able to provide the surveillance and targeting needed to exploit new weapons.

1.2 PROGRAM STRUCTURE

In Phase 1, three industry teams used modeling, simulation, and analysis to develop maritime CDMaST SoS architectures in accordance with the CDMaST Phase 1 BAA (DARPA-BAA-16- 01 dated 15 October 2015). From these efforts, along with smaller ‘seedling’ study efforts conducted in parallel, the government identified the Phase 2 SoS architecture construct. A classified CD, available on request, contains the classified BAA addendum describing the architecture construct. In parallel, the Government developed a testbed designed to facilitate architecture concept experimentation during CDMaST Phase 2. The classified CD also contains supplemental information on the testbed as well as the Phase 1 BAA for reference.

In CDMaST Phase 2, the performer team will work with the Government to show both the technical feasibility and military value of the maritime SoS architecture concepts of interest through analysis and experimentation. The program will evaluate the technical and operational feasibility through a series of experiments using constructive, virtual, and live assets.

Specifically, Phase 2A will focus on the development and validation of architecture concepts for an anti-submarine warfare (ASW) scenario. Phase 2B will expand the architecture construct to include anti-surface warfare (ASuW) and ultimately support an integrated ASuW/ASW scenario and technical demonstration.

1.2.1 Contrast between CDMaST Phase 1 and CDMaST Phase 2

See classified addendum.

1.2.2 Program Methodology

The Phase 2 methodology is based on addressing the engineering feasibility of the SoS approach by demonstrating the effectiveness of distributed systems of systems and the necessary SoS services in support of executing the kill chain functions. Figure 1 graphically depicts the kill chain functions.

Detect LocalizeClassify Target Engage Assess

Figure 1: Nominal Kill Chain Functions

Figure 2 shows the ‘services pillars’ that form the SoS foundation needed to execute each kill chain function.

Figure 2: System of Systems Service Pillars

The Phase 2 approach is to build up to the full SoS sea control capability through a series of experimentation ‘waves’, that demonstrate progress on each service pillar and culminate in an end-to-end kill chain demonstration. The classified addendum provides an architecture construct based on the CDMaST Phase 1 architecture development efforts. This construct provides the basis for the experimentation program. Phase 2 experimentation will employ the given architecture construct to demonstrate the service pillars which support the kill chain functional areas as well as generalized SoS warfighting interoperability. For additional details relating the pillars in Figure 2 to the construct, see classified addendum.

The government recognizes that CDMaST encompasses an extremely broad range of technologies and concepts and that live testing all aspects of the SoS architecture is not practical.

Program execution must address time, cost, and asset availability constraints. Therefore, proposers should identify critical risk items and efficiently allocate live, virtual, and constructive experimentation resources to address those risks.

1.2.3 Phase 2 Architecture Construct

See classified addendum.

1.2.4 Phase 2 Program Schedule

CDMaST Phase 2A is anticipated to be a 30-month effort covering all three TAs and Phase 2B is anticipated to be an 18-month effort covering TAs 2 and 3 only. Phase 2 proposals must address all three TAs. Section 1.2.5 details each TA.

Figure 3 provides the notional Phase 2 schedule. The total period of performance for Phase 2 (both Phase 2A and Phase 2B) is anticipated to be 39 months. Phase 2B is anticipated to begin during month 21 of Phase 2A and will run concurrently with the remainder of the Phase 2A effort. See Figure 4 and section 1.2.5.3 for additional details on the experimentation wave schedule.

Q

Q

Q

Q

Q

Q

Q

Q

Q

Q

Q

Q

Q

Q

Q

Q

Q

TA1 Architecture Development

TA2: Test Bed Integration

TA3:

Experimentation

Programmatics

Phase 1 Phase 2

Fiscal Years

FY18 FY19 FY20 FY21

Phase 2

BAA

Phase 2A Award

Testbed Evolution and ExpansionTestbed Development

Excursion Demos

Wave 1

Wave 2

Wave 3

Wave 4

Wave 5

Wave 6

Architecture Development

Phase 2A

Phase 2B Award

*Phase 2B

Wave 7

Technical Demonstrations

Operational Experiments

2A *2B

*notionally Figure 3: CDMaST Phase 2 Schedule

1.2.5 TA Details

1.2.5.1 TA1 – Architecture Development

1.2.5.1.1 TA1 Description

The primary purpose of TA1 is to facilitate architecture refinement, documentation, and analysis to support substantiation of performance results. In TA1, the performer should refine the CDMaST SoS architecture results through full scenario modeling, simulation, and analysis to include:

Incorporation of new technology enablers and tactics Warfighter and stakeholder feedback (e.g., government team, operators, program offices) Lessons learned during Phase 2 experimentation Employment of advanced tactics

TA1 lasts the duration of the Phase 2A period only.

1.2.5.1.2 TA1 Nominal Tasks

TA1 tasks should include:

Refinement of the CDMaST SoS architecture through modeling, simulation, and analysis o Simulated warfighting results with implementation of Phase 2 architecture o Logistics plan with supporting analysis for deployment and sustainment of SoS architecture Phase 2 Architecture Documentation: Use of systems modeling language (SysML) based tools to assist in composition, validation and transition to documentation of the architecture is encouraged

For compatibility with Department of Defense standards, DARPA requires architecture documentation that follows the Department of Defense Architecture Framework (DoDAF) Version 2.02 or later, which can be found at http://dodcio.defense.gov/Library/DoD-Architecture-Framework/. Phase 2 systems engineering architecture models should be used to generate the following views at a minimum:

o OV-1 (High-Level Operational Concept) o OV-5b (Activity Trace) o SV-1 (Systems Interface Description: to describe major systems and their interfaces) o SV-2 (Systems Resource Flow Description to describe the communications/network infrastructure that major systems, which are described in SV-1s, will be using) o SV-10b (System State Transition Description) http://dodcio.defense.gov/Library/DoD-Architecture-Framework/

Costing of the CDMaST SoS architecture; specifically, acquisition, operation, and reconstitution costs

1.2.5.1.3 TA1 Proposal Guidance

Proposals should include the following:

A description of the proposed modeling, simulation, and analysis tool(s) to be used for

CDMaST SoS architecture refinement A description of the proposed tools and/or methods to document the CDMaST SoS architecture An overview of the architecture segments or pillars upon which the refinement process will focus; proposers should highlight specific areas where they plan to make improvements to the existing architecture

A plan, including milestones, to bring refinements of the CDMaST architecture into the TA3 experimentation process

1.2.5.2 TA2 – Testbed Integration Support

1.2.5.2.1 TA2 Description

The Government will provide an experimentation testbed to facilitate the continuous integration, test, and experimentation of the performer’s CDMaST SoS architecture concepts across each of the experimental waves. The Government will maintain the experimentation testbed architecture and its interfaces. The primary purpose of TA2 is for the industry team to collaborate with the Government to support the development of requisite constructive models and live asset (hardware and software) interfaces necessary for integration into the Government-developed, synthetic testbed environment.

TA2 will run the full duration of Phase 2 and should be broken into Phase 2A and Phase 2B periods.

1.2.5.2.2 TA2 Nominal Tasks

The continuation of testbed development in Phase 2 will be highly collaborative and rely on teaming between Government and the performer to enable interaction with battle management and command and control systems as well as hardware and software in the loop integration;

therefore, the performer is encouraged to:

Provide the technical information necessary for integration of the performer’s architecture implementation into the experimentation testbed. This information may come in the form of written documentation, technical interchange meetings, or short term staffing at the Government facility in San Diego, CA. For example:

o The performer may provide parameters and specifications for an unmanned system (UxS) to the Government. The Government will develop the constructive representation for use in the testbed.

o The performer may also provide Government access to the UxS hardware, high fidelity models, and/or autonomy software. The Government would leverage an existing interface or develop a new interface to integrate either the performer’s UxS and/or autonomy engine into the testbed.

Provide continuous feedback to the Government on the experimentation testbed architecture and interfaces throughout Phase 2. The performer may provide this feedback formally through documentation or informally through technical interchange meetings or during other interactions.

1.2.5.2.3 TA2 Proposal Guidance

DARPA encourages proposers to consider TA2 a minor, support task relative to the overall Phase 2 effort. TA2 should be used to describe the efforts and travel required to achieve integration and operation of systems with the testbed.

1.2.5.3 TA3 – Experimentation

1.2.5.3.1 TA3 Description

In TA3, the performer, in collaboration with the Government experimentation team, will test and demonstrate their CDMaST SoS architecture. As shown in the schedule (Figure 3), TA3 will consist of experimentation waves that will demonstrate increasing technical capabilities and will lead up to end-to-end technical demonstrations. In Phase 2A, shown in Figure 4 (CDMaST Experimentation Strategy) below (corresponding to a blow up of Waves 1-4 in Figure 3), the performer and the Government will conduct a series of tests to prove the utility of the service pillars posited in the performer’s CDMaST SoS architecture. Waves 1, 2, and 3 will focus on operational experiments with the goal of adding capability and robustness in each subsequent wave. This approach will enable a full technical demonstration focused on ASW in Wave 4.

Figure 4: CDMaST Experimentation Strategy

For the purposes of illustrating the concept of engineering tests and operational experiments in a wave, Figures 5 and 6 below depict a fictitious SoS architecture and notional groupings of tests and experiments for a wave based around two of the service pillars shown in Figure 2 (Communications/Networking and C2).

In Figure 5, the upper-right graphic depicts the notional overall theater ‘kill web’ architecture laydown. The constructive-virtual environment simulates the full theater laydown for interaction with the battle management and C2 systems. Key elements, circled in yellow, constitute the live elements needed to complete the kill chain. The yellow circles depict notional engineering tests using real hardware and software in a live and/or high fidelity synthetic environment. Finally, after completion of the engineering tests, the performer and the Government will conduct an operational experiment. The operational experiment exercises and explores communications throughout the kill-chain in a live, virtual, constructive environment. Figure 6 expands one engineering test from Figure 5 into three sequential tests that demonstrate increasing capability.

Figure 5: Notional Grouping of Engineering Tests and Operational Experiments

Figure 6: Notional Engineering Test Breakdown

These operational experiment waves are repeated to address different service pillars as proposed by the performer. The waves will address the critical architecture risk areas and will culminate in a full end-to-end demonstration incorporating all of the service pillars.

In Phase 2B, shown as Waves 5-7 in Figure 3, the performer and the Government will conduct one ASuW operational test wave, one ASuW technical demonstration wave, and one combined ASuW/ASW technical demonstration wave that will loosely follow strategy shown in Figure 4.

1.2.5.3.2 TA3 Tasks

Phase 2A

Proposers should break out TA3 tasks into:

Tasks related to each wave in Figure 4 Independent, standalone tasks required to execute proposed tests (e.g., long-term integration efforts, information assurance (IA) efforts, procurement of long-lead items)

For all experimentation waves, the performer will provide a Declaration of Intent (DoI).

Specifically, the performer will identify the core objective(s) of each wave, the technical challenges in the wave, and the technical solutions for each challenge for each of the service pillars, including hardware / software integration.

For waves 1, 2, and 3, the performer should include the following tasks as shown in Figure 4 (tasks can and should overlap during a given wave):

Scenario development and system integration: The performer, with Government support, will develop the specific scenario by which to implement their DoI. The performer will also identify the specific systems requiring integration to support the scenario.

SoS integration: The performer will define the end-to-system SoS configuration to be addressed in this wave, develop the integration specifications (e.g., size/weight/power/cost (SWAP-C) for integrating systems onto platforms, the data exchange specifications for SoS data communications, etc.)

Engineering testing: The performer will conduct scaled tests to begin reducing technical risk for the given DoI. Engineering tests may be executed at performer, commercial, and/or Government facilities as required.

Experimentation and analysis: The performer, with Government support, will refine their architecture and reduce risk based on their own analysis and on feedback from the Government. The performer’s analysis may come from analytical assessments, modeling and simulation results, and/or constructive-only excursions with either their own tools or the Government testbed.

Operational experiments: The performer will perform tests using the testbed environment and live ranges that result in a proof of concept that supports the given declaration of intent. Operational experiments should build upon the engineering tests and analysis conducted in the given wave and in previous waves, if applicable.

Tactics workshop: The performer will attend tactics workshops hosted by the Government. The performer will present their scenario and corresponding concept of operations (CONOP). The Government will provide feedback for the performer to refine and improve their scenario and architecture concepts. For tactics workshops, the Government audience will include active duty Navy personnel from relevant warfighting areas as well as the acquisition community.

For wave 4, the performer should include the following tasks at minimum:

The same tasks as waves 1, 2, and 3.

Technical demonstration: The performer will perform an end-to-end demonstration of the performer’s architecture implementation. For wave 4, the demonstration will focus on ASW. The technical demonstration should occur after operational experimentation.

Stakeholder engagement: The performer will attend stakeholder engagement hosted by the Government at the conclusion of each full kill chain demonstration (waves 4, 6, and 7). The performer will present the results of the given wave to the Government to receive feedback. For stakeholder engagements, the Government audience will include potential transition partners such as relevant Navy program offices.

1.2.5.3.3 TA3 Proposal Guidance

Phase 2A The fundamental SoS challenges revolve around the ability to obtain, process, transfer, and control engagement quality targeting information in a contested, cross-domain environment in a timely manner. Performers should maximize experimentation resources to address these challenges while minimizing expenditures for packaging of technology and acquisition of platforms. Performers can assume that unmanned platforms are capable of waypoint positioning;

therefore, manually positioned mobile or stationary surrogate platforms are acceptable provided:

1) the size, weight, and power are compatible with the actual platform; and 2) motion effects are reasonably taken into account.

Proposers should include waves 1, 2, 3, and 4 in their Phase 2A proposal. Waves 1, 2, and 3 end with operational experiments; wave 4 ends in a technical demonstration. Proposers should propose each wave as a standalone, fully priced item, including program management, security, and other support function costs. DARPA reserves the right to award some or all waves in a proposal, based on resource availability and the evaluation criteria in section 5.1.

At a minimum, proposers should include the following information in their proposals for each experimentation wave:

Identification of the technical risks in the proposed CDMaST SoS architecture concepts Description of the CDMaST SoS architecture implementation and associated service pillars that will be tested (i.e., Declaration of Intent) Identification of the set of tests that the performer and the Government will execute to reduce these technical risks Identification of the combinations of constructive, virtual, and live assets needed to execute each test Identification of the Technology Readiness Level (TRL) of each asset for each test.

DARPA encourages the use of surrogates or real assets at TRL5 or higher for CDMaST Phase 2. TRL definitions can be found at:

http://www.acq.osd.mil/chieftechnologist/publications/docs/TRA2011.pdf

Identification of the preparation work required to support each test, including:

o Integration of hardware and/or software on individual assets o Meeting IA and security requirements o Logistics to obtain assets and move them to the test areas

Phase 2B

Waves 5, 6 and 7 will be part of Phase 2B. Wave 5 is an operational test wave, similar to waves 1, 2, and 3. Wave 6 will be a technical demonstration focused on ASuW. Wave 7 will be a combined ASuW/ASW technical demonstration. Refer to section 1.1.2.2 of the classified addendum for details on the technical demonstrations of interest for wave 6.

For the Phase 2B, proposers should include a ROM cost and high-level SOW. Unlike the Phase 2A proposal, the Phase 2B estimate does not need to be priced with separate, standalone waves.

1.2.6 Deliverables

Proposals should include the following deliverables:

Monthly reports with program status and financials Presentation materials from all Government technical interchange meetings and workshops Mid-term and final CDMaST SoS architecture modeling and simulation results that assess the architecture’s ability to meet CDMaST metrics as defined in section 1.3.

Documentation of the technical information necessary for integration of the performer’s architecture into the distributed experimentation testbed Test Methods and Inputs into the Government Experimentation Master Plan http://www.acq.osd.mil/chieftechnologist/publications/docs/TRA2011.pdf

Asset Management Plan (includes safety/security plan for systems and platforms) For each experimentation wave:

o Risk Assessment o Critical Design Review (CDR) Reports, including:

Declaration of Intent Architecture CDR Systems CDR o After-Action Report (AAR) for experiments and tests Final Report including:

o CDMaST SoS architecture description and supporting documentation, including DoDAF views and architecture costs as specified in TA1 task descriptions o Final CDMaST SoS architecture modeling and simulation results that assess the architecture’s ability to meet CDMaST metrics as defined in section 1.3.

o Summary of experimentation campaign, outcomes, and lessons learned Animated vignette articulating operational concept

1.2.7 Government Furnished Equipment / Information (GFE/GFI)

DARPA will provide the following as GFE:

Partial testbed environment for use at performers location, including:

o Software o Full description of partial testbed including contrast with full testbed o Requirements to receive, install, operate, and store the partial testbed

DARPA will provide the following as GFI:

Testbed o Testbed description o Testbed hardware in the loop (HWIL) and software in the loop (SWIL) capabilities o Distributed test capabilities o Live range capabilities

Testbed Interfaces o Documentation needed for Government to model constructive assets o Requirements to use live assets, HWIL, and SWIL at Government facilities o Software interface specifications

Experimentation Planning o Detailed experimentation wave strategy o Preliminary version of Government Experimentation Master Plan

1.3 PROGRAM METRICS

See classified addendum.

2. AWARD INFORMATION

2.1 GENERAL AWARD INFORMATION

One award is anticipated. The amount of resources made available under this BAA will depend on the quality of the proposals received and the availability of funds.

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 6.2.10 “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 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 program. For more information on publication restrictions, see the section below on Fundamental Research.

http://www.darpa.mil/work-with-us/contract-management#OtherTransactions

2.2 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 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 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

3. ELIGIBILITY INFORMATION

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

3.1 ELIGIBLE APPLICANTS

3.1.1 Federally Funded Research and Development Centers (FFRDCs) and Government Entities http://www.darpa.mil/work-with-us/additional-baa

3.1.1.1 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.

3.1.1.2 Government Entities

Government Entities (e.g., Government/National laboratories, military educational institutions, etc.) are subject to applicable direct competition limitations. Government entities must clearly demonstrate that the work is not otherwise available from the private sector and provide written documentation citing the specific statutory authority and contractual authority, if relevant, establishing their ability to propose to Government solicitations.

3.1.1.3 Authority and Eligibility

At the present time, DARPA does not consider 15 U.S.C. § 3710a to be sufficient legal authority to show eligibility. While 10 U.S.C.§ 2539b may be the appropriate statutory starting point for some entities, specific supporting regulatory guidance, together with evidence of agency approval, will still be required to fully establish eligibility. DARPA will consider FFRDC and Government entity eligibility submissions on a case-by-case basis; however, the burden to prove eligibility for all team members rests solely with the proposer.

3.1.2 Non-U.S. Organizations

Non-U.S. organizations and/or individuals may not participate in this effort as a prime awardee to DARPA since most work will be performed at the SECRET/NOFORN level. Non U.S.

organizations and/or individuals may act as subawardees to the extent that the prime awardee can ensure such participants comply with any necessary nondisclosure agreements, security regulations, export control laws, and other governing statutes applicable under the circumstances.

Non-U.S. organizations or individuals acting as subawardees will perform solely at the unclassified level. See Section 4.2 “Security and Proprietary Issues” regarding the proposers capabilities to perform research and development at the classification level they propose.

3.1.3 Applicants Considering Classified Submissions

DARPA expects classified submissions to this BAA. For classified proposals, applicants will ensure all industrial, personnel, and information systems for processing security requirements are in place and at the appropriate level (e.g., Facility Clearance Level (FCL), Automated Information Security (AIS), Certification and Accreditation (C&A), and any Foreign Ownership

Control and Influence (FOCI) issues are mitigated prior to submission. Additional information on these subjects can be found at http://www.dss.mil.

3.2 ORGANIZATIONAL CONFLICTS OF INTEREST

FAR 9.5 Requirements In accordance with FAR 9.5, proposers are required to identify and disclose all facts relevant to potential OCIs involving the proposer’s organization and any proposed team member (subawardee, consultant). Under this Section, the proposer is responsible for providing this disclosure with each proposal submitted to the BAA. The disclosure must include the proposer’s, and as applicable, proposed team member’s OCI mitigation plan. The OCI mitigation plan must include a description of the actions the proposer has taken, or intends to take, to prevent the existence of conflicting roles that might bias the proposer’s judgment and to prevent the proposer from having unfair competitive advantage. The OCI mitigation plan will specifically discuss the disclosed OCI in the context of each of the OCI limitations outlined in FAR 9.505-1 through FAR 9.505-4.

Agency Supplemental OCI Policy In addition, DARPA has a supplemental OCI policy that prohibits contractors/performers from concurrently providing Scientific Engineering Technical Assistance (SETA), Advisory and Assistance Services (A&AS) or similar support services and being a technical performer.

Therefore, as part of the FAR 9.5 disclosure requirement above, a proposer must affirm whether the proposer or any proposed team member (subawardee, consultant) is providing SETA, A&AS, or similar support to any DARPA office(s) under: (a) a current award or subaward; or (b) a past award or subaward that ended within one calendar year prior to the proposal’s submission date.

If SETA, A&AS, or similar support is being or was provided to any DARPA office(s), the proposal must include:

The name of the DARPA office receiving the support;

The prime contract number;

Identification of proposed team member (subawardee, consultant) providing the support; and An OCI mitigation plan in accordance with FAR 9.5.

Government Procedures In accordance with FAR 9.503, 9.504 and 9.506, the Government will evaluate OCI mitigation plans to avoid, neutralize or mitigate potential OCI issues before award and to determine whether it is in the Government’s interest to grant a waiver. The Government will only evaluate OCI mitigation plans for proposals that are determined selectable under the BAA evaluation criteria and funding availability.

The Government may require proposers to provide additional information to assist the Government in evaluating the proposer’s OCI mitigation plan.

If the Government determines that a proposer failed to fully disclose an OCI; or failed to provide the affirmation of DARPA support as described above; or failed to reasonably provide additional http://www.dss.mil/ information requested by the Government to assist in evaluating the proposer’s OCI mitigation plan, the Government may reject the proposal and withdraw it from consideration for award.

3.3 COST SHARING/MATCHING

Cost sharing is not required; however, it will be carefully considered where there is an applicable statutory condition relating to the selected funding instrument. Cost sharing is encouraged where there is a reasonable probability of a potential commercial application related to the proposed research and development effort.

For more information on potential cost sharing requirements for Other Transactions for Prototype, see http://www.darpa.mil/work-with-us/contract-management#OtherTransactions.

3.4 OTHER ELIGIBILITY CRITERIA

3.4.1 Collaborative Efforts

Collaborative efforts/teaming are encouraged.

4. APPLICATION AND SUBMISSION INFORMATION

4.1 ADDRESS TO REQUEST APPLICATION PACKAGE

This announcement, any attachments, and any references to external websites herein constitute the total solicitation. If proposers cannot access the referenced material posted in the announcement found at www.darpa.mil, contact the administrative contact listed herein.

4.2 CONTENT AND FORM OF APPLICATION SUBMISSION

4.2.1 Security and Proprietary Issues

NOTE: If proposals are classified, the proposals must indicate the classification level of not only the proposal itself, but also the anticipated award document classification level.

DARPA policy is to treat all submissions as source selection information (see FAR 2.101 and 3.104), and to disclose their contents only for the purpose of evaluation. Restrictive notices notwithstanding, during the evaluation process, submissions may be handled by support contractors for administrative purposes and/or to assist with technical evaluation. All DARPA support contractors performing this role are expressly prohibited from performing DARPA-sponsored technical research and are bound by appropriate nondisclosure agreements.

Submissions will not be returned. The original of each submission received will be retained at DARPA and all other non-required copies destroyed. A certification of destruction may be http://www.darpa.mil/ requested, provided the formal request is received at this office within 5 days after notification that a proposal was not selected.

a. Proprietary Information Proposers are responsible for clearly identifying proprietary information. Submissions containing proprietary information must have the cover page and each page containing such information clearly marked with a label such as “Proprietary”. NOTE: “Confidential” is a classification marking used to control the dissemination of U.S. Government National Security Information as dictated in Executive Order 13526 and should not be used to identify proprietary business information.

b. Security Information Classified submissions shall be transmitted in accordance with the following guidance.

Additional information on the subjects discussed in this section may be found at http://www.dss.mil/.

If a submission contains Classified National Security Information as defined by Executive Order 13526, the information must be appropriately and conspicuously marked with the proposed classification level and declassification date. Similarly, when the classification of a submission is in question, the submission must be appropriately and conspicuously marked with the proposed classification level and declassification date. Submissions requiring DARPA to make a final classification determination shall be marked as follows:

“CLASSIFICATION DETERMINATION PENDING. Protect as though classified____________________________(insert the recommended classification level, e.g., Top Secret, Secret or Confidential)”

NOTE: Classified submissions must indicate the classification level of not only the submitted materials, but also the classification level of the anticipated award.

Proposers submitting classified information must have cognizant security agency approved facilities, information systems, and appropriately cleared/eligible personnel to perform at the classification level proposed. All proposer personnel performing Information Assurance (IA)/Cybersecurity related duties on classified Information Systems shall meet the requirements set forth in DoD Manual 8570.01-M (Information Assurance Workforce Improvement Program).

Proposers choosing to submit classified information from other collateral classified sources (i.e., sources other than DARPA) must ensure (1) they have permission in writing from an authorized individual at the cognizant Government agency (e.g., Contracting Officer, Program Manager);

(2) the proposal is marked in accordance with the source Security Classification Guide (SCG) from which the material is derived; and (3) the source SCG is submitted along with the proposal.

The effort being solicited by this BAA is classified or otherwise involves access to, or generation of, classified information. Security classification guidance via a Security Classification Guide (SCG) and DD Form 254, “DoD Contract Security Classification Specification,” is provided with the BAA Classified Addendum. The BAA Classified Addendum is classified collateral http://www.dss.mil/

Secret; as such it can only be mailed to the requester’s classified mailing address which must be provided to the Technical Office Program Security Officer or their staff.

A formal request for the DARPA-HR001117S0046 BAA Classified Addendum and Security Classification Guide may be submitted by filling out the Classified Documents Request Form (found in APPENDIX 2 to this BAA) and emailing the Request Form to HR001117S0046@darpa.mil with subject line titled “Request DARPA- HR001117S0046 Classified Documents.” Security classification guidance via a Security Classification Guide (SCG) and a DD Form 254, “DoD Contract Security Classification Specification,” will be provided.

Proposers are required to submit this request no later than 15 September, 2017 to allow for adequate time for delivery of the material. The DARPA-HR001117S0046 Classified Documents Request Form is the only method of request that will be accepted.

Confidential and Secret Information Use transmission, classification, handling, and marking guidance provided by previously issued SCGs, the DoD Information Security Manual (DoDM 5200.01, Volumes 1 - 4), and the National Industrial Security Program Operating Manual, including the Supplement Revision 1, (DoD 5220.22-M and DoD 5200.22-M Sup. 1) when submitting Confidential and/or Secret classified information.

Confidential and Secret classified information may be submitted via ONE of the two following methods:

Hand-carried by an appropriately cleared and authorized courier to the DARPA CDR.

Prior to traveling, the courier shall contact the DARPA Classified Document Registry (CDR) at 703-526-4052 to coordinate arrival and delivery.

OR

Mailed via U.S. Postal Service (USPS) Registered Mail or USPS Express Mail. All classified information will be enclosed in opaque inner and outer covers and double-wrapped. The inner envelope shall be sealed and plainly marked with the assigned classification and addresses of both sender and addressee.

The inner envelope shall be addressed to:

Defense Advanced Research Projects Agency ATTN: STO / Dr. James Galambos / Ms. Jackie Croat Reference: HR001117S0046 675 North Randolph Street Arlington, VA 22203-2114

The outer envelope shall be sealed with no identification as to the classification of its contents and addressed to:

mailto:HR001117S0046@darpa.mil

Defense Advanced Research Projects Agency Security & Intelligence Directorate, Attn: CDR 675 North Randolph Street Arlington, VA 22203-2114

Top Secret Information Use classification, handling, and marking guidance provided by previously issued SCGs, the DoD Information Security Manual (DoDM 5200.01, Volumes 1 - 4), and the National Industrial Security Program Operating Manual, including the Supplement Revision 1, (DoD 5220.22-M and DoD 5200.22-M Sup. 1). Top Secret information must be hand-carried by an appropriately cleared and authorized courier to the DARPA CDR. Prior to traveling, the courier shall contact the DARPA CDR at 703-526-4052 to coordinate arrival and delivery.

Sensitive Compartmented Information (SCI) SCI must be marked, managed and transmitted in accordance with DoDM 5105.21 Volumes 1

- 3. Questions regarding the transmission of SCI may be sent to the DARPA Technical Office PSO via the BAA mailbox or by contacting the DARPA Special Security Officer (SSO) at 703- 812-1970.

Successful proposers may be sponsored by DARPA for access to SCI. Sponsorship must be aligned to an existing DD Form 254 where SCI has been authorized. Questions regarding SCI sponsorship should be directed to the DARPA Personnel Security Office at 703-526-4543.

Special Access Program (SAP) Information SAP information must be marked in accordance with DoDM 5205.07 Volume 4 and transmitted by specifically approved methods which will be provided by the Technical Office Program Security Officer or their staff.

Proposers choosing to submit SAP information from an agency other than DARPA are required to provide the DARPA Technical Office PSO written permission from the source material’s cognizant Special Access Program Control Officer (SAPCO) or designated representative. For clarification regarding this process, contact the DARPA Technical Office PSO via the BAA mailbox or the DARPA SAPCO at 703-526-4102.

Additional SAP security requirements regarding facility accreditations, information security, personnel security, physical security, operations security, test security, classified transportation plans, and…