DARPA-BAA-10-79 BLADE BAA July 9.pdf

DARPA-BAA-10-79

Behavioral Learning for Adaptive Electronic Warfare

(BLADE)

Broad Agency Announcement (BAA) for

Information Processing Techniques Office (IPTO) Defense Advanced Research Projects Agency

(DARPA)

Table of Contents Part One: Overview Information Part Two: Full Text of Announcement

I. FUNDING OPPORTUNITY DESCRIPTION

II. AWARD INFORMATION

III. ELIGIBILITY INFORMATION

A. Eligible Applicants

1. Historically Black Colleges and Universities, Small Businesses, Small Disadvantaged Businesses and Minority Institutions

2. Federally Funded Research and Development Centers (FFRDCs) and Government entities

3. Foreign Participation

4. Procurement Integrity, Standards of Conduct, Ethical Considerations, and Organizational Conflicts of Interest

B. Cost Sharing or Matching C. Other Eligibility Requirements

1. Ability to Support Classified Design and Development

IV. APPLICATION AND SUBMISSION INFORMATION

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

1. Proposal Information

2. Proposal Preparation and Format

C. Submission Dates and Times D. Intergovernmental Review - N/A E. Funding Restrictions – N/A F. Other Submission Requirements

V. APPLICATION REVIEW INFORMATION

A. Evaluation Criteria B. Review and Selection Process

VI. AWARD ADMINISTRATION INFORMATION

A. Award Notices B. Administrative and National Policy Requirements C. Reporting

VII. AGENCY CONTACTS

VIII. OTHER INFORMATION

A. Frequently Asked Questions (FAQs) B. Collaborative Efforts/Teaming C. Industry Day

Part One: Overview Information

• Federal Agency Name – Defense Advanced Research Projects Agency

(DARPA), Information Processing Techniques Office (IPTO)

• Funding Opportunity Title – Behavioral Learning for Adaptive Electronic

Warfare (BLADE)

• Announcement Type – Initial Broad Agency Announcement (BAA)

• Funding Opportunity Number – DARPA-BAA-10-79

• Catalog of Federal Domestic Assistance Numbers (CFDA) - N/A

• Key Dates o Posting Date – see announcement at www.fbo.gov o Proposal Due Date

Initial Closing – 12:00 noon (ET), 8 September 2010 Final Closing – 12:00 noon (ET), 8 November 2010 o Industry Day – 28 July 2010. The Industry Day will be classified and therefore attendance is limited to individuals with US DODSECRET clearances or higher. See Section VIII.C. for details.

• Anticipated individual awards – Multiple awards are anticipated.

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

• Technical POC: Yiftach Eisenberg, Program Manager, DARPA/IPTO

• IPTO Solicitation Website: www.darpa.mil/ipto/solicit/solicit_open.asp

• BAA mailbox: DARPA-BAA-10-79@darpa.mil

• BAA FAX: 703-248-8072

• BAA Mailing Address

ATTN: DARPA-BAA-10-79

3701 North Fairfax Drive Arlington, VA 22203-1714

Part Two: Full Text of Announcement

I. FUNDING OPPORTUNITY DESCRIPTION

The Defense Advanced Research Projects Agency (DARPA) often selects its research efforts through the Broad Agency Announcement (BAA) process. This BAA is being issued, and any resultant selection will be made, using procedures under FAR Part

35.016. Any negotiations and/or awards will use procedures under FAR 15.4, Contract Pricing, as specified in the BAA. Proposals received as a result of this BAA shall be evaluated in accordance with evaluation criteria specified herein through a scientific review process. The BAA will appear first on the Federal Business Opportunities website, http://www.fedbizopps.gov/. The following information is for those wishing to respond to the BAA.

DARPA is soliciting innovative research proposals in the area of machine learning for electronic warfare applications. Proposed research should investigate innovative approaches that enable revolutionary advances in science, devices, or systems.

Specifically excluded is research that primarily results in evolutionary improvements to the existing state of practice.

Introduction

The goal of the Behavioral Learning for Adaptive Electronic Warfare (BLADE) program is to develop the capability to counter adaptive wireless communication threats in tactical environments and in tactically relevant time scales. Wireless communication threats include an adversary’s use of wireless radios and networks for Command, Control, and Communication (C3), as well as for other malicious uses, such as Radio Control Improvised Explosive Devices (RC-IED’s).

Currently, the development of new Electronic Attack (EA) techniques requires technicians in a laboratory to characterize a new communication threat and then synthesize and evaluate potential countermeasures. Meanwhile, U.S and allied forces remain vulnerable to the new threat until the new countermeasure is fielded. In addition to taking a significant amount of time to develop, EA techniques today are rigidly designed to address a specific threat with known characteristics. As wireless communication devices become more adaptive and responsive to their environment by using technology such as Dynamic Spectrum Allocation (DSA), the effectiveness of fixed countermeasures may become severely degraded.

