HR001119S0023.pdf

HR001119S0023

Broad Agency Announcement Digital RF Battlespace Emulator (DRBE)

Microsystems Technology Office

February 12, 2019

Foreword

In June 2017, the Defense Advanced Research Projects Agency (DARPA) announced the Electronics Resurgence Initiative (ERI), a five-year, upwards of $1.5B investment in the future of domestic, U.S. Government (USG), and Department of Defense (DoD) electronic systems.

ERI recognizes and addresses long-foreseen obstacles to Moore’s Law – the transistor scaling trend that has allowed for 50 years of rapid progress in electronics. To address these issues, ERI kicked off a major investment that draws on the contributions of several ongoing DARPA programs and creates new, long-term technology investments. Through novel research and development (R&D) in semiconductor materials and integration, architectures, and designs, ERI programs will promote circuit specialization as a complement to transistor scaling. The success of these efforts will depend on constructively enmeshing the technology needs and capabilities of the defense enterprise with the commercial and manufacturing realities of the electronics industry.

ERI Phase II, launched in 2018, will build on existing ERI programs with the goal of supporting a domestic semiconductor manufacturing industry that can implement specialized circuits, demonstrate that those circuits can be trusted through the supply chain and are built with security in mind, and are ultimately available to both DoD and commercial sector users.

This Digital RF Battlespace Emulator (DRBE) BAA supports these Phase II objectives. DRBE will develop the domain-specific computing architectures needed to perform high-fidelity, real-time emulation of radiofrequency (RF) environments, providing a key tool for the 24/7 testing and training of advanced systems such as cognitive radar. By leveraging specialization, DRBE will address the increasing requirements for developing intelligent Department of Defense (DoD) systems. Commercial applications of the high throughput, low latency computing architectures are also expected, particularly in the area of big-data exploitation.

Together with the ongoing ERI programs, including the “ERI Page 3 Investments” announced in 2017, ERI Phase II is the next step in creating a more robust, secure, and heavily automated electronics industry. This industry will provide a foundational contribution both to U.S. national security and to the needs and ambitions of the commercial sector, with new capabilities emerging in the 2025 to 2030 timeframe. DARPA seeks to receive proposals from entities that can help to achieve this goal. For reference, an updated list of ERI programs, solicitations, and events is available via https://www.darpa.mil/work-with-us/electronics-resurgence-initiative.

https://www.darpa.mil/work-with-us/electronics-resurgence-initiative

Table of Contents

Foreword

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description A. Background B. Technical Areas C. Program Structure, Schedule, and Milestones D. Deliverables E. Government Furnished Equipment/Property/Information F. Intellectual Property

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

III. Eligibility Information A. Eligible Applicants

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

B. Organizational Conflicts of Interest C. Cost Sharing/Matching D. Other Eligibility Criteria

1. Collaborative Efforts

2. Ability to Support Classified Development

3. Associate Contractor Agreement Clause

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

1. Full Proposal Format

2. Proprietary Information

3. Security Information

a. Program Security Information

b. Unclassified Submissions

4. Disclosure of Information and Compliance with Safeguarding Covered Defense

Information Controls

5. Human Research Subjects/Animal Use

6. Approved Cost Accounting System Documentation

7. Section 508 of the Rehabilitation Act (29 U.S.C. § 749d)/FAR 39.2

8. Small Business Subcontracting Plan

9. Intellectual Property

a. For Procurement Contracts

b. For All Non-Procurement Contracts

10. Patents

11. System for Award Management (SAM) and Universal Identifier Requirements

12. Funding Restrictions

C. Submission Information

1. Submission Dates and Times

a. Proposal submission deadline: April 1, 2019

b. Frequently Asked Questions (FAQ)

2. Proposal Submission Information

a. For Proposers Requesting Contracts or Other Transaction Agreements

b. Classified Submission Information

3. Other Submission Requirements

V. Application Review Information A. Evaluation Criteria

1. Overall Scientific and Technical Merit

2. Plans and Capability to Accomplish Technology Transition

3. Cost Realism

4. Potential Contribution and Relevance to the DARPA Mission

B. Review and Selection Process

1. Review Process

2. Handling of Source Selection Information

3. Federal Awardee Performance and Integrity Information (FAPIIS)

VI. Award Administration Information A. Selection Notices

1. Proposals B. Administrative and National Policy Requirements

1. Meeting and Travel Requirements

2. FAR and DFARS Clauses

3. Controlled Unclassified Information (CUI) on Non-DoD Information Systems

4. Representations and Certifications

C. Reporting D. Electronic Systems

5. Wide Area Work Flow (WAWF)

6. i-Edison

VII. Agency Contacts VIII. Other Information

A. Proposers Day B. Protesting

ATTACHMENT 1: Cost Volume Proposer Checklist ATTACHMENT 2: Proposal Summary Slide Template ATTACHMENT 3: Task Staffing Summary Template

PART I: OVERVIEW INFORMATION

Federal Agency Name: Defense Advanced Research Projects Agency (DARPA), Microsystems Technology Office (MTO)

Funding Opportunity Title: Digital RF Battlespace Emulator (DRBE) Announcement Type: Initial Announcement Funding Opportunity Number: HR001119S0023 Catalog of Federal Domestic Assistance Numbers (CFDA): Not applicable Dates: (All times listed herein are Eastern Time) o Posting Date: February 12, 2019 o Proposers Day: February 13, 2019

Live streaming video beginning at 1 PM eastern time:

https://www.youtube.com/watch?v=Y6YZ0rB0qSM o FAQ Submission Deadline: March 18, 2019 o Proposal Due Date: April 1, 2019 o Estimated period of performance start: September 2, 2019

Concise description of the funding opportunity:

The Digital RF Battlespace Emulator (DRBE) program seeks the creation of a new breed of High Performance Computer (HPC), dubbed “Real-time HPC” (RT-HPC), which effectively balances computational throughput with extreme low latency to create the world’s first largescale virtual radiofrequency (RF) test range. The DRBE system will enable numerous real RF systems (such as radars) to interact with each other in a fully closed loop RF environment. Computationally, DRBE will be responsible for calculating the interactions of high bandwidth RF waveforms with emulated objects in a physical environment (such as ground clutter and radar target returns).

Anticipated individual awards: Multiple awards are anticipated in both TA1 and TA2.

Proposals for TA3 ARE NOT currently being requested.

Anticipated funding type: 6.2 Types of instruments that may be awarded: Procurement contract or other transaction Agency contact:

o Mr. Paul Tilghman, Program Manager BAA Coordinator: HR001119S0023@darpa.mil

DARPA/MTO

ATTN: HR001119S0023

675 North Randolph Street Arlington, VA 22203-2114 https://www.youtube.com/watch?v=Y6YZ0rB0qSM mailto:name@darpa.mil

PART II: 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 the procedures under Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016 and 2 C.F.R. § 200.203. Any negotiations and/or awards will use procedures under FAR 15.4, Contract Pricing. Proposals received as a result of this BAA shall be evaluated in accordance with evaluation criteria specified herein through a scientific review process.

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

The Microsystems Technology Office at DARPA seeks innovative proposals in the areas of real-time high performance computing, computational accelerators, domain specific computing architectures, non-traditional computing, and digital emulation. Proposed research should investigate innovative approaches that enable revolutionary advances. Specifically excluded is research that primarily results in evolutionary improvements to the existing state of practice.

The core DRBE microelectronics research challenge arises from the simultaneous requirements for extremely low latency and high computational throughput. Radiofrequency signals require only 3.3 µs to propagate at the speed of light from a transmitter to a receiver 1 km away. Thus, a realistic emulation of signals transmitted by a virtual transmitter to a virtual receiver 1 km away must be able to emulate all the signal interactions that would occur in the intervening environment in less than 3.3 µs. The computational load is large, scaling proportionally with the square of the number of RF systems times the total RF bandwidth. Existing processors emphasize either high computational density or low latency, but not both. At DRBE’s scale (number of systems and bandwidth), both the data transfer and the computational requirement is orders of magnitude more than an existing integrated circuit can provide.

A. Background

Due to cost, system complexity, and limited availability of military ranges, the future testing, evaluation and training of military systems will increasingly take place in completely virtual environments. Moreover, the increasing adoption of artificial intelligence (AI) requires orders of magnitude more test and training time. This paradigm, often called Live, Virtual, Constructive (LVC), has already begun to see significant adoption in training modern fighter aircraft pilots, where simulators are increasingly used to augment real-world aircraft flight hours. Since today’s LVC systems rely on conventional computing to create their virtual world they lack the veracity to accurately model a large number of high bandwidth inputs and outputs to and from complex sensor systems such as the radars and EW (Electronic Warfare) systems critical to modern warfare. As these systems themselves increasingly adopt the use of AI, the ability to conduct 24/7/365 training and testing of them becomes increasingly crucial.

http://www.fbo.gov/

DRBE will develop a real-time High Performance Computer (RT-HPC) and the associated domain-specific hardware accelerators needed to perform high-fidelity emulation of the RF environment in real time. This will result in 1-2 orders of magnitude improvement over the state of the art, both in terms of number of waveform interactions (i.e., fidelity), and the number of connected systems and signal bandwidth (i.e., scale). The intersection of real-time computing with high computing capacity is not possible with today’s existing “general-purpose” computing.

While the DRBE program will create and apply innovations in processing architectures to the field of RF emulation, it is believed that that such advances are important in other applications of both military and commercial relevance. As such, DARPA seeks computing architectures with more than one application in high throughput, low latency computing.

DRBE will also create a largescale, real-time, virtual RF test range to enable the development of cognitive radar, EW, and distributed systems, as well as more frequent and more effective testing of conventional EW. DRBE will provide the scale, fidelity, and complexity necessary to match how EW is employed operationally. DRBE will allow many RF systems to interact and create a realistic, complex, reactive signal environment which faithfully reproduces fielded conditions.

Currently, this scale and fidelity is available only through large-force exercises but not through chamber testing, open-air ranges, or modeling and simulation.

Upon completion of the DRBE program, the DRBE test range will become a key part of the Department of Defense’s development and test infrastructure, ushering in an era of system development and test based on 24/7/365 data generation. This will enable big-data exploitation now common in the application of Artificial Intelligence (AI) to other modalities (such as computer game play).

A study evaluated classified EW scenarios and derived unclassified computing metrics for the future DRBE test range and RF-HPC. DRBE requires 70-200 waveform interactions (i.e., reflections) between transmitter and receiver, and 80-200 connected systems each producing on average 1-2 GHz of RF input and output. The total computation requirement is estimated to be 20 PFLOP/s, 2 Tb (terabits) of memory, and 150 TB/s (terabytes per second) with a total system latency limit of 3.3 s.

B. Technical Areas

The program is divided into 3 technical areas (TAs). The color-coded figure below illustrates how the primary areas of responsibility for each TA are allocated across the complete system.

This BAA seeks proposals only for TA1 and TA2. A single organization may propose to both TA1 and TA2 but must submit separate and independent proposals for each TA. A single organization may receive awards for both TA1 and TA2. The TA3 effort will not begin until Phase 3 of the program and thus proposals are not being requested through this BAA.

Figure 1 – DRBE Technical Areas

Digital RF Emulation Primer This section provides a brief overview of digital RF emulation. The intent is to acquaint potential proposers with the general needs of a digital RF emulation system. This is by no means meant to provide an exhaustive overview, and proposers would do well to supplement the general overview provided here with relevant team member expertise in their proposals.

A digital RF emulator is a computing system which consumes and produces digitized RF inputs and outputs. The goal of the emulator is to mimic the response of a physical environment between RF transmitters (inputs) and RF receivers (outputs). The unique response between each transmitter and receiver is called the channel response. A depiction of RF emulation for a simple 4x4 set of transmitters and receivers with overlapping frequency bands is shown in Figure 2.

Figure 2 – An example showing the contributions from each of four transmitters to each of four receivers in a fully connected configuration (i.e., all transmitters and receivers operate at overlapping frequencies).

To faithfully mimic the complexity of an RF environment a digital channel emulator such as DRBE should be able to capture at least 4 classes of environmental response:

1. Propagation: A unique amplitude, delay, phase, and Doppler response between each transmitter and receiver pair with overlapping frequencies (receivers not tuned to frequency bands of specific transmitters do not need to waste calculation on a null response) which reflects the geometry between the pair. This calculation grows with , 𝑁2 where N is the number of transmitters and receivers.

2. Multipath & Clutter: Between the above noted transmit receiver pairs, the signal invariably encounters objects (i.e., scatterers) which disturb the line-of-sight propagation of the signal. This calculation grows with , where N is the number of transmitters and 𝑁2 receivers.

3. Mono-static Radar Cross Section (RCS) Response: Radar signals that encounter moving platforms, such as aircraft, produce a response back to the same radar (i.e., monostatic) which is dependent on the material, shape, and relative orientation, to enable the radar to locate, range, and track the aircraft. Simplistic approaches will model the aircraft as a single-point reflector with the nature of the reflection (i.e., amplitude and phase) dependent on the orientation. More sophisticated approaches will capture a near continuous model of reflection from an aircraft. This calculation grows with , where P 𝑃2 is the number of platforms emulated.

4. Multi-static Radar Cross Section (RCS) Response: RCS responses can also be measured multi-statically; that is, a single platform can be illuminated by multiple radars or other background emitters operating in the environment, such as TV stations, and received and located by multiple non-collocated receivers. This calculation grows with , where P is 𝑃3 the number of platforms emulated.

Chann el Matri x

T X

N o is e

As shown above in the above list of emulated phenomenology, the most frequent type of calculation is the interaction of a signal with a scatterer or reflector. In the most straightforward case, this can be digitally modeled by a Finite Impulse Response (FIR) filter, making it the workhorse of this problem domain. Additional details such as Doppler, temporal resolution, and higher-fidelity interactions layer complexity onto this problem’s core calculation.

While commercial emulators exist, the market is focused on communications, and thus they lack the veracity to emulate the radar-centric environment described above. Additionally they fail to achieve the necessary scale due to limitations of COTS processing used in such systems.

Technical Area 1 (TA1) – System Integrator The goal of TA1 is to leverage the RT-HPC designed by TA2 to create the DRBE RF emulation capability. As such, TA1 performers are responsible for the design and integration of an overall system-level capability. This is to minimally include: supporting tools, specifications and interfaces, interfacing hardware, procedures for sanitization of classified waveforms stored during operations, as well as a final demonstration of the new paradigm enabled by DRBE. RF emulation focused metrics (those in Table 1) guide the overall TA1 solution.

TA1 responses should address key components of the system called out in Figure 1 in addition to any other components unique to the proposed system architecture.

1. Scenario Design & Control These tools allow scenario designers to emplace specific systems within a geographic area of regard, creating the necessary commands, parameters, or other specifications to allow the RT- HPC to carry out the scenario in real-time. Numerous such tools of varying capability exist across the DoD without standardization of inputs and/or outputs. It is desirable that responses to this BAA leverage existing tools to the extent possible to achieve the necessary tool-suite.

Once the scenario is designed and compiled, the Scenario Controller executes the scenario, stepping through each discrete time step. Two approaches are possible. The first prescripts the entire environment. The second allows for some (or all) platforms in the environment to make independent and real-time decisions about their location (heading, velocity, speed). While the latter category allows for much more flexibility, care must be paid to address how the system completes necessary calculations in real time.

2. Radio Interface & API DRBE should be able to interface with external systems under test (SUTs), both digital and analog. In the former case, TA1 should prescribe a digital Application Programming Interface (API). In the latter case, a radio interface is required to digitize the SUTs inputs and return the system outputs to analog. Care must be paid to the type of system being interfaced with DRBE.

For a traditional single-element RF aperture, one DRBE input is equivalent to one antenna.

However, interfacing with Electronically Scanned Arrays (ESAs) and Active Electronically Scanned Arrays (AESAs) systems is significantly more challenging. The ideal solution will not use 10s or 100s of DRBE inputs and outputs to interface with such systems, but instead a single input / output and address such complexity in the RF interface. Proposers should provide approaches for interfacing with both types of systems.

The DRBE program desires to leverage RF frontends which meet the interfaces purpose for the proposed demonstration.

3. Reference Algorithms TA1 will work with TA2 through a joint trade study to explore tradeoffs between HPC architectures and the resulting impact on system level performance. As part of this trade study, TA1 will create reference algorithms which demonstrate the desired calculation for core components of the emulation (e.g., the classes of environment response shown earlier). This will allow TA2 to evaluate architecture variants without deep expertise in RF emulation.

Due to the overall schedule of the program, the first TA2 hardware will not be available until 30 months into the program. As such TA1 performers should have a representative surrogate system to allow development and test of the above components. The surrogate system should be cost-conscious. As such, it is acceptable and expected that the surrogate system will reduce overall system performance metrics (such as number of inputs and outputs, bandwidth, etc.) so long as it can be demonstrated how the system will be used to reduce later integration risk. It is also highly desirable if the first fabrication run of TA2 ASICs yield usable chips, and that the surrogate provide a path for incremental upgrade using these parts to again further reduce later program integration risk.

Table 1 below defines “Threshold” performance for TA1 as well as desired “Objective” performance. The number of total systems is the number DRBE ports that can each accommodate an independent complete RF system for testing. The bandwidth listed is the average instantaneous bandwidth (IBW) of an RF system, with receive (Rx) IBWs typically being wider than transmit (Tx) IBWs. A single RF system may have a tunable bandwidth significantly larger than the IBW. The ensemble of 80 to 200 RF systems will operate over a band from near 0 GHz to well over 10 GHz. The number of signal interactions is the number of signal reflections that occur between the transmitter on one RF system and the receiver on another (or the transmitting) RF system. The maximum latency allows emulation of a 1 km or greater separation between transmitter and receiver.

Table 1 – TA1 System-level Metrics Metric Threshold Objective Number of total systems 80 200 Minimum latency / range 3.3 s / 1 km 3.3 s / 1 km Maximum latency / range 3300 s / 2 x 500 km 3300 s / 2 x 500 km Average Tx IBW 1 GHz 1 GHz Average Rx IBW 2 GHz 2 GHz RCS Complexity point-cloud model* high-fidelity model Clutter Complexity discrete clutter continuous clutter patch Multi-path Complexity 10 paths 100 paths Environment Update Rate 100 Hz 1 kHz

* 20 discrete scatters or equivalent

The system should be capable of calculating monostatic responses for all connected radars and capable of calculating multi-static responses for a fraction of the connected systems.

TA1 will also have the goal of planning and executing a final demonstration of the overall DRBE system. Proposers should define an initial desired demonstration which could be executed in the DRBE environment. As part of that definition, necessary Government Furnished Equipment (GFE) and Government Furnished Information (GFI) should be identified along with the dates by which these items are needed. Proposers should take care to note which GFE they are already in possession of, or where there exists a previous relationship with the GFE resource sponsor(s), and provide appropriate contact information. Proposers should also note necessary GFE for which the point of contact sponsor is unknown.

Technical Area 2 (TA2) – Real-time HPC and Hardware Accelerator The goal of TA2 is the development of a RT-HPC and associated computing architectures advancements necessary to achieve both low-latency and high computational throughput required for the DRBE problem domain (i.e., RF Emulation). TA2 is responsible for architecting and designing the DRBE RT-HPC to include the design of domain-specific hardware accelerators necessary to meet the real-time computational metrics, as well as the firmware that runs on the custom hardware accelerators modeled after reference algorithms created by TA1.

A reference design was created to derive compute-focused metrics for TA2. The reference design makes the same assumptions shown in the TA1 Threshold metrics. Metrics for TA2 are listed in Table 2.

Table 2 – Preliminary TA2 RT-HPC Metrics Metric TA2 Objective Maximum latency 2.5 µs Compute (32-bit floating point) 20 PFLOPs Total Memory 2.0 Tb Aggregate I/O Bandwidth 150 TB/s

As a point of comparison, the reference design further broke down the overall system into 156 discrete accelerators. Each accelerator required 133 tera floating-point multiply accumulates per second (TMACs), 12.2 Gb of memory, 77 Tb/s of memory bandwidth, 7.7 Tb/s of input/output (I/O) bandwidth, and latency less than 2.5 µs.

Existing HPCs rely on commonly available general purpose computing devices such as General Purpose Processors (GPPs) and Field Programmable Gate Arrays (FPGAs). These devices demonstrate the two extremes of the DRBE computing problem. GPPs have been designed to be computationally high throughput, while sacrificing latency. FPGAs represent the other extreme of very low latency, but also low computational throughput. The DRBE program seeks innovative designs which are able to achieve both high throughput computation while being low latency.

As with all HPCs, the DRBE program expects to utilize an array of these discrete hardware accelerators to achieve its compute requirement. However, proposers should take care to respect the latency requirement, as each additional computational hop introduces latency. Similarly, proposers should describe the per accelerator I/O requirements. With each introduction of a new accelerator comes growing connectivity requirements between accelerators. Requirements such as total system memory are relatively small as compared to other modern largescale computing environments. However, it should be noted that the total memory is again challenging because of the real-time nature of the computation involved.

Figure 3 – TA2 Latency definition

Processing latency is defined as shown in Figure 3 to include the time it takes a digitized signal to traverse any intermediate processors and interconnects, time spent calculating the environment responses, as well as any buffering. The TA2 latency metric has been reduced from TA1, and as such does not include time spent in the RF interface.

The DRBE program is open to all viable approaches to achieving the desired computational metrics. To include (but not limited to): new computing architectures, novel computing paradigms (including analog), dataflow architectures, domain-specific architectures and highly integrated, large multi-chip modules. Solutions that meet DRBE metrics and can be beneficial to other applications are highly desirable.

Additionally, the DRBE program seeks innovative solutions in how data flow is managed and traded off with compute. For example, a straightforward approach will sample all inputs at a fixed rate, with a fixed set of center frequencies. This approach will create more digital RF bandwidth to be managed, but simplify calculations and data routing. More sophisticated approaches could reduce the total data the system must manage, but at the cost of latency and/or additional computation. Similar approaches have recently emerged in hardware accelerators for machine learning, which use custom architectures to excise calculation of zero or near zero products. Proposers should thoroughly describe the architectural approach to their discrete hardware accelerator, as well any additional trades conducted which better enable the architecture to more effectively manage and manipulate the data.

TA2 is will assemble the array of hardware accelerators into a viable HPC construct for integration with TA1 tools and software. This could be approached as integration of the accelerators into more traditional COTS computer infrastructure, or through a more novel direct integration of the hardware accelerators themselves. Regardless of the chosen approach, the RT- HPC delivered to TA1 should be a complete functioning system, compliant with jointly agreed upon interfaces and specifications. While there is no precise SWAP restriction on the DRBE RT- HPC, the system should be both powered and cooled by infrastructure available in a traditional server and/or RF facility.

For Si CMOS based designs, the cost of design and fabrication at emerging CMOS process nodes (e.g., 10nm, 7nm, etc.) remains high. Designs which require fabrication with such processes should describe why that approach is necessary and clearly highlight the inability to achieve the program metrics with lower-cost process nodes.

DARPA envisions a successful DRBE program resulting in the creation of more than 1 DRBE system situated at multiple laboratories throughout the country. As such it is desirable to establish a low cost to replicate the hardware after non-recurring engineering (NRE) investment.

Proposers should report and explain their estimates to build a second DRBE system.

Lastly, as discussed in the prior section, TA2 will work jointly with TA1 to refine the computational architecture and requirements in consideration of impact on overall system metrics (those that govern the TA1 capability).

Technical Area 3 (TA3) – General Purpose Digital RF System Emulator (For informational purposes only, not to be proposed under this BAA.) In order to provide a rich test environment, DRBE must be populated with many RF systems that cannot be practically located together with the DRBE system. TA3 starts in phase 3 of the program and is tasked with building emulators which replicate existing systems. These emulators will be software-based and executed on a common hardware platform designed to allow the test designer to select the number, type, and function of adversary RF systems present in the environment. This information is provided strictly for awareness. No TA3 responses are solicited by this BAA. Any such responses will be deemed non-compliant and not receive review.

C. Program Structure, Schedule, and Milestones DRBE Program Schedule

Phase 1 is an architecture trade-study for the overall DRBE system, the HPC, and the ASIC. As part of this study, each TA1 team must work with each TA2 team to explore tradeoffs and to minimize overall development risk. DARPA’s decision to continue funding into Phase 2 will depend on both projected performance (TA1 and TA2) and compatibility with teams in the other

TA.

The Phase 1 TA1 effort ends in a Conceptual Design Review (CoDR) for the entire system. This includes documented digital interfaces to/from TA2 HPC, and available reference algorithms.

The Phase 1 TA2 effort ends in a CoDR for the HPC. At the CoDR, TA2 is expected to have an HPC design which supports computational metrics as refined cooperatively with TA1, and an ASIC design that meets metrics flowed down to the device level.

During Phase 2, both TA1 and TA2 mature their designs to a Preliminary Design Review (PDR).

At the PDR, TA1 is expected to have demonstrated all software tools and programming interfaces, using a surrogate HPC that may have reduced bandwidth and/or system connectivity count. Also, TA1 is expected to have developed all digital interfaces to the TA3 digital emulators of RF systems. At the PDR, TA2 is expected to have an ASIC design taped out and ready for fabrication, as well as simulation results which demonstrate the ASICs ability to achieve latency and compute capability per the refined and flowed-down system metrics.

DARPA anticipates that only a single TA1 team and a single TA2 team will be funded during Phase 3. During Phase 3, TA1 will mature the overall system design to the level of a Critical Design Review (CDR). At the CDR, TA1 is expected to have demonstrated achievability of Also, the surrogate system previously used for TA1 risk reduction may be considered for upgrade to use ASICs created in initial TA2 fabrication run to further reduce risk.

During Phase 3, TA2 will fabricate and test the ASIC developed during Phase 2. The results will inform both a revised ASIC design and maturation of the HPC to the level of a CDR. At the CDR, TA2 is expected to demonstrate achievability of Phase 4 ASIC and HPC build to support overall program requirements. Also, ASIC issues from initial fabrication must have been identified and remediated with a revised design ready for fabrication.

Phase 4 build out of the full DRBE system meeting overall program requirements. During Phase 4, TA2 builds a full HPC. TA1 builds all TA1 components of the DRBE system and integrates these with the HPC and the TA3 digital emulators. During the final six months of Phase 4, TA1 leads a demonstration using the DRBE system to test RF systems provided by the Government.

D. Deliverables

TA1 and TA2 performers will deliver a kickoff briefing at the start of Phase 1, and quarterly technical review briefings while under contract in any Phase. During Phases 1 and 2, these briefings will be presented in a joint meeting held at or near DARPA with all contractors present.

Beginning in Phase 3 the quarterly review meetings will be held at the contractor’s facility. At the end of Phases 1, 2, and 3 the quarterly review meetings will be correspondingly supplemented by delivery of CoDR, PDR, and CDR documentation.

Concurrent with the Phase 1 kickoff briefing, TA1 and TA2 performers will deliver a detailed technical tasking plan and corresponding spending plan. All contractors will deliver bi-weekly status and updates to the technical plan for review via teleconference. The technical plans must have measureable milestones with sufficiently fine resolution to demonstrate progress over a two week period. All TA1 and TA2 performers will delivery monthly financial status reports. As needed, bi-weekly teleconferences will be supplemented by delivery of in-depth briefings to document significant progress or challenges.

In addition to periodically scheduled deliverables, all TA1 and TA2 performers will deliver in-depth technical briefings as requested by DARPA. DARPA estimates that such requests will be made no more than once per quarter.

During Phase 3, TA2 performers will deliver ASICs from the first fabrication run along with any firmware required to use these ASICS in the TA1 surrogate HPC. The quantity delivered will depend on the number of functional ASICs available and the reserve required to be maintained by TA2 for testing. These ASICs will be provided as GFE to TA1 performers.

During Phase 4, the TA1 performer will deliver a complete functional DRBE system with sufficient technical documentation to support Government operation of the system after the end of the Program.

During Phase 4, the TA2 performer will deliver a complete functional HPC with technical documentation sufficient to support integration into the TA1 system.

All performers under all TAs will deliver a final technical report at the end of their contract.

E. Government Furnished Equipment/Property/Information

During Phase 1, DARPA will provide TA1 performers with the classified (collateral Secret) scenario definitions used to establish threshold and objective metrics. DARPA will work with the TA1 performers to refine these scenarios and metrics.

During Phase 4, DARPA will provide the TA1 performers the HPC fabricated under TA2 and the digital emulators developed under TA3. The Government will also provide RF systems to be tested during the final demonstration.

F. Intellectual Property

Any proposed use of intellectual property (patents, proprietary information, etc.) should be clearly identified in the proposal. Identify all intellectual property claims to future results, prototypes, and deliverables. Explain how these claims may limit the Government use of the DRBE system or development of future copies or variants. For forms to be completed regarding intellectual property, see Section IV.B.10. If there are no intellectual proprietary claims, this should be stated.

II. Award Information

A. General Award Information

Multiple awards are 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 at the end of one or more of the phases, as applicable.

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

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

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

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

B. Fundamental Research

It is DoD policy that the publication of products of fundamental research will remain unrestricted to the maximum extent possible. National Security Decision Directive (NSDD) 189 defines fundamental research as follows:

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

As of the date of publication of this BAA, the Government expects that program goals as described herein may be met by proposers intending to perform fundamental research and proposers not intending to perform fundamental research or the proposed research may present a high likelihood of disclosing performance characteristics of military systems or manufacturing http://www.darpa.mil/work-with-us/contract-management#OtherTransactions technologies that are unique and critical to defense. Based on the nature of the performer and the nature of the work, the Government anticipates that some awards will include restrictions on the resultant research that will require the awardee to seek DARPA permission before publishing any information or results relative to the program.

Proposers should indicate in their proposal whether they believe the scope of the research included in their proposal is fundamental or not. While proposers should clearly explain the intended results of their research, the Government shall have sole discretion to select award instrument type and to negotiate all instrument terms and conditions with selectees. Appropriate clauses will be included in resultant awards for non-fundamental research to prescribe publication requirements and other restrictions, as appropriate. This clause can be found at http://www.darpa.mil/work-with-us/additional-baa.

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

III. Eligibility Information

A. Eligible Applicants

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

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

a) FFRDCs

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

b) 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.

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

c) 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.

(1) Non-U.S. organizations and/or individuals may participate to the extent that such participants comply with any necessary nondisclosure agreements, security regulations, export control laws, and other governing statutes applicable under the circumstances.

(2) For classified proposals, applicants will ensure all industrial, personnel, and information systems 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.

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

http://www.dss.mil/

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

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

D. Other Eligibility Criteria

1. Collaborative Efforts

Collaborative efforts/teaming are encouraged.

2. Ability to Support Classified Development

All of the hardware, firmware, and software developed under the DRBE Program is expected to be unclassified. The specific operational and test scenarios serving as basis for flowdown of requirements to hardware are expected to be classified at the collateral Secret level or higher.

TA1 proposers must have the staff and facility clearances required to work with DARPA on the evaluation of classified scenarios. TA2 proposers do not require any ability to support classified development.

3. Associate Contractor Agreement Clause

This same or similar clause will be included in all TA1 and TA2 awards against

HR001119S0023:

(a) It is recognized that success of the DRBE program depends in part upon the open exchange of information between the various Associate Contractors involved in the effort. This clause is intended to ensure that there will be appropriate coordination and integration of work by the Associate Contractors to achieve complete compatibility and to prevent unnecessary duplication of effort. By executing this contract, the Contractor assumes the responsibilities of an Associate Contractor. For the purpose of this clause, the term Contractor includes subsidiaries, affiliates, and organizations under the control of the contractor (e.g. subcontractors).

(b) Work under this contract may involve access to proprietary or confidential data from an Associate Contractor. To the extent that such data is received by the Contractor from any Associate Contractor for the performance of this contract, the Contractor hereby agrees that any proprietary information…