HR001123S0006.pdf

HR001123S0006

Broad Agency Announcement Processor Reconfiguration for Wideband Spectrum Sensing

(PROWESS)

Microsystems Technology Office

October 6, 2022

Table of Contents

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description A. Background B. Program Description C. Program Structure D. Technical Areas E. Schedule/Milestones F. Deliverables G. Government Furnished Equipment/Property/Information H. 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

2. Other Applicants B. Organizational Conflicts of Interest C. Cost Sharing/Matching

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

1. Abstract Format

2. Full Proposal Format

3. Proprietary Information

4. Security Information

a. Program Security Information

b. Controlled Unclassified Information (CUI)

i. CUI Proposal Markings

ii. CUI Submission Requirements

c. Unclassified Submissions

5. Disclosure of Information and Compliance with Safeguarding Covered Defense

Information Controls

6. Human Subjects Research (HSR)/Animal Use

7. Approved Cost Accounting System Documentation

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

9. Small Business Subcontracting Plan

10. Intellectual Property

a. For Procurement Contracts

b. For All Non-Procurement Contracts

11. Patents

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

13. Funding Restrictions

C. Submission Information

1. Submission Dates and Times

a. Abstract Due Date

b. Full Proposal Date

c. Frequently Asked Questions (FAQ)

2. Abstract Submission Information

3. Proposal Submission Information

a. For Proposers Requesting Technology Investment Agreements

b. For Proposers Requesting Contracts or Other Transaction Agreements

c. Classified Submission Information

4. Other Submission Requirements

V. Application Review Information A. Evaluation Criteria

1. Overall Scientific and Technical Merit

2. Potential Contribution and Relevance to the DARPA Mission

3. Cost Realism

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

2. Proposals

B. Administrative and National Policy Requirements

1. Meeting and Travel Requirements

2. Solicitation Provisions and Award Clauses, Terms and Conditions

3. Controlled Unclassified Information (CUI) and Controlled Technical Information

(CTI) on Non-DoD Information Systems

4. Representations and Certifications

C. Reporting D. Electronic Systems

1. Wide Area Work Flow (WAWF)

2. i-Edison

3. Vault

4. DARPA Embedded Entrepreneurship Initiative (EEI)

VII. Agency Contacts VIII. Other Information

1. Proposers Day

ATTACHMENT 1: Cost Volume Proposer Checklist ATTACHMENT 2: General MTO Controlled Unclassified Information Guide (CUIG) ATTACHMENT 3: DARPA Standard Cost Proposal Spreadsheet ATTACHMENT 4: Other Transactions (OT) Certifications Template

PART I: OVERVIEW INFORMATION

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

Funding Opportunity Title: Processor Reconfiguration for Wideband Spectrum Sensing

(PROWESS)

Announcement Type: Initial Announcement Funding Opportunity Number: HR001123S0006 Catalog of Federal Domestic Assistance Numbers (CFDA): Not applicable Dates: (All times listed herein are Eastern Time) o Posting Date: October 6, 2022 o Proposers Day: October 13, 2022 o Abstract Due Date: November 3, 2022, 4:00 PM Eastern Time o FAQ Submission Deadline: November 28, 2022, 4:00 PM Eastern Time o Proposal Due Date: December 19, 2022, 4:00 PM Eastern Time o Estimated period of performance start: June 1, 2023

Concise description of the funding opportunity: The DARPA Microsystems Technology Office seeks innovative proposals in run-time reconfigurable processors, with the specific goal to develop processors that provide autonomous radiofrequency (RF) systems with decision-directed situational awareness about complex and uncertain electromagnetic environments.

Anticipated individual awards: Multiple awards are anticipated.

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

Agency contact:

o Mr. John Davies, Program Manager BAA Coordinator: HR001123S0006@darpa.mil

DARPA/MTO

ATTN: HR001123S0006

675 North Randolph Street Arlington, VA 22203-2114 mailto:HR001123S0006@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 for FAR-based procurement contracts 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 System for Award Management (SAM) website, under the Contract Opportunities link, at https://sam.gov/. The following information is for those wishing to respond to the BAA.

The Microsystems Technology Office at DARPA seeks innovative proposals in high-throughput streaming-data processors that reconfigure in nanoseconds to monitor complex radiofrequency (RF) signal environments. The Processor Reconfiguration for Wideband Spectrum Sensing (PROWESS) program will enable “just-in-time” synthesis of processing pipelines in uncertain environments where pre-programmed solutions are likely to fail. PROWESS will allow receivers to continuously explore algorithm space, optimizing performance for both measured spectrum conditions and the needs of cognitive RF decision logic. Proposed research should investigate innovative approaches that enable revolutionary advances in science, devices, and systems.

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

A. Background

Commercial and military demands on the electromagnetic spectrum (EMS) are driving RF systems to operate in increasingly congested and complex environments. Prior research, including DARPA’s Spectrum Collaboration Challenge (SC2), has demonstrated that autonomous software-defined RF systems deliver significant benefits in both spectral capacity and robustness over traditional fixed or rule-based approaches to spectrum usage. The foundation of this type of RF autonomy is spectrum sensing, which enables RF systems to optimize to actual spectrum conditions and react to interference in real-time.

Modern autonomous RF systems rely on field programmable gate arrays (FPGAs) for low-latency, high-throughput receiver processing. Spectrum sensing across wide bandwidths that contain increasingly complex and diverse signals drives the demand for edge processing beyond the capacity of today’s devices. This increased demand is rooted in three emerging trends. First, as transmitters become more dynamic and software-defined, there is far more uncertainty about potential RF signal operating parameters. Traditional methods to detect and characterize signals are designed for specific waveforms and perform poorly across arbitrary signal modulations and bandwidths. Overcoming these limitations drives receivers to use much more computationally-intensive algorithms. Given the potential rate of signal change, this trend also devalues the use of waveform-specific accelerators. Second, systems are operating across wider frequency ranges, expanding from megahertz (MHz) to gigahertz (GHz) scales. This pushes receivers to sense over wider bandwidths, significantly increasing the amount of digitized data they must continuously process. Third, wideband and narrow beam waveforms reduce peak power presented at the sensor, driving receivers to deliver additional gain through cross-correlation and multi-channel spatial processing. These trends, coupled with the potential benefits from the widespread use of RF autonomy, motivate innovation in ultra-flexible high-throughput streaming data processors.

PROWESS will combine emerging high-density reconfigurable processing arrays with embedded real-time schedulers to expose new architectural tradeoffs that jointly deliver high compute density and fast program switching. Such architectures potentially offer significant benefits for spectrum sensing and related applications, particularly when systems must operate in environments whose characteristics are difficult to fully specify at design time. By making decisions (i.e., switching programs) on large volumes of continuously streaming data, PROWESS devices will enable the detection and characterization of complex and uncertain waveforms in dense environments. Relative to state-of-the-art solutions, PROWESS devices are expected to provide (1) increased processing capacity switchable at waveform timescales and (2) real-time resource management that dynamically aligns tasks to both the sensed signal environment and downstream decision-making applications. PROWESS is open to a wide range of solutions that achieve these goals; promising approaches include the integration of highly parallel coarse-grained reconfigurable arrays with multi-stage hardware-software compilers.

B. Program Description

PROWESS program goals are to develop and demonstrate:

Run-time reconfigurable processors with 200 giga-operations per second per square millimeter (GOPS/mm2) compute density and 50 nanosecond program switch time Real-time schedulers that manage 100 parallel programs at 90% processor utilization Scaling to continuously monitor 40 GHz total input bandwidth for important signals

Achieving these goals requires overcoming two technical challenges.

Technical Challenge 1 Maximize compute density (>200 GOPS/mm2) while minimizing program switch time (<50 nanoseconds). General purpose processors (GPPs) can execute software with complex program switching, but only at low streaming data rates. GPPs achieve this flexibility by dedicating significant die area to caching and branch prediction circuitry. As GPP performance per watt improvements have slowed, faster processors alone cannot deliver the compute density required for wideband sensing.

FPGAs and application-specific integrated circuits (ASICs) can process streaming data at much higher data rates than GPPs, but each program switch point must have dedicated hardware that is unused for unexecuted branches. This unused processing capacity, or “dark silicon,” directly reduces compute density. While FPGAs can switch their programs through reconfiguration, their millisecond-scale reconfiguration times are limited by low I/O bandwidth to off-chip configuration memory—which can’t improve without sacrificing compute density—and the large configuration file sizes associated with their fine-grained processing elements. New processing architectures are needed than can jointly maximize compute density while minimizing program switch time.

Technical Challenge 2 Real-time program scheduling that maximizes detection of important signals across wide bandwidths. Optimal task scheduling for processing arrays is non-deterministic and addressed by brute force search. Many existing heuristic methods for computational resource allocation are non-real-time—e.g., generating FPGA configurations takes hours to place and route programs.

The timelines for these approaches force spectrum sensors to use fixed signal processing pipelines designed using assumptions about the intended operational environment. Making such assumptions is increasingly difficult for environments that contain software-defined or autonomous RF systems, and performance degradation can result when design assumptions and the signal environment do not align.

While dense RF environments present receivers with millions of signals, the information about important signals that drives the decision making of autonomous RF systems can be relatively sparse. Emerging cognitive sensors that continuously reassess signal importance present a new opportunity to relax timing constraints and enable schedulers to dynamically drop low-priority data and processing tasks. Such decision-centric scheduling methods could substantially reduce the processing requirements to detect important signals and correspondingly increase the bandwidths that spectrum sensors can effectively monitor.

C. Program Structure

PROWESS is a 60-month, three-phase program with an 18-month Phase 1 (Base), a 24-month Phase 2 (Option), and an 18-month Phase 3. The number of funded performers may decrease at the conclusion of each phase. Performers will continue into subsequent phases at the Government’s sole discretion based on technical progress against the metrics and milestones defined in this BAA and funding availability.

Phase 1 will focus on the development of device and software designs, using risk reduction experiments to mature these designs to the level of a preliminary design review (PDR). Phase 2 will further mature designs to the level of a critical design review (CDR) and demonstrate prototype devices and software.

Phase 3 will focus on the development of full-scale devices and support software capable of integration with a prototype receiver. The Government intends to issue a Statement of Objectives (SOO) detailing Phase 3 goals to Phase 2 performers. It is anticipated that the SOO will be provided in Month 18 of Phase 2. Phase 2 performers may submit a proposal in response to this SOO. The Government will not reimburse proposers’ Phase 3 proposal preparation costs if they choose to respond to this SOO. If awarded, the Government anticipates incorporating Phase 3 into current PROWESS awards, unless the contracting officer determines a more appropriate contracting approach. Lastly, it is the Government’s intent to negotiate and award Phase 3 no later than the Phase 2 end date.

Notably, this BAA solicits technical and cost proposals solely for Phase 1 and Phase 2. The discussions of Phase 3 are provided for information only. Proposals should include a brief description of the general approach to Phase 3 but should not include Phase 3 in the cost proposal.

D. Technical Areas

PROWESS has one technical area that focuses on the development of runtime reconfigurable processing hardware and support software. Hardware of interest includes high-throughput streaming data processing arrays and any associated controllers or schedulers. Software of interest includes programming workflow tools, software-based resource managers, and real-time kernels to execute representative sensor processing functions. This BAA uses the term runtime reconfigurable array (RTRA) broadly to include this combined hardware and software architecture, and uses the terms “RTRA devices” and “RTRA software” when necessary to differentiate between system elements.

DARPA anticipates that PROWESS performers will leverage expertise in both processing architectures and spectrum sensing to ensure solutions are well-matched to this use case.

Teaming is encouraged as needed. While PROWESS focuses on spectrum sensing, proposers are encouraged to identify additional high-impact applications and transitions of their RTRAs.

RTRAs present a new opportunity to treat reconfiguration as integral to algorithmic design, rather than just switching among independent programs. This capability is anticipated to enable the continuous real-time decision-making needed to monitor large swathes of dense and unstructured RF spectrum. PROWESS’ overall goal is to combine high-density computational fabric with algorithmic time multiplexing to greatly expand the useful processing capacity in edge sensor systems. Depending on the specific application, this additional processing capacity is expected to improve the performance of receiver systems across the following dimensions:

Total input bandwidth, i.e., number of antenna channels × instantaneous bandwidth per channel

Diversity of signal types detected and characterized Probability of detection and correct characterization for signals important to the decision-making of an autonomous RF system

Table 1 summarizes PROWESS metrics. The objectives are consistent across program phases, with each phase increasing the maturity of associated demonstrations. In Phase 1, metrics will be demonstrated through design projection coupled with risk reduction experimentation. In Phase 2, metrics will be demonstrated at using a prototype RTRA device. In Phase 3, metrics will be demonstrated on a full-scale device or system of devices capable of characterizing complex signals across 40 GHz total input bandwidth.

Table 1: PROWESS Metrics Metric Objective Notes

Compute density 200 GOPS/mm2 1 Program switch time 50 nanoseconds 2 Processor utilization 90% 3 Throughput gain from program switching 16 dB 4 Notes:

1. Assumes IEEE half-precision floating point operations with a 16nm process. Metric goals are correspondingly increased when targeting smaller process nodes.

2. A program switch is defined as a run-time decision point in software, firmware, or hardware that selects among compute options. Within the specified switch time, on average 50 program options are expected to be available at each decision point.

3. Average scheduler performance that satisfies program switch time goals for at least 100 parallel tasks under dynamic task prioritization

4. Throughput gain is defined as the system bandwidth increase from time-multiplexed processing pipelines while maintaining consistent signal probability of detection. For example, 16 dB (40x) throughput gain would enable a system with enough processing resources to continuously monitor one GHz of total RF bandwidth (unswitched) to monitor 40 GHz of total RF bandwidth through program switching.

Simultaneously achieving metric goals in compute density and program switch times involves complex tradeoffs in processing, memory, inter-processor communications, and control. To encapsulate the impact of these tradeoffs, compute density metrics are measured across the complete RTRA system, inclusive of any support circuitry outside the processing core.

Successful PROWESS solutions could include a wide range of processing architectures, including processing elements that are heterogeneous or homogeneous, or coarse-grained, fine-grained, or a mixture. Approaches to PROWESS that include dedicated accelerators for universal “always on” processing functions may be considered when motivated by substantial metric improvements. Single-purpose accelerators for specific signal types are strongly discouraged, and would not meet PROWESS’ goal to prepare for environments whose characteristics are difficult to fully specify at design time.

PROWESS focuses on reconfigurable receiver processing and is not expected to develop new reconfigurable RF front ends. However, performers may consider any impacts or synergies if RTRAs are integrated into RF systems with end-to-end flexibility.

PROWESS performers may implement program switching through a number of potential approaches, including branching within software kernels, program memory reconfiguration, or dynamic routing through on-chip networks. DARPA anticipates successful solutions will integrate diverse switching types to achieve program goals, and that designs will be informed by analysis of switching patterns in representative sensor workloads. In addition to minimizing switching speed, PROWESS’ goal is to provide diverse switching options (an average of 50) at each decision point. Approaches that address program switch time objectives through global context switching across a handful of preprogrammed options are strongly discouraged.

PROWESS’ goal is to increase in two-dimensional (2D) compute density through novel compute architectures; PROWESS does not intend to focus on new device packaging or integration techniques. However, PROWESS performers are encouraged to identify any synergies with three-dimensional (3D) integration or similar exploitations of the z-direction. If using such approaches, note that compute density will be calculated as the average density across the component layers in the die or wafer stack and will not directly contribute to increased performance against this metric.

PROWESS metrics do not explicitly define performance goals for RTRA device energy efficiency (performance per watt) under the assumption that improvements to compute density will deliver complementary improvements to energy efficiency. Approaches that achieve compute density goals at the expense of energy efficiency are discouraged. Additionally, today’s systems on chip (SoCs) often rely on low device utilization to relax thermal and power delivery requirements. PROWESS may break such traditional assumptions by enabling much higher device utilization through the continuous allocation of useful work. Performers are encouraged to identify and mitigate any corresponding thermal and power delivery risks as their solutions scale.

Performers may demonstrate metric goals using either RTRA chiplets or larger-scale integrated circuits. Performers using a chiplet approach are encouraged to demonstrate how their solutions scale as multi-chiplet systems. For future integration with analog-to-digital converters and other peripherals, performers are encouraged to incorporate high-speed interconnects into their designs, with a goal to achieve the equivalent of one (1) terabit/s/mm shoreline input/output bandwidth density. DARPA anticipates that chiplet-based approaches will enable new processing architectures to be developed at reduced cost, schedule, and technical risk. Regardless of specific approach, DARPA strongly encourages performers to develop program plans that balance simulation, emulation, and hardware-in-the-loop experimentation to burn down risks and enable rapid learning and design cycles.

Performers are encouraged to develop models of spectrum sensing workloads to ground their architectural design decisions in the objective application. These models may include a cascade of spectrum sensing functions: e.g., detection, frequency and spatial separation, parameter estimation, classification, and tracking. These functions may extract information about both individual RF signals and the environment as a whole. Performers are encouraged to consider environments that include communications, radar, and multi-function RF systems.

Understanding how these workloads change in dynamic environments is critical, including the scope of program changes, the origin point of switching decisions, and how programs switch across different timescales. Performers may organize algorithms into executable decision trees or use other methods to perform these assessments.

DARPA does not anticipate that achieving PROWESS’ goals requires the invention of new spectrum sensing algorithms. However, RTRAs may present opportunities to combine existing algorithms in new ways, develop novel algorithm implementations, or incorporate algorithms previously unavailable to edge systems. Performers are encouraged to identify and develop such innovative approaches.

PROWESS is both a key enabler of future autonomous RF systems and dependent on feedback from the downstream decision software to achieve throughput gain metric goals. PROWESS does not intend to develop new autonomous or cognitive RF applications. Performers are encouraged to leverage existing representative decision logic from such applications to benchmark the range of throughput gains in their system under different RF environmental conditions. At the conclusion of Phase 2, DARPA anticipates providing decision logic software as government furnished information (GFI) to PROWESS performers for independent metric evaluation. This is in addition to any decision logic software developed by performers for internal benchmarking purposes.

RTRAs developed under PROWESS are anticipated to be highly reprogrammable. To minimize lifecycle costs, performers are encouraged to support software development in existing high-level programming languages. Additionally, transitioning RTRA devices to future receiver designs is only sustainable if these devices are paired with a full software development workflow. Such a workflow may include compilers, simulators, debuggers, benchmarking and analytics, and kernel libraries. To minimize development cost and risk, performers are encouraged to leverage existing tools wherever possible and to maximize the use of free and open-source software. New tool development is expected when needed to overcome PROWESS technical challenges or achieve substantial metric performance gains.

Specific goals for each PROWESS phase follow below.

Phase 1 (Base) The goal of Phase 1 is to mature RTRA designs through a preliminary design review (PDR) grounded in risk reduction experimentation. This PDR is anticipated to include both device and software design elements and reflect a design of sufficient maturity to support device tapeout early in Phase 2. A concept design review (CoDR) is anticipated at the Phase 1 midpoint; this review is expected to address all major design elements of the PDR using draft or intermediate results. The fidelity of intermediate and final Phase 1 metric projections is critically important and is an expected focus of Phase 1 experimentation and risk reduction.

PROWESS performers are expected to define the range of RF environments and conditions needed to inform key RTRA design trades; the Government anticipates providing feedback on these conditions and other design assumptions. Additionally, the Government anticipates collaborating with PROWESS performers in Phase 1 to define interfaces for integration of streaming digital environment data and autonomous RF decision software. The Government anticipates providing this data and software as GFI in Phase 2. At its discretion, the Government may also provide reference datasets in Phase 1 to assist RTRA development.

Throughout the program, DARPA encourages performers to manage by risk. A standard 5x5 risk matrix assesses risks according to their likelihood (L) and consequence (C) on a five-point scale.

Individual risks can then be scored and ranked from 1 to 25 (L×C). DARPA’s goal is to reduce the maximum the number of high/red risks (i.e., L×C>12) to medium/yellow (i.e., 12≥L×C≥5) by the end of Phase 1. Specific risk reduction activities will vary, but anticipated Phase 1 mitigations include modeling of spectrum sensing workloads, prototyping scheduler software, and characterizing RTRA device models in FPGA-based emulators. As appropriate, performers are encouraged to leverage any available surrogate hardware to inform their designs.

Phase 2 (Option) The goal of Phase 2 is to mature RTRA designs through a critical design review (CDR) and demonstrate prototype RTRA devices on streaming digital data representative of challenging RF environments. This CDR is anticipated to reflect an RTRA design of sufficient maturity that devices could be delivered in Phase 3 in support of integration with prototype receiver systems.

At the end of Phase 2, PROWESS performers are expected to demonstrate their RTRA devices on a test board in a laboratory environment. These testbeds are expected to include capability to stream multiple channels of high-speed digital data into the devices-under-test and to host real-time RTRA control software. In addition to benchmarking tests specified by PROWESS performers, DARPA expects to provide GFI data and RF autonomy software for supplemental evaluation. PROWESS performers may anticipate including all instrumentation necessary to measure metric performance on these testbeds.

DARPA’s goal is to reduce all high/red risks to medium/yellow and maximize the number of medium/yellow risks reduced to low/green (i.e., L×C<5) by the end of Phase 2.

Phase 3 (Informational Only):

The goal of Phase 3 is to develop and deliver RTRAs to sufficient maturity to integrate with prototype RF receivers, addressing any errata or outstanding developmental items from Phase 2.

Additionally, PROWESS performers should anticipate providing integration support for software applications developed by transition stakeholders.

E. Schedule/Milestones

Figure 1 depicts the PROWESS schedule.

Figure 1: PROWESS Schedule

Phase 3 proposal: After assessing technical progress and the needs of potential transition stakeholders, the Government anticipates providing a SOO to performers in Month 18 of Phase

2. If they choose to respond, performers will have 45 days to provide a proposal for Phase 3 based on the SOO requirements. Decisions on which performer(s) will continue to Phase 3 will be made based on technical progress and the availability of funds.

Table 2 depicts PROWESS milestones.

Table 2: PROWESS Milestones

Phase Milestone Program Month

Phase 1 kickoff 1 RTRA concept design review (CoDR) 9 Demonstrate real-time scheduler prototype 121

RTRA preliminary design review (PDR) and performance projection 16 Phase 2 kickoff 19 RTRA device tapeout 24 Initial release of software development workflow 26 Integrated kernel software and scheduler risk reduction demonstration 32 Sensor processing demonstrated on RTRA device on test board 38

RTRA critical design review (CDR) and scaling projection 40

F. Deliverables

All performers shall deliver a detailed spend plan at program kickoff and execution of subsequent option phase awards, monthly technical status updates, and monthly financial reports including updated expenditures. Performers will prepare and submit briefing materials and participate in quarterly progress reviews, either via teleconference or at the performer’s site at the discretion of DARPA. All performers will participate in and support program-wide reviews at DARPA and held at least annually and scheduled at the Program Manager’s discretion. All performers should be prepared to respond to off-schedule delivery of technical updates and summary slides at the Program Manager’s request.

Upon completion of each phase, performers shall deliver to the Government an end-of-phase final technical report. This report documents summary and detailed designs, insights into PROWESS technical challenges, results of experiments and other risk mitigation activities, and plans for future development.

Performers shall deliver source and executable software developed under PROWESS. This includes any programming workflow tools, software-based resource managers, and real-time kernels. Starting in mid-Phase 2, performers are expected to release their workflow tools to support third-party application development, and update these tools as required to address defects and add features.

Other proposed deliverables specific to the objectives of the individual efforts may also be included. These may include reports, experimental protocols and test data, publications, intermediate and final versions of software and APIs, documents, models, modeling data and results, and model validation data.

Table 3 summarizes PROWESS deliverables.

Table 3: PROWESS Deliverables Deliverable Frequency Phase spend plans At phase kickoffs Technical and financial reports Monthly Kickoff and quarterly progress review presentations Quarterly CoDR design package Once, at Phase 1 month 9 Phase 1 final technical report and PDR package Once, at Phase 1 end Phase 2 final technical report and CDR package Once, at Phase 2 end Source and executable software At phase end and at DARPA request

G. Government Furnished Equipment/Property/Information

In Phase 2, DARPA plans to provide GFI data and RF autonomy software for supplemental evaluation. DARPA plans to provide this GFI no later than six (6) months prior to the end of Phase 2. Data and software is expected to conform to an interface definition specified by each performer and provided to the government no later than six (6) months after Phase 2 kickoff (i.e., 12 months prior to GFI software delivery).

H. Intellectual Property

Any use of proposer-defined intellectual property (patents, proprietary information, etc.) should be clearly marked as such within the proposal. Include all proprietary claims to the results, prototypes, intellectual property, or systems supporting the effort and/or necessary for the use of the research, results and/or prototype. If there are no proprietary claims, this should be stated.

For forms to be completed regarding intellectual property, see Section IV.B.10.

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 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. § 4022(f), the Government may award a follow-on production contract or Other Transaction (OT) for any OT awarded under this solicitation 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 solicitation, the Government expects that program goals as described herein may be met by proposed efforts for fundamental research and non-fundamental research. Some proposed research may present a high likelihood of disclosing performance http://www.darpa.mil/work-with-us/contract-management#OtherTransactions http://www.darpa.mil/work-with-us/contract-management#OtherTransactions characteristics of military systems or manufacturing technologies that are unique and critical to defense. Based on the anticipated type of proposer (e.g., university or industry) and the nature of the solicited work, the Government expects 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 determine whether the proposed research shall be considered fundamental and to select the award instrument type. Appropriate language will be included in resultant awards for non-fundamental research to prescribe publication requirements and other restrictions, as appropriate. This language 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 to be performed by a potential awardee is non-fundamental research, its proposed subawardee’s effort may be fundamental research. It is also possible that the research performed by a potential awardee is fundamental research while its proposed subawardee’s effort may be non-fundamental research.

In all cases, it is the potential awardee’s responsibility to explain in its proposal which proposed efforts are fundamental research and why the proposed efforts should be considered 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 solicitation 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, that (a) cites the specific authority establishing their eligibility to propose to Government solicitations and compete with industry, and (b) certifies the FFRDC’s compliance with the associated FFRDC sponsor agreement’s terms and conditions. These conditions are a requirement for FFRDCs proposing to be awardees or subawardees.

b) Government Entities http://www.darpa.mil/work-with-us/additional-baa

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 and compete with industry. This information is required for Government Entities proposing to be awardees or subawardees.

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

2. Other Applicants

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.

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 solicitation. The disclosure must include the proposer’s, and as applicable, proposed team member’s OCI mitigation plan. The OCI mitigation plan must include a description of the actions the proposer has taken, or intends to take, to prevent the existence of conflicting roles that might bias the proposer’s judgment and to prevent the proposer from having unfair competitive advantage. The OCI mitigation plan will specifically discuss the disclosed OCI in the context of each of the OCI limitations outlined in FAR 9.505-1 through FAR 9.505-4.

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

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

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

The name of the DARPA office receiving the support;

The prime contract number;

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

Government Procedures In accordance with FAR 9.503, 9.504 and 9.506, the Government will evaluate OCI mitigation plans to avoid, neutralize or mitigate potential OCI issues before award and to determine whether it is in the Government’s interest to grant a waiver. The Government will only evaluate OCI mitigation plans for proposals that are determined selectable under the solicitation 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 and https://acquisitioninnovation.darpa.mil.

IV. Application and Submission Information

PROPOSERS ARE CAUTIONED THAT PROPOSALS MAY BE EVALUATED

UNFAVORABLY OR REJECTED (IF DEEMED NONCONFORMING) IF PROPOSAL

PREPARATION (PROPOSAL FORMAT, CONTENT, ETC.) AND/OR SUBMITTAL

INSTRUCTIONS ARE NOT FOLLOWED.

A. Address to Request Application Package

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

B. Content and Form of Application Submission

All submissions, including abstracts and proposals must be written in English with type not smaller than 12-point font. Smaller font may be used for figures, tables, and charts. Copies of all http://www.darpa.mil/work-with-us/contract-management https://acquisitioninnovation.darpa.mil/ http://www.darpa.mil/ documents submitted must be clearly labeled with the DARPA BAA number, proposer organization, and proposal title/proposal short title.

1. Abstract Format

Proposers are strongly encouraged to submit an abstract in advance of a full proposal. Abstracts should follow the format described below in this section. The cover sheet should be clearly marked “ABSTRACT” and the total length of Section II should not exceed five (5) pages.

Section I. Administrative

A. Cover sheet to include:

(1) BAA number (HR001123S0006);

(2) Technical area(s);

(3) Lead Organization submitting abstract;

(4) Type of organization, selected among the following categories:

Large Organization, Small Disadvantaged Organization, Other Small Organization, HBCU, MI, Other Educational, Other Nonprofit;

(5) Proposer’s internal reference number (if any);

(6) Other team members (if applicable) and type of organization for each;

(7) Proposal title;

(8) Technical point of contact to include:

Salutation, last name, first name, street address, city, state, zip code (+4), telephone, fax (if available), electronic mail;

(9) Administrative point of contact to include:

Salutation, last name, first name, street address, city, state, zip code (+4), telephone, fax (if available), electronic mail;

(10) Total funds requested from DARPA, and the amount of cost share (if any); AND

(11) Date proposal abstract was submitted.

(Note: An official transmittal letter is not required when submitting a Proposal Abstract.)

Section II. Abstract Details

A. Innovative Claims {One (1) page maximum} Summary of innovative claims for the proposed research. This section is the centerpiece of the abstract and should succinctly describe the uniqueness and benefits of the proposed approach relative to alternate approaches.

B. Technical Approach Technical rationale, technical approach, and constructive plan for accomplishment of technical goals in support of innovative claims and deliverable production.

C. Deliverables Deliverables associated with the proposed research and the plans and capability to accomplish technology transition and commercialization.

D. Cost and Schedule Provide a cost estimate for resources (e.g., labor, materials) and any subcontractors over the proposed timeline of the project, broken down by program phase.

2. Full Proposal Format

All full proposals must be in the format given below. Proposals shall consist of two volumes:

Volume I – Technical and Management Proposal (3 sections), and Volume II – Cost Proposal (4 sections). The submission of other supporting materials along with the proposals is strongly discouraged and will not be considered for review. Section II of Volume I, Technical and Management Proposal, shall not exceed 25 pages. The page limitation for full proposals includes all figures, tables, and charts. There is no page limit for Volume II, Cost Proposal.

a. Volume I, Technical and Management Proposal

Section I. Administrative

A. Cover sheet to include:

(1) BAA number (HR001123S0006);

(2) Technical area(s);

(3) Lead Organization submitting proposal;

(4) Type of organization, selected among the following categories:

Large Organization, Small Disadvantaged Organization, Other Small Organization, HBCU, MI, Other Educational, Other Nonprofit;

(5) Proposer’s internal reference number (if any);

(6) Other team members (if applicable) and type of organization for each;

(7) Proposal title;

(8) Technical point of contact to include:

Salutation, last name, first name, street address, city, state, zip code (+4), telephone, fax (if available), electronic mail;

(9) Administrative point of contact to include:

Salutation, last name, first name, street address, city, state, zip code (+4), telephone, fax (if available), electronic mail;

(10) Total funds requested from DARPA, and the amount of cost share (if any); AND

(11) Date proposal was submitted.

B. Official transmittal letter.

The transmittal letter should identify the BAA number, the proposal by name, and the proposal reference number (if any), and should be signed by an individual who is authorized to submit proposals to the Government.

Section II. Detailed Proposal Information

A. Executive Summary {two (2) pages maximum}

Su…