To protect U.S. forces and enable the rapid defeat of new communication threats, a paradigm shift in Electronic Attack is needed from a manual lab-based EA development approach to an adaptive in-the-field systems approach. The BLADE program will achieve this objective by developing novel algorithms and techniques that will enable our EW systems to automatically learn to jam new RF threats in the field.

Program Scope

The scope of the BLADE program includes the development of a networked EA system capable of automatically jamming new wireless communication threats, in the field. The key challenges for meeting this objective are:

• Detecting and characterizing the new threat

• Learning to effectively and efficiently jam the new threat

• Accurately assessing jam effectiveness in the field

The BLADE program will address these key challenges through the development of a closed loop system comprised of three functional modules, as shown below:

These modules are described in detail below. Specific information regarding the types of threat signals of interest and the performance goals for the three modules are contained in the classified addendum. See Section IV.A. below for instructions on requesting the classified addendum.

• Detection and Characterization – this includes the development of algorithms and techniques for detecting the presence of a new threat and learning its characteristics. Proposals should address methods for detecting new communication threats operating over very wide frequency ranges and in highly cluttered tactical RF environments. While detection is a critical first step in countering a new threat, it is believed that a substantial amount of prior investment in adaptive detection algorithms may be leveraged and extended for the BLADE application. Proposals should clearly state the maturity of any baseline detection algorithms used as part of the approach and describe specific advancements requiring further research and development. The BLADE program seeks advanced signal characterization algorithms that enable the classification of observed communication signals as either one of a list of known threats or as new/unknown. Of particular interest are algorithms capable of deriving Physical (PHY), Media Access Control (MAC), and Network (NET) layer features of communication threats from over-the-air observables. In addition to

EWO

Command & Display

Wideband ReceiverRx Detection and

Characterization

Jam Waveform Optimization

Battle Damage Assessment

Jam/Probe TransmitterTx enabling threat classification, the derived characteristics of a threat signal are also envisioned to enable improved jam waveform optimization and battle damage assessment, as described below.

• Jam Waveform Optimization – this includes the development of methods and techniques for automatically synthesizing countermeasures that effectively and efficiently deny detected communication threat(s). Of special interest are machine learning algorithms that use information derived through passive signal characterization as well as from active probing and learning, to automatically synthesize surgical `jamming techniques. Proposals should address methods for minimizing jam resource utilization, (i.e., RF power, bandwidth, and duty cycle) while achieving a desired level of jam effectiveness. Solutions are sought that will enable the BLADE system to address multiple simultaneous threats by optimally allocating limited jamming resources across the targeted threat space.

Key to the jam waveform optimization process is feedback from the Battle Damage Assessment module, described below.

• Battle Damage Assessment – this includes the development of algorithms and techniques for accurately assessing jam effectiveness in the field. Proposals should address methods for evaluating jam effectiveness over-the-air, i.e., without physical access to the threat radio. Of particular interest are techniques that exploit the over-the-air observable changes in the threat radio caused by our jamming to enable the BLADE system to assess its impact and infer the integrity of the threat communication link. As discussed above, the assessment of jam effectiveness may be fed back to the Jam Waveform Optimization module to continually optimize the jam response.

While the BLADE system should be capable of automatically jamming new communication threats, it should also be designed to enable an Electronic Warfare Officer (EWO) to command the system and receive feedback from it. Specifically, the EWO should be able to command the BLADE system to either jam particular threats or simply identify potential threats and learn how to defeat them. In the latter case, the system would not actually jam a threat until it is commanded to do so by the EWO. This provides the EWO with the capability to carefully control the application of communication denial effects based on the overall mission requirements. In addition to providing commands, the EWO should receive feedback from the BLADE system showing what communication threats have been detected and how effectively a particular radio threat is being jammed. This feedback provides a powerful situational awareness capability to the warfighter. In addition to fully autonomous operation, proposals should address specific human-computer interfaces in the BLADE system that enable the EWO interactions described above.

The BLADE system should be developed using an open-software architecture to allow for insertion, modification and removal of software modules with minimal impact to other parts of the system. A flexible and extensible architecture that allows different processing modules to “plug in” to the system using standards-based programming techniques is desirable. Development of new RF front end hardware (receiver, transmitter, controllable radio, antennas, etc.) is out of scope of the BLADE program.

Rather, the Government envisions software algorithms developed under the BLADE program to be integrated into existing EW hardware. Proposals should recommend EW hardware platforms suitable for porting the BLADE algorithms in the latter part of the program. The Government will select the actual target hardware based on performer recommendations and evaluation of potential transition opportunities.

Emitter geo-location, specific emitter identification, and other enabling technologies may be leveraged and integrated into the BLADE system, but development of these enabling technologies is out of scope of this program. The assumptions, maturity, and approach for integrating any enabling technologies, such as emitter geo-location, should be explicitly stated in the proposal.

The BLADE system should be capable of operating as a single node or as a network of distributed BLADE nodes, with performance improving as nodes are added to the network. While solutions that enable multiple BLADE nodes to cooperatively sense and deny new threats are desirable, the development of new networking technologies is out of scope of this program. Rather, existing networking capabilities may be leveraged to enable information sharing among multiple BLADE nodes. Proposals should clearly state any assumptions about available networking capabilities including nominal data rates, latency, etc.

It is desired that the BLADE system be capable of:

• Rapidly detecting and denying new communication threats in the field

• Providing real-time feedback on jam effectiveness

• Surgically attacking new threats

• Countering multiple simultaneous threats

• Supporting single node operation as well as distributed multi-node operations

• Supporting fully autonomous operation as well as human-in-the-loop operation

• Suitable for vehicle mounted and Group 3 UAS operations, such as the Shadow

(Proposed approach may include standoff assets as part of the overall approach, but should clearly describe how those assets fit into the vision for a closed-loop system capable of detecting new threats and adapting to them in the field.)

• Standards-based, modular, open and extensible software architecture

Proposers may submit proposals that address either 1) a complete end-to-end BLADE system as described above, or 2) one or more of the functional modules (Detection & Characterization, Jam Waveform Optimization, Battle Damage Assessment). Proposals described under 1) and 2) may propose more than one approach/solution for each module.

An independent Government Evaluation Team will be responsible for testing and evaluating BLADE system performance against Government-defined communication threats. Test and evaluation will begin with non-real-time testing early in the program to validate the algorithms, and move toward field testing of a real-time EW system integrated onto Government approved form factor hardware.

Program Structure

The BLADE program is structured in three phases as described below. The phase lengths shown are what the Government anticipates, however, proposers should propose phase lengths commensurate with the work proposed. Phase 1 is focused on system design and algorithm development. Phase 2 is focused on real-time implementation of the Phase 1 designs. Phase 3 is an effort to produce a networked form-fit-functional prototype system.

Phase 1 (15 months): The first phase of the program should focus on developing the system architecture and algorithms for threat detection and characterization, jam waveform optimization, and battle damage assessment. Proposers should consider multi-node architectures that can distribute functions and resources via networked operations. Non-real-time software-based jamming solutions will be tested against communication threats developed by the Government Evaluation Team (see Test and Evaluation section below). The primary objective of Phase 1 is to demonstrate that machine learning algorithms can enable an EW system to rapidly counter new communication threats.

Phase 2 (18 months): The second phase should focus on extending the software system architecture and algorithms and implementing them in a real-time processing system. Emphasis should be on software architecture, real-time functionality and performance, rather than form factor. Provisions for networking between multiple processing nodes, for the purpose of distributing operations (e.g., sensing) and resources (e.g., jam power), should also be implemented. The outcome of this phase should be a functional jammer system, capable of countering multiple simultaneous radio threats, including legacy and unknown adaptive communications waveforms.

Proposers may use any suitable hardware needed to demonstrate their solution, including custom, commercial, and laboratory equipment. Proposers should identify potential hardware used as part of their real-time non-form-factor system. Each performer’s solution will be made available to the Government Evaluation Team who will evaluate its performance against real-time over-the-air signals in both laboratory and controlled field environments.

Phase 3 (18 months): The objective of Phase 3 is to produce a form-fit-function cognitive jammer system. The processing functions developed in Phase 2 should be optimized and refined in terms of performance and size, and integrated with Government approved EW hardware. Networked operation should be enhanced to implement distributed sensing and resource management across multiple BLADE nodes. At least three nodes are to be constructed for testing in operational like environments, potentially including an airborne node. The primary transition target for BLADE will be vehicle-mounted EW systems. The specific EW system to target for integration will be selected early in the program in concert with potential transition partners. Proposers should suggest potential platforms for consideration. Phase 3 test and evaluation will be conducted by the Government Evaluation Team in theater-like environments against a wide range of communication threats.

Test and Evaluation

Performers will be responsible for working closely with the Government Evaluation Team to develop a test and evaluation strategy that demonstrates the system and individual system modules have achieved the desired performance goals.

BLADE Phase 1 testing will be conducted using a non-real-time software-based testbed environment. Performer-developed jamming solutions will be tested against Government-developed communication threats. The Government will provide a full description of the testbed environment including reference computing platform and all APIs needed to interface with the test platform. Performers must provide all software (with licenses) needed to execute their solution on the reference platform. Limits will be placed on computation time, memory, storage, and transmit energy to ensure that algorithms developed in Phase 1 can be feasibly implemented in real-time systems in Phase 2 and Phase 3. Prior to actual testing, the Government will offer a number of controlled practice-runs to verify compliance with the API and hardware interfaces. If a performer’s proposed solution does not fall within the test framework specified by the Government, or has systems with unique aspects that need special test set-ups to demonstrate, the performer should recommend a testing framework that allows their solution to be evaluated against the performance goals referenced in the classified addendum. Such recommendations will be considered at the Government’s discretion.

BLADE Phase 2 and Phase 3 testing will be performed using real-time over-the-air methods. Performer developed jamming systems will be tested against Government developed communication threats.

For Phase 2, each performer’s system must run in real-time but the processing components and the RF hardware need not be of any particular form factor. Performers are to provide all software and hardware required to demonstrate their system. The use of multiple nodes to demonstrate the efficacy of networked operation is expected, although operation using a standalone node should also be demonstrated.

For Phase 3, the prototype system(s) must run in real-time and in a form factor suitable for a vehicle-mounted application (see above). The use of multiple nodes to demonstrate the efficacy of networked operation is expected.

At the completion of each program phase, a Government Evaluation Team will evaluate BLADE performance against a set of performance parameters described in the classified addendum. Proposers should state intermediate performance goals for Phase 1 and 2 and explain how they help measure progress towards achieving the overall BLADE program goals.

Schedule

Proposers should propose a detailed schedule that is consistent with their program plan. In addition, the following set of milestones and their approximate timing must be integrated into the proposer’s schedule. Schedules will be synchronized across performers, as required, and monitored/revised as necessary throughout the BLADE program.

Phase 1 Months After Contract

(MAC)

Kick-off Meeting (PI Meeting) 1 Test and Evaluation Plan Review 3 Preliminary Architecture and Algorithm Design Review 4 Mid-term Technology Assessment (PI Meeting) 8 Initial System-Testbed Integration 9 Evaluation Dry Runs 10 Final System-Testbed Integration 12 Final System Architecture and Algorithm Review 12 Government Test and Evaluation (Lab Tests) 14 Phase 1 Final Review 15

Phase 2 MAC

Kick-off Meeting (PI Meeting) 1 Test and Evaluation Plan Review 3 Preliminary Architecture and Algorithm Design Review 5 Mid-term Technology Assessment (PI Meeting) 8 Breadboard System Design Review 10 Evaluation Dry Runs 11 Final Breadboard System Integration 13 System Review 15 Government Test and Evaluation (Over-the-Air Tests) 17 Phase 2 Final Review 18

Phase 3 MAC

Kick-off Meeting (PI Meeting) 1 Test and Evaluation Plan Review 3 Preliminary Architecture and Algorithm Design Review 5 Mid-term Technology Assessment (PI Meeting) 8 Prototype System Design Review 10 Evaluation Dry Runs 11 Final Prototype System Integration 13 System Review 15 Government Test and Evaluation (Over-the-Air Field Tests) 17 Phase 3 Final Review 18

As part of the BLADE program, a minimum of two Principal Investigator (PI) meetings will occur per phase. A joint kickoff will serve as the first PI meeting and will focus on communicating proposed technical approaches, functional architectures and interfaces, as well as to review final Government evaluation results from the prior phase. Around mid-way through each phase, a second PI meeting will occur focused on reviewing current technical approaches, system architectures, and accomplishments of each performer.

The locations for the technical interchange, PI meetings, and other events will be specified by the Government. In general, for budgeting travel, assume that technical interchanges will be held either in Washington, D.C., or at the performer’s location.

Assume that PI meetings will be held alternately at East and West Coast locations. In addition to site visits, regular teleconference meetings are encouraged to enhance communications with the Government team. Should important issues arise between program reviews, the Government team will be available to support informal interim technical interchange meetings.

Deliverables

Performers should propose to provide the following deliverables:

• Program Plan –The initial Program Plans for each Phase shall be based upon the performers’ proposals and work prior to the Kickoff meeting, and shall be presented at the Kickoff Meeting. The Program Plans shall be revised and submitted for approval within one month after the Kickoff Meeting for each phase. The Program Plans shall be in Microsoft Project format.

• Software Development Plan (SDP) – The SDPs for each phase shall be based upon the performers’ proposals and shall be presented at the Kickoff. The SDP shall describe the scope of the software development effort, reference any applicable documents, describe the development process, describe the development environment, and include documentation of the software development team and organization. The SDPs shall be revised and submitted for approval within one month after the Kickoff Meeting for each phase.

• Architecture and Algorithm Design Document - Initial design documentation for each phase shall be presented at the Architecture and Algorithm Design Review meeting for that phase. The document shall be revised and submitted for approval within one month after the System Review for each phase. A revised document reflecting any design changes subsequent to the initial document shall be submitted within one month after the end of each phase. The architecture documentation shall describe the system in sufficient detail to permit an engineer to correctly implement the system without consulting the system designer. The algorithm documentation shall describe the algorithms in sufficient detail to permit a software engineer to correctly code the algorithms without consulting the algorithm designer.

• Software Documentation - Software documentation shall be provided within one month after the end of each phase documenting source code, hardware description language specifications, system diagrams, part numbers and other data necessary to maintain and to produce copies of the software.

• Software – All computer software developed or delivered under the BLADE program must be delivered as source and as object (executable) code. Include the source listings and source code for the target computer systems. Delivered software under this effort is to be completely maintainable and modifiable with no reliance on any non-delivered computer programs or documentation. For all computer software purchased or licensed for use as a component of the software to be delivered, arrangements shall be made for licensing and maintenance agreements to be transferred to the Government at no additional cost upon the completion of the Performer’s work under any contract awarded under this BAA.

• Hardware - At the conclusion of Phase 3, the complete prototype system hardware shall be delivered. The delivered system shall be the same fully functional system used to perform the Phase 3 final performance tests and evaluations. The delivery is to include sufficient documentation so as to be completely operable, maintainable and modifiable with no reliance on any non-delivered hardware or hardware documentation developed or procured under the BLADE program.

• Slide Presentations – Annotated slide presentations shall be submitted within one month after the program Kickoff Meeting and each review, and draft presentations will be due one week before the Kickoff meeting and each review.

• Monthly Progress Report – A monthly progress report describing planned progress and resources, actual progress made and resources expended, and any issues requiring the attention of the Government shall be provided within 10 days after the end of each month.

• Final Report – The final report for each phase shall concisely summarize the effort conducted during that phase and in previous phases, if any, and shall be submitted within one month after the end of each phase.

All deliverables shall be in the performer’s format except as noted. All reporting should be delivered as required in Section VI.C.

Intellectual Property

It is desired that all noncommercial software (including source code), software documentation, hardware designs and documentation, and technical data generated under the BLADE program be provided as a deliverable to the Government with Unlimited Rights (procurement contract) or, at a minimum, with Government Purpose Rights (Other Transaction Agreement). Therefore, to the greatest extent feasible, proposers should not include background proprietary software and technical data as the basis of their proposed approach. If proposers desire to use proprietary software or technical data or both as the basis of their proposed approach, in whole or in part, they should: 1) clearly identify such software/data and its proposed particular use(s); 2) explain how the Government will be able to reach its program goals (including transition) within the proprietary model offered; and 3) provide possible nonproprietary alternatives in any area that might present transition difficulties or increased risk or cost to the Government under the proposed proprietary solution.

Proposers expecting to use, but not to deliver, commercial open source tools or other materials in implementing their approach may be required to indemnify the Government against legal liability arising from such use.

All references to "Unlimited Rights" or "Government Purpose Rights" are intended to refer to the definitions of those terms as set forth in the Defense Federal Acquisition Regulation Supplement (DFARS) Part 227. (See also section VI.B.2. below, “Intellectual Property,” including subsections c. and d.).

Cross Technical Area Considerations All performers under the BLADE program are expected to work together to ensure success of the program. To that end, all performers will have an Associate Contractor Agreement clause incorporated into the resulting award, in order to allow the free and open exchange of information. In part, the clause will state the following, “this clause is intended to ensure that there will be appropriate coordination and integration of work by the BLADE associated contractors to ensure complete compatibility between software components, system architecture, equipment, data, test framework, and other program elements for the BLADE program, to prevent unnecessary duplication of effort, and to maximize commonality”.

II. AWARD INFORMATION

Multiple awards are anticipated. The amount of resources made available for award will depend on the quality of the proposals received and the availability of funds. Proposals identified for negotiation may result in a procurement contract or other transaction agreement.

In addition, the Government reserves its rights to the following:

• to select for negotiation all, some, one, or none of the proposals received in response to this solicitation,

• to make awards without discussions with proposers,

• to conduct discussions if it is later determined to be necessary,

• to segregate portions of resulting awards into pre-priced options,

• to accept proposals in their entirety or to select only portions of proposals for award,

• to fund proposals in phases with options for continued work at the end of one or more of the phases,

• 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; and,

• to remove proposers from award consideration should the parties fail to reach agreement on award terms, conditions and cost/price within a reasonable time or the proposer fails to timely provide requested additional information.

As of the date of publication of this BAA, DARPA expects that research goals for this BAA cannot be met by proposers intending to perform 'fundamental research', i.e., 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. Notwithstanding this statement of expectation, DARPA is not prohibited from considering and selecting research proposals that, regardless of the category of research proposed, still meet the BAA criteria for submissions. In all cases, the contracting officer shall have sole discretion to select award instrument type and to negotiate all instrument provisions with selectees.

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.

1. Historically Black Colleges and Universities, Small Businesses, Small Disadvantaged Businesses and Minority Institutions

Historically Black Colleges and Universities (HBCUs), Small Businesses, Small Disadvantaged Businesses and Minority Institutions (MIs) are encouraged to submit proposals and join others in submitting proposals; however, no portion of this announcement will be set aside for these organizations’ participation due to the impracticality of reserving discrete or severable areas of this research for exclusive competition among these entities.

2. Federally Funded Research and Development Centers (FFRDCs) and Government entities

FFRDCs and Government entities (e.g., Government laboratories, military educational institutions, etc.) are subject to applicable direct competition limitations and cannot propose to this BAA in any capacity (as prime or sub) unless they address the following conditions.

• FFRDCs must clearly demonstrate that the proposed work is not otherwise available from the private sector AND must also provide a letter on letterhead from their sponsoring organization citing the specific authority establishing their eligibility to propose to Government solicitations and compete with industry, in compliance with the associated FFRDC sponsor agreement terms and conditions. This information is required for FFRDCs proposing to be prime or subcontractors.

• Government entities must clearly demonstrate that the proposed work is not otherwise available from the private sector and provide written documentation citing the specific statutory authority (as well as, where relevant, contractual authority) establishing their ability to propose to Government solicitations.

• 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 eligibility submissions on a case-by-case basis;

however, the burden to prove eligibility for all team members rests solely with the proposer.

3. Foreign Participation Foreign participants and/or individuals may participate to the extent that such participants comply with any necessary Non-Disclosure Agreements, Security Regulations, Export Control Laws, and other governing statutes applicable under the circumstances.

4. Procurement Integrity, Standards of Conduct, Ethical Considerations, and Organizational Conflicts of Interest

Current federal employees are prohibited from participating in particular matters involving conflicting financial, employment, and representational interests (18 USC 203, 205, and 208). The DARPA Program Manager for this BAA is Dr. Yiftach Eisenberg.

Once proposals have been received, and prior to the start of proposal evaluations, the Government will assess potential conflicts of interest and will promptly notify the proposer if any appear to exist. Note the Government assessment does NOT affect, offset, or mitigate the proposer’s own duty to give full notice and planned mitigation for all potential organizational conflicts, as discussed below.

All Proposers and proposed subcontractors must affirm whether they are providing scientific, engineering, and technical assistance (SETA) or similar support to any DARPA technical office(s) through an active contract or subcontract. All affirmations must state which office(s) the Proposer supports and identify the prime contract numbers. Affirmations shall be furnished at the time of proposal submission. All facts relevant to the existence or potential existence of organizational conflicts of interest (FAR 9.5) must be disclosed. The disclosure shall include a description of the action the Proposer has taken or proposes to take to avoid, neutralize, or mitigate such conflict. In accordance with FAR 9.503 and without prior approval or a waiver from the DARPA Director, a Contractor cannot simultaneously be a SETA and Performer.

Proposals that fail to fully disclose potential conflicts of interests and/or do not have plans to mitigate this conflict will be rejected without technical evaluation and withdrawn from further consideration for award.

If a prospective Proposer believes that any conflict of interest exists or may exist (whether organizational or otherwise), the Proposer should promptly raise the issue with DARPA by sending Proposer's contact information and a summary of the potential conflict by email to the mailbox address for this BAA at DARPA-BAA-10-79@darpa.mil, before time and effort are expended in preparing a proposal and mitigation plan. If, in the sole opinion of the Government after full consideration of the circumstances, any conflict situation cannot be effectively mitigated, the proposal may be rejected without technical evaluation and withdrawn from further consideration for award under this BAA.

B. Cost Sharing or Matching

Cost sharing is not required for this particular program; however, cost sharing will be carefully considered where there is an applicable statutory condition relating to the selected funding instrument (e.g., for any Other Transaction Agreement under the authority of 10 U.S.C. 2371). Cost sharing is encouraged where there is a reasonable probability of a potential commercial application related to the proposed research and development effort.

C. Other Eligibility Requirements

1. Ability to Support Classified Design and Development Development, integration and testing of the BLADE system will require all performers to comply with the BLADE Security Classification Guide (see Section IV for instructions on requesting the SCG).

At time of proposal submission, all personnel involved in the classified design and development work must have, at a minimum, a SECRET level DoD clearance AND the facility where the design and development work will be performed must be approved for classified work and storage. This also requires that all computers, work stations, and other information processing equipment to be used for the classified design and development work be approved at a minimum for SECRET level work and storage.

Proposers proposing against this BAA must provide their CAGE code and security point(s) of contact in their proposals.

Prime proposers may incorporate universities and other un-cleared subcontractors developing fundamental algorithms provided that all applicable security guidelines and ITAR regulations are satisfied.

IV. APPLICATION AND SUBMISSION INFORMATION

A. Address to Request Application Package

This document, the attached DD form 254 (Contract Security Classification Specification), the Classified Addendum to this BAA, and the BLADE Program Security Classification Guide (both provided under separate cover), contain all the information required to submit a proposal. No additional forms, kits, or other materials are needed.

This notice constitutes the total BAA. No additional information is available, nor will a formal Request for Proposal (RFP) or additional solicitation regarding this announcement be issued. Requests for same will be disregarded.

To obtain a copy of the Classified Addendum and the BLADE Program Security Classification Guide, proposers must send a request to the BAA mailbox and include the following information:

Company name Classified mailing address CAGE Code Facility Security Officer (FSO) name and phone number Technical POC name and phone number

Note: DARPA will verify the facility clearance (including the ability to safeguard information) and the clearance of the recipient before mailing the classified material. If the required clearances are not available, the addendum/Program Security Classification Guide will NOT be sent!

B. Content and Form of Application Submission

1. Proposal Information DARPA anticipates that proposals may be unclassified, unclassified with a classified appendix, or entirely classified. In all cases where classified information is provided, proposers must provide seven copies of their classified proposal information including appendix (five hard copies and two on CD or DVD) and provide them per the instructions in Section VI.B.1. – Security Classification and Proprietary Issues. For unclassified proposals which include a classified appendix, proposers must notify DARPA by sending an email to the BAA mailbox. These notifications must include the Technical POC name, organization and title of the unclassified proposal.

DARPA will employ an electronic upload submission system for all UNCLASSIFIED responses to this BAA. See also Section IV.F. Other Submission Requirements below.

Responding to this announcement requires completion of an online cover sheet for each proposal prior to submission. To do so, the proposer must go to https://www.csc-ballston.com/baa/index.asp?BAAid=10-79 and follow the instructions there. Upon completion of the online cover sheet, a Confirmation Sheet will appear along with instructions on uploading proposals. The Confirmation Sheet will be used as the Cover Sheet for the proposal and will contain the information outlined below in Proposal Section 1.1. If a proposer intends to submit more than one proposal, a unique UserId and password must be used in creating each cover sheet. Once the upload is complete, a confirmation will appear and should be printed for the proposer’s records.

Since proposers may encounter heavy traffic on the web server, they SHOULD NOT wait until the day the proposal is due to fill out a coversheet and submit the proposal! Technical support for the web server/submission issues is typically available during regular business hours (9:00 – 5:00 ET, Monday-Friday).

DO NOT ENTER OR UPLOAD ANY CLASSIFIED MATERIAL AT https://www.csc-ballston.com/baa/index.asp?BAAid=10-79!

2. Proposal Preparation and Format The proposal shall be delivered in two volumes, Volume 1 (technical proposal) and Volume 2 (cost proposal). Proposals not meeting the format described in this BAA may not be reviewed.

All uploaded proposals must be zipped and encrypted using Winzip or PKZip with 256-bit AES encryption. Only one zipped/encrypted file will be accepted per proposal.

Proposals which are not zipped/encrypted will be rejected by DARPA. An encryption password form must be completed and emailed to the BAA mailbox at the time of proposal submission. See https://www.CSC- Ballston.com/baa/Encryption_Instructions.htm for the encryption password form and additional encryption information. Note: the word “PASSWORD” must appear in the subject line of the above email. Failure to provide the encryption password will result in the proposal not being evaluated.

Volume 1 – Technical Proposal

The technical proposal shall include the following sections. Each page is 8-1/2 by 11 inches with type not smaller than 12 point (charts may use 10 pt font), margins not smaller than 1 inch, and line spacing not smaller than single-spaced. All submissions must be in English.

Page limits:

a. Proposals for end-to-end systems must abide by the maximum page counts for the individual elements of the proposal as shown in braces { } for each individual section below.

b. Proposals addressing one or more individual modules may divide the page counts for each proposal element as desired HOWEVER; the overall page count for section 2.1 through section 2.13 of the Technical Volume cannot exceed 30 pages.

Proposal Section 1. Administrative

1.1 Confirmation Sheet/Cover Sheet

As described above, this cover sheet will contain the following information:

• BAA number;

• Module name(s) or Full System Proposal

• Proposal title;

• Technical point of contact including: name, telephone number, electronic mail address, fax (if available) and mailing address;

• Administrative point of contact including: name, telephone number, electronic mail address, fax (if available) and mailing address;

• Summary of the costs of the proposed research, including total base cost, estimates of base cost in each year of the effort, estimates of itemized options in each year of the effort, and cost sharing if relevant;

• Contractor’s reference number (if any)

• Contractor's type of business, selected from among the following categories:

o WOMEN-OWNED LARGE BUSINESS, o OTHER LARGE BUSINESS, o SMALL DISADVANTAGED BUSINESS [Identify ethnic group from among the following: Asian-Indian American, Asian-Pacific American, Black American, Hispanic American, Native American, or Other], o WOMEN-OWNED SMALL BUSINESS, o OTHER SMALL BUSINESS, o HBCU, o MI, o OTHER EDUCATIONAL, o OTHER NONPROFIT, OR o FOREIGN CONCERN/ENTITY.

1.2 Table of contents {No page limit}

Proposal Section 2. Technical Details Ensure that each section provides the detailed discussion of the proposed work necessary to enable an in-depth review of the specific technical and managerial issues.

Specific attention must be given to addressing both risk and payoff of the proposed work that make it desirable to DARPA.

2.1 Summary Chart {1 chart}:

Provide a one-slide summary of the proposal that effectively and succinctly conveys the main objective, key innovations, expected impact, and other unique aspects of the proposal.

2.2 Innovative claims for the proposed research {1 Page}:

This page is the centerpiece of the proposal and should succinctly describe the unique proposed approach and contributions. This section may also briefly address the following topics:

a. Problem Description. Provide a concise description of the operational and technical problems to be solved.

b. Research Goals. Identify specific research goals. Goals should address the technical challenges of the effort.

c. Expected Impact. Describe the expected impact of your research.

2.3 Proposal Roadmap {2 Pages}:

The roadmap provides a top-level view of the content and structure of the proposal. It contains a synopsis for each of the roadmap areas defined below, which should be elaborated elsewhere. It is important to make the synopses as explicit and informative as possible. The roadmap must also cross-reference the proposal page number(s) where each area is elaborated. The required roadmap areas are:

a. Main goals of the proposed research.

b. Tangible benefits to end users (i.e., benefits of the capabilities afforded if the proposed technology is successful).

c. Critical technical barriers (i.e., technical limitations that have, in the past, prevented achieving the proposed results).

d. Main elements of the proposed technical approach.

e. Basis of confidence (i.e., rationale that builds confidence that the proposed approach will overcome the technical barriers).

f. Nature and description of end results to be delivered to DARPA. In what form will results be developed and delivered to DARPA and the scientific community?

Note that DARPA encourages experiments, simulations, specifications, proofs, etc. to be documented and published to promote progress in the field.

Proposers should specify both final and intermediate products.

g. Cost and schedule of the proposed effort.

2.4 Technical Approach {20 pages}:

Provide a detailed description of the technical approach. Include a description of state of the art approaches and the limitations that relate to each area addressed by the proposal. This section will serve as the primary expression of the proposers’ scientific and technical ideas. The technical approach descriptions should be separated by program phase. This section should include the following:

a) A description of the problem to be solved, including i) the operational problem that the BLADE technologies developed under this program are intended to address, and ii) how existing jamming systems operate and their limitations.

Individual module proposers are also expected to address these issues.

b) For full system proposals, a description of the detailed technical approach that addresses the three modules described in the Program Scope section, as well as the proposed design approach, system architecture, and integration plan, including integration of potential third-party software modules. Identify any relevant technologies that will be leveraged by the BLADE system but not explicitly developed under this program, such as geo-location, emitter identification, networking, etc. State any assumptions about leveraged technologies, such as networking data rates and latencies, geo-location accuracy, etc.

For module proposals, a description of the detailed technical approach that addresses the module functionality described in the Program Scope section, as well as the proposed design approach, module architecture, and plans for integration into a real-time system. State any assumptions about interfaces and information provided from other system modules, as well as any relevant technologies that will be leveraged by the proposed module but not explicitly developed under this program.

c) A description of how and why the proposed approach will be able to achieve the stated performance goals for the overall program given in the classified addendum. In addition, proposers should state their intermediate performance goals for Phases 1 and 2. Provide evidence or analyses that back up the claims.

Include evidence or analyses to show that real-time operation can be achieved in Phases 2 and 3 and that suitable size, weight and power specifications can be achieved in Phase 3. Individual module proposers are also expected to address these issues, in so far as they are relevant to their proposed modules.

d) A discussion of how the proposed work will evolve from the Phase 1 simulation-based system, to the Phase 2 breadboard system, to the Phase 3 prototype system, including potential transition strategies to integrate BLADE algorithms and processing components into existing EW platforms for ground vehicles and optionally, a Group 3 UAS, such as the Shadow. Individual module proposers are also expected to address these issues, in so far as they are relevant to their proposed modules.

2.5 Statement of Work (SOW) {5 pages}:

In plain English, clearly define the technical tasks/subtasks to be performed, their durations, and dependencies among them. For each task/subtask, provide:

• A general description of the objective (for each defined task/activity);

• A detailed description of the approach to be taken to accomplish each defined task/activity;

• Identification of the primary organization responsible for task execution

(prime, sub, team member, by name, etc.);

• The completion criteria for each task/activity - a product, event or milestone that defines its completion.

• Define all deliverables (reports, data, software, hardware, prototypes, etc.) to be provided to the Government in support of the proposed research tasks/activities. Include expected delivery date for each deliverable.

• Clearly identify any tasks/subtasks (prime or subcontracted) that will be accomplished on-campus at a university.

Note: The SOW should be developed so that each phase of the program is separately defined.