DARPA-BAA-11-01 System F6.pdf

Broad Agency Announcement

System F6

Tactical Technology Office (TTO)

DARPA-BAA-11-01

October 20, 2010

Table of Contents:

Part I: Overview Information Part II: Full Text of Announcement Sec. I: FUNDING OPPORTUNITY DESCRIPTION Sec. II: AWARD INFORMATION Sec. III: ELIGIBILITY INFORMATION

A. Eligible Applicants B. Cost Sharing/Matching C. Other Eligibility Criteria

Sec. IV. APPLICATION AND SUBMISSION INFORMATION A. Address to Request Application Package B. Content and Form of Application

Submission Sec. V. APPLICATION REVIEW INFORMATION

A. Evaluation Criteria B. Review and Selection Process

Sec. VI. AWARD ADMINISTRATION INFORMATION A. Award Notices B. Administrative and National Policy Requirements C. Reporting D. Electronic Systems

Sec. VII. AGENCY CONTACTS Sec. VIII. OTHER INFORMATION

A. Intellectual Property B. Non-Procurement Contract Proposers – Noncommercial and

Commercial Items (Technical Data and Computer Software) C. All Proposers – Patents

Appendix A: MULTI-LEVEL SECURITY REQUIREMENTS

Part I: Overview Information

• Federal Agency Name – Defense Advanced Research Projects Agency (DARPA), Tactical Technology Office (TTO)

• Funding Opportunity Title – System F6

• Announcement Type – Initial announcement

• Funding Opportunity Number – Broad Agency Announcement 11-01

• Catalog of Federal Domestic Assistance Numbers (CFDA) – Not applicable

• Dates o Posting Date: October 20, 2010 o Questions Due Date: November 5, 2010 o Proposal Due Date: December 20, 2010

• Total amount of money to be awarded – $69.0 million

• Anticipated individual awards – Multiple awards are anticipated

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

• Agency contact –

DARPA/TTO

Attn: BAA 11-01 3701 North Fairfax Drive Arlington, VA 22203-1714 Fax: +1-703-248-8006 E-mail: DARPA-BAA-11-01@darpa.mil

Part II: Full Text of Announcement

I. FUNDING OPPORTUNITY DESCRIPTION

Program Objectives

The goal of the System F6 program is to demonstrate the feasibility and benefits of disaggregated—or fractionated—space architectures, wherein the functionality traditionally co-resident within a single, large, “monolithic” satellite is delivered by a cluster of wirelessly-interconnected modules capable of sharing their resources and utilizing resources found elsewhere in the cluster. Such an architecture enhances the adaptability and survivability of space systems, while also shortening development timelines and reducing the barrier-to-entry for participation in the national security space industry. The program is predicated on the development of open interface standards— from the physical wireless link layer, through the network protocol stack, and including the real-time resource sharing middleware and cluster flight logic—that can enable the emergence of a space “global commons” which would enhance the mutual security posture of all participants through interdependence. A key program goal is the industry-wide promulgation of these open interface standards for the sustainment and development of future fractionated systems.

The program will culminate with an on-orbit demonstration in 2014-2015 of the key functional attributes of fractionated architectures. The on-orbit demonstration will take place in LEO, with precise orbit parameters to be determined, and will be approximately six months in duration, with a potential subsequent residual capability demonstration lasting up to 18 months. The successful completion of these on-orbit demos constitute the high-level objectives of the program, from which proposers and performers are expected to derive system-, subsystem-, and component-level objectives.

1. Capability for semi-autonomous long-duration maintenance of a cluster1 and cluster network, and to add and remove spacecraft modules2 to/from the cluster and cluster network;

2. Capability to securely share resources3 across the cluster network with real time guarantees and among payloads or users in multiple security domains;4

1 A cluster is defined as a set of spacecraft with nearly equal orbital elements and able to maintain a stable relative geometry to support wireless communications. It is distinguishable from a formation in that there is no requirement for precision relative station-keeping such as might be needed for coherent sensing or sparse aperture synthesis.

2 A module is defined as an independent spacecraft that is part of a fractionated cluster and cluster network, and that makes one or more of its components available as shared resources on the cluster network.

3 A resource is a spacecraft component registered and made accessible across the cluster network for use by applications that may or may not be co-resident on the same physical spacecraft module as the resource.

4 A security domain is an enclave within which data can be freely shared among users, between applications, and across resources, but beyond which data can only depart subject to specific controls.

3. Capability to autonomously reconfigure the cluster to retain safety- and mission-critical functionality in the face of network degradation or component failures;

4. Capability to perform a defensive cluster scatter and re-gather maneuver to rapidly evade a debris-like threat; specifically, 5 minutes after a command is received from the ground, each module should be at least 10 km from where any module would have been under normal orbit operations (i.e., if no scatter maneuver had been initiated), and each pair of modules are as far apart as possible; the planning and execution of the scatter and re-gather maneuvers shall be performed without intervention or communication from ground operations.

Program Scope & Structure

The program will be executed in multiple technical tracks solicited through a series of broad agency announcements (BAAs). The present BAA is the first in the series, and includes four technical areas. It is focused on the definition of interfaces and the development of algorithms and software which will constitute the F6 Developer’s Kit (FDK). The FDK is a set of open source interface standards, protocols, software, behaviors, and reference implementations thereof, necessary for any party, without a contractual relationship with or assistance from any System F6 performer, to develop a clean-sheet module design that can fully participate in a fractionated cluster. The four technical areas (described in detail in the following sections) are:

1. Design Tools for Adaptable Systems

2. Wireless Inter-Module Communications

3. Information Architecture

4. Cluster Flight

In short, the first technical area is aimed at the development of design tools that appropriately quantify the adaptability of a space system, alongside its performance, cost, and risk. The goal is to appropriately incentivize the incorporation of adaptability features into space system designs by facilitating analytically rigorous trades between adaptability and traditional system attributes at each level of abstraction in the design. The second technical area is aimed at developing a Layer 1 and Layer 2 wireless communications standards for communication between spacecraft modules on orbit. (The layer numbering scheme referenced throughout the BAA refers to the OSI Reference Model.5) The third technical area seeks the development of an information architecture to function at Layers 3 through 7 across the space-based wireless links and extending to the ground segment via a variety of downlink paths. The information architecture should support dynamic

Different classification levels or disparate organizational ownership would constitute distinct security domains.

5 See ISO/IEC Standard 7498-1:1994; see also Figure 1.

routing or switching, real-time resource sharing and scheduling, fault tolerant behaviors, and a multi-level information assurance solution. The fourth and final technical area is geared toward the development of Layer 7 applications that enable collision-safe multi-body cluster flight, efficient relative navigation, relative station-keeping, and cluster reconfiguration—including rapid defensive maneuvering.

Figure 1: BAA Technical Areas Superposed against the OSI Reference Model

One or more subsequent BAAs will focus on the development of one or more physical instantiations of the FDK, called F6 Technology Packages (F6TPs). An F6TP is a modular component that can be installed on a wide range of spacecraft buses to enable them to fully participate in a fractionated cluster. Additionally, the second BAA will call for the development of fractionated infrastructure resources, i.e., payloads that can be shared across the demonstration cluster, including on-orbit computing and data storage capability, communications relay, relative navigation sensors, etc. The acquisition of spacecraft buses and launch for the demonstration mission will take place once all principal technology development is complete.

Each technical area in this BAA is structured with a base period of performance of 6 months of preliminary architecture design, culminating in a design review and trade study deliverable (Milestone A). Offerors must include as a priced 12-month option to their proposal, a detailed architecture development activity, culminating in complete prototype software or hardware (as appropriate) build (Milestone B). Offerors must also include in their proposal a second 12-month priced option for a verification, validation, and regulatory approval support activity, culminating in a flight readiness review (Milestone C). Proposals must follow this structure.

OSI Model

Layer 7 (Application)

Cluster Flight (BAA Technical Area 4)

Payload Application in Security Domain A

Payload Application in Security Domain B

Layer 6 (Presentation)

Information Architecture (BAA Technical Area 3)

Layer 5 (Session)

Layer 4 (Transport)

Layer 3 (Network)

Layer 2 (Data Link) Wireless Inter‐Module Communications

(BAA Technical Area 2)Layer 1 (Physical)

Figure 2: Notional Overall Program Timeline

At each of the above milestones, the performer shall deliver a final report in the form of:

(1) a technical data package containing all software source code, libraries, executables, test cases, and documentation developed in the course of performance; all drawings, models, blueprints, circuit diagrams, data sets, specifications, and documentation developed in the course of performance; all milestone-specific deliverables as delineated in this BAA; (2) a technical manuscript of publishable quality and suitable for publication in a journal or conference proceedings documenting their technical progress and results achieved in significant detail; and (3) a programmatic final report containing financial data and other information not suitable for publication but appropriate for program documentation and planning. Apart from the delivery of these items at Milestones A, B, and C, offerors are free to propose an appropriate schedule of reviewable interim milestones, to occur at least bi-monthly. These milestones should have concrete interim deliverables (e.g., code builds, demo runs, draft documentation, etc.) and quantitative metrics (e.g., revisits of key performance attributes) associated with them. Deliverables specific to a technical area are described in each section below. Offerors are also referred to Section VI.C of this BAA for additional reporting requirements.

All milestone reviews will be conducted in the form of principal investigator (PI) meetings—occurring bi-monthly—at which all performers across the various technical areas will be present. The PI meetings will be held at Government-furnished facilities in major U.S. or international metropolitan areas with easy access by air. The Government reserves the option to make the PI meetings open events. To facilitate the exchange of information between performers within and across technical areas, selected offerors may be required to implement an associate contractor agreement (ACA) as a condition for contract award.

The Government desires Unlimited Rights to all deliverables under this program except clearly-identified commercial items, with their commercial availability described and substantiated in the proposal. Intellectual property is a proposal review criterion (see Section V) under this BAA and proposers should structure their development accordingly, especially where proprietary technical data. Offerors should take specific care to avoid inclusion of Restricted, Limited, or Government Purpose Rights items (technical data and non-commercial computer software) as part of their proposed solutions or explain how the inclusion of such items would provide better value to the Government in comparison to the receipt of Unlimited Rights to all deliverables.

The Government anticipates broadly releasing the FDK developed in the course of this effort under an open source license. An appropriate open source licensing agreement will be identified or developed by the Government in course of program execution.

Performers will be expected to mark and make available all deliverables in accordance with this license agreement.

This BAA is intentionally structured in the form of multiple independent technical areas to facilitate participation by small and non-traditional performers, as well as academic and other not-for-profit institutions. Offerors may respond to only those technical areas that are within their scope of competency. Offerors choosing to respond to multiple technical areas should submit separate proposals to each technical area.

To further and facilitate the development of robust and ubiquitous industry-wide standards and promote a space “global commons,” international participation in this solicitation is welcomed. The designation of technologies developed under this BAA with respect to export control regulations is to be determined. As a precaution, all offerors should plan, immediately upon award, to commence implementation of a technical assistance agreement (TAA) to encompass all U.S. and non-U.S. awardees under this BAA.

The Government anticipates funding this effort with RDT&E Budget Activity 3 (“6.3”), Advanced Technology Development funds.

A limited amount of RDT&E Budget Activity 2 (“6.2”), Applied Research funds may be available on a case-by-case basis as needed to enable academic institutions performing work on campus to participate without pre-publication review restrictions.

Technical Area One: Design Tools for Adaptable Systems

An essential ingredient for the widespread development and employment of fractionated architectures is the maturation of a set of design tools that enable the explicit trade-off between system “–ilities,” such as adaptability6 and survivability,7 and traditional design

6 Adaptability is defined as the capacity of a system to retain or enhance its functionality through extrinsic action in the face of uncertainty, i.e., in response to anticipated or unanticipated stimuli, events, or changes in context that may be exogenous or endogenous to the system. It is synonymous with flexibility.

attributes, such as size, weight, power, cost, reliability, and performance. This design toolset should help answer two questions. First, acknowledging that a fractionated counterpart to a single individual monolithic system may cost more, when does a fractionated architecture make sense? When does the business case close? Specifically, when does an evaluation of the expectation of net present value show the fractionated alternative superior to a traditional architecture? And second, assuming the business case does close, how should a system be optimally fractionated?—how many modules should it have?—how should functionality be distributed among those modules?—what degree of cluster-level redundancy is needed and how is it best attained?

Previous DARPA-sponsored research culminated in the development of several Value- Centric Design Methodologies (VCDMs) to address a subset of these questions.8 However, offerors should note that this technical area neither pre-supposes nor requires any specific approach to the problem of space architecture design in the face of uncertainty. Proposed approaches should, however, be technically sound and firmly based in established theory in fields such as microeconomics, decision analysis, and probabilistic methods. When considering the range of uncertainties that give rise to the need for system adaptability and survivability, offerors should include at least:

technology development risks, supply chain delays, changes in user needs, program funding fluctuations, launch failures, component failures, orbital debris, and technological obsolescence.

The end state vision at the conclusion of the base and two option efforts would be for a polished, validated, well-documented, user-friendly software tool or suite of tools that could be employed by industry, government, or university-level students to analyze and design a wide range of space architectures, compute a measure of their adaptability and survivability, and enable optimization and trades between these metrics and traditional system attributes.

In addition to deliverable requirements as described in the Program Scope & Structure section above, offerors should note the following expectations for milestone deliverables:

7 Survivability is defined as the capacity of a system to retain its functionality without extrinsic action in the face of uncertainty, i.e., in response to anticipated or unanticipated stimuli, events, or changes in context that may be exogenous or endogenous to the system. It is synonymous with robustness.

8 See, e.g., Brown, O.C., Eremenko, P., and Collopy, P.D., “Value-Centric Design Methodologies for Fractionated Spacecraft: Progress Summary,” Paper No. AIAA-2009-6540, AIAA Space 2009 Conference & Exposition, Pasadena, Calif., 14-17 September 2009.

Table 1: Specific Deliverables for Technical Area One Milestone Deliverables A (6 months from contract award)

Algorithm development complete Prototype algorithm implementation Notional end-to-end test cases demonstrated

B (18 months from contract award)

Fully-functional, polished, well-documented, user-friendly software tool delivered

C (30 months from contract award)

Input data sets covering a broad range of applications developed

Tool is appropriately validated such that it can immediately be employed with confidence for subsequent design and analysis of major national security space systems.

In addition to proposal preparation guidance described in Section IV.B.5 below, offerors should include in the Technical Approach section of the proposal:

• Description of the proposed metric(s) and algorithmic approach, and the technical substantiation thereof;

• Notional architecture and description of inputs, outputs, and functionality for the proposed software tool;

• Detailed software tool development plan;

• Detailed software verification and validation plan.

Technical Area Two: Wireless Inter-Module Communications

The inter-module wireless communications architecture is the Layer 1 and Layer 2 backbone of the cluster network for the System F6 demonstration system. DARPA is interested in a wide spectrum of innovative architecture and standards solutions to this problem. No specific throughput, operating range, or other performance requirements are imposed at this time. Offerors should describe the range of capability, the benefits, and the potential risks or disadvantages of their proposed solution.

The inter-module communications architecture must support the on-orbit demonstrations described previously in the Program Objectives section. In particular, it must support the addition and removal of new modules, support the variation in geometry associated with cluster flight, and maintain communications during the defensive scatter maneuver. The proposed solution should maximize throughput and availability, while minimizing size, weight, and power. Other attributes of interest are interference resistance and cross-link signal detection range. The architecture should allow for a variety of encryption standards.9 Offerors should be acutely mindful of spectrum allocations for space-to-space communications.

9 A cryptographic solution that meets defense standards for space systems communications, while remaining unclassified and shareable in an open-source and internationally collaborative environment, is desired. See, e.g., http://www.dtic.mil/whs/directives/corres/pdf/858101p.pdf and http://www.nsa.gov/ia/programs/suiteb_cryptography/ for additional information.

The base period of performance will be focused on the preliminary design of a prototype transceiver unit10 and the development of a corresponding parametric performance model which will be delivered to the Government at Milestone A in support of trade studies.

Subsequent option periods will be dedicated to detailed design, prototype development, and ultimately flight unit development. Throughout the course of execution, a Layer 1 and Layer 2 interface specification, documentation, and reference design implementation will be developed and refined for inclusion in the FDK.

Table 2: Specific Deliverables for Technical Area Two Milestone Deliverables A (6 months from contract award)

Preliminary design of the proposed solution Draft Layer 1 and 2 input to the FDK Parametric performance model as per Table 3

B (18 months from contract award)

Detailed design of the proposed solution Final Layer 1 and 2 input to the FDK Fabrication of at least four fully-functional terrestrial prototype transceiver units

Testing of above in a representative environment with appropriate consideration given to cluster size, geometry, and dynamics

C (30 months from contract award)

Delivery of at least four space-qualified, flight-ready transceiver units

The parametric model referenced above as a Milestone A deliverable should be delivered in tabular form with reasonable resolution and span the following parameter space:

Table 3: Milestone A Parametric Model Requirements for Technical Area Two Input Parameters Outputs Number of modules [4 – 20] Inter-module distance [100 m – 100 km] Relative angles between each module

Transceiver dimensions Transceiver mass Transceiver input power Pointing accuracy needed from spacecraft

Pointing knowledge needed from spacecraft

Point-to-point data throughput Point-to-point data latency Inter-module link topologies

10 The transceiver unit, as used here, is a complete wireless communications package for a single satellite module, including any antennas, optics, gimbals, etc.

• Estimates of signaling and packet overhead;

• Operating frequency bands and associated interference environment;

• Estimates of frame error rate (FER) due to motion, noise, interference;

• Estimates of inter-module link throughput and latency;

• Link topology as a function of the number of inter-module antennas and antenna pointing;

• Estimated size, weight, power, and gate count of the transceiver unit;

• Antennas or optical aperture description, including neighbor definition and pointing strategy;

• Modulation / coding schemes including link adaptation strategies and associated packet sizes;

• ADC/DAC realization-clock rate and number of effective bits;

• Maximum range for network discovery (distance at which a module can first be recognized and initialized on the network);

• Rationale for choice of frequency and bandwidth, substantiation for why a corresponding spectrum allocation is feasible and the risks associated therewith;

• Draft completed Form DD1494, “Application for Equipment Frequency

Allocation” for the proposed solution at the end of proposal section 2.3 “Technical Approach.” The form consists of six pages and a system line diagram.

These seven pages will not count against the total page count for section 2.3.

Technical Area Three: Information Architecture

The information architecture developed in this technical area will span the entire set of functions from Layer 3 upward needed to support the on-orbit demonstrations described previously in the Program Objectives section. The information architecture has three principal functions. First, it must expose spacecraft devices as network-addressable resources on the cluster network. As a corollary, it should also be capable of exposing terrestrial devices as network-addressable resources on the cluster network, subject to link availability.11 To this end, the architecture must provide seamless routing and prioritization of data across multiple cluster‐to‐ground data paths, enabling the sharing of data between nodes and the transfer of latency‐insensitive tasks between a space‐based and terrestrially‐based computing resource, while guaranteeing the real-time delivery of critical data across the network for mission‐critical applications.

Second, it must provide the capability to share a resource—a flight processor, a mission processor, a data storage device, communications links (both to a GEO relay and directly from the cluster to the ground), a navigation sensor (such as a star tracker), and a mission

11 DARPA is pursuing a parallel effort for the development of a persistent broadband ground connectivity solution for spacecraft in LEO utilizing the commercial Inmarsat Broadband Global Area Network (BGAN) service. Part of the System F6 on-orbit demonstration is likely to include the ability to use a terrestrially-based computation resource for a closed-loop on-orbit application.

sensor—across the wireless cluster network with real-time guarantees. It must also be able to enable the simultaneous utilization of each such resource by multiple processes, applications, or users operating in multiple different security domains. More broadly, the architecture must dynamically allocate resources amongst multiple payloads, providing guaranteed performance for mission-critical applications.

Third, the information architecture should provide real-time fault tolerance. In other words, it should enable the reconfiguration of network routing paths and location of processes or applications within the cluster network rapidly and autonomously in the face of network degradation, component failure, or addition/removal of resources from the network. The fault detection and recovery architecture will seamlessly integrate with any spacecraft‐level fault management system, enabling each spacecraft to independently maintain safety‐critical functions (e.g. maintain power positive state and independent communication link) at any point, while managing resources and anomalies such as transient outage as a result of orbital maneuvers, module entry/exit from the cluster, and reallocation of resources due to equipment faults.

The information architecture must deliver these functional capabilities and support the corresponding on-orbit demonstrations in the face of several constraints. First, it must operate within the constraints of hardware which can reasonably be expected to operate in the LEO space environment over the course of 24 months. If the anticipated computational burden of the proposed solution exceeds the capability offered by existing space-qualified devices, it is the offeror’s burden to articulate in detail the proposed approach to operating in a space environment. Second, the information architecture must meet link encryption requirements needed for space operations.12 And third, the information architecture must incorporate the information assurance features associated with a multi-level security (MLS) computing environment. The System F6 program goal is to realize a system which incorporates the principal controls associated with an accreditable MLS systems, but without submitting the architecture to a formal certification and accreditation (C&A) process as an MLS system. To that end, the principal controls which will apply to the information architecture developed under this technical area are enumerated in Appendix A to this BAA.

Verification and validation of safety-critical, distributed, real-time, and dynamically-reconfigurable software represents a unique challenge for which the existing paradigm of “test to exhaustion” is fundamentally inapplicable due to the near-infinite state space of such systems. Offerors are expected to propose innovative—yet practical, given the short timeline to flight—approaches that can lead to a reasonable level of assurance that safety-critical functions will be maintained in the course of the demonstration mission.

The base period of performance will be focused on the preliminary design of the information architecture. The first option period will be dedicated to the detailed design

12 A cryptographic solution that meets defense standards for space systems communications, while remaining unclassified and shareable in an open-source and internationally collaborative environment, is desired. See, e.g., http://www.dtic.mil/whs/directives/corres/pdf/858101p.pdf and http://www.nsa.gov/ia/programs/suiteb_cryptography/ for additional information.

and implementation of the information architecture. The second option period will be dedicated to the verification and validation of the resulting architecture in preparation for flight. Throughout the course of execution, a Layer 3 through 7 interface specification, documentation, and reference implementation will be developed and refined for inclusion in the FDK.

Table 4: Specific Deliverables for Technical Area Three

A (6 months from contract award)

Preliminary design of the information architecture Draft Layer 3 through 7 input to the FDK

B (18 months from contract award)

Detailed design of the information architecture Complete implementation and documentation of the information architecture

Final Layer 3 through 7 input to the FDK

C (30 months from contract award)

Verification and validation of the information architecture

• Estimate of software overhead resources required to host the information architecture on a per-network-node basis (processor cycles/MIPS/FLOPS/etc., link bandwidth, memory);

• Estimate of time to re-allocate all applications on a node to another node on the cluster-network;

• Limits on maximum number of supportable independent security domains/levels;

• Estimated source lines of code (SLOC) or equivalent code size metric, broken down by the principal components of the information architecture;

• Information assurance approach for implementing the controls described in

Appendix A;

• Software development plan;

• Software verification and validation plan.

Technical Area Four: Cluster Flight

The principal objective of this technical area is the ability to perform multi-body cluster flight with reasonable propellant optimality, a high level of assurance that trajectories are passively safe or safe to most probable on-orbit failure modes, and simultaneous capability for rapid maneuver planning as needed for a defensive scatter maneuver, which remains a significant theoretical novelty and practical implementation challenge.

Algorithm development should be performed over a parametric range of cluster radii and geometries to enable subsequent trades with the wireless cross-link architecture.

In order to support the on-orbit demonstrations described previously in the Program Objectives section, the cluster flight architecture must support long-duration cluster station-keeping by maintaining a stable relative geometry to support wireless communications, and support module ingress/egress from the cluster. A rapid maneuvering capability to perform a defensive scatter maneuver is also required. Offerors should develop and articulate a holistic approach to collision avoidance under various failure scenarios that may include a combination of long-duration passively safe orbits, fault detection, active avoidance, and other techniques.

Routine cluster operations must be semi-autonomous such that a minimal ground crew can operate clusters of various sizes, and such that the size of the ground crew is invariant with cluster size. The cluster flight architecture must incorporate the corresponding ground segment and ground control software. Interfaces and behaviors between cluster flight operations and bus operations should be clearly identified and documented.

The base period of performance will be focused on the preliminary design of the cluster flight approach and architecture, and the development of a corresponding parametric performance model which will be delivered to the Government at Milestone A in support of trade studies. The first option period will be dedicated to the detailed design and implementation of the cluster flight architecture. The second option period will be dedicated to the verification and validation of the resulting architecture in preparation for flight. Throughout the course of execution, cluster flight interface specification, documentation, and reference implementation will be developed and refined for inclusion in the FDK.

Table 5: Specific Deliverables for Technical Area Four

A (6 months from contract award)

Preliminary design of the proposed solution Draft cluster flight behavior/rules input to the FDK Parametric performance model as per Table 6

B (18 months from contract award)

Detailed design of the proposed solution Complete implementation and documentation of the cluster flight architecture

Final cluster flight behavior/rules input to the FDK C (30 months from contract award)

Verification and validation of the cluster flight architecture

The parametric model referenced above as a Milestone A deliverable should be delivered in tabular form with reasonable resolution and span the following parameter space:

Table 6: Milestone A Parametric Model Requirements for Technical Area Four Input Parameters Outputs Number of modules [4 – 20] Altitude [300 km – 1500 km] Inter-module distances [100 m – 100 km] Cluster configurations (e.g. string of pearls) [at least 3, selected by performer]

Relative geometries between modules in the cluster

Worst-case collision probability for any single mode failure

• Estimates of nominal daily station-keeping ΔV;

• Estimates of scatter separation geometry and required ΔV;

• Self-collision (i.e., two modules within the cluster) probability per day;

• Estimate of software overhead resources required to host the cluster flight software on a per-module and cluster basis (processor cycles/MIPS/FLOPS/etc., link bandwidth, memory);

• Estimated control loop bandwidth;

• Relative navigation sensor accuracy requirements for position and velocity;

• Depiction of at least 3 cluster configurations, along with a preliminary approach for module gathering, scatter and re-gather, and collision hazard assessment;

• Estimated source lines of code (SLOC) or equivalent code size metric, broken down by the principal components of the cluster flight software architecture;

• Software development plan;

• Software verification and validation plan.

II. AWARD INFORMATION

Multiple awards in each technical area 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. A total of approximately $69.0 million is anticipated to be available for award across all technical areas and options.

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.

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. 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, and other factors. 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. 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.

As of the date of publication of this BAA, DARPA cannot identify whether or not the work under this BAA may be considered 'fundamental research,' i.e., basic and applied research in science and engineering, the results of which ordinarily are published and shared broadly within the scientific community, as distinguished from proprietary research and from industrial development, design, production, and product utilization the results of which ordinarily are restricted for proprietary or national security reasons.

Notwithstanding this statement of expectation, DARPA is not prohibited from considering and selecting research proposals that, while perhaps not qualifying as 'fundamental research' under the foregoing definition, still meet the BAA criteria for submissions. In all cases, the Contracting Officer shall have sole discretion to select award instrument type and to negotiate all instrument provisions with selectees.

III. ELIGIBILITY INFORMATION

A. Eligible Applicants

All responsible sources capable of satisfying the Government's needs may submit a proposal that shall be considered by DARPA. DARPA encourages the participation of small businesses, academia, non-traditional, and international performers in this solicitation.

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

Federally Funded Research and Development Centers (FFRDCs) and government entities (government/national laboratories, military educational institutions, etc.) are subject to applicable direct competition limitations and cannot propose to this BAA in any capacity unless they address the following conditions. FFRDCs must clearly demonstrate that the proposed work is not otherwise available from the private sector AND must also provide a letter on letterhead from their sponsoring organization citing the specific authority establishing their eligibility to propose to government solicitations and compete with industry, and compliance with the associated FFRDC sponsor agreement and terms and conditions. This information is required for FFRDCs proposing to be prime or subcontractors. 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 (as well as, where relevant, contractual authority) establishing their ability to propose to Government solicitations. At the present time, DARPA does not consider 15 U.S.C. 3710a to be sufficient legal authority to show eligibility. While 10 U.S.C. 2539b may be the appropriate statutory starting point for some entities, specific supporting regulatory guidance, together with evidence of agency approval, will still be required to fully establish eligibility. DARPA will consider eligibility submissions on a case-by-case basis; however, the burden to prove eligibility for all team members rests solely with the proposer.

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

Current federal employees are prohibited from participating in particular matters involving conflicting financial, employment, and representational interests (18 USC 203, 205, and 208.). The DARPA Program Manager for this BAA is Paul Eremenko. Once the proposals have been received, and prior to the start of proposal evaluations, the Government will assess potential conflicts of interest and will promptly notify the proposer if any appear to exist. (Please note the Government assessment does NOT affect, offset, or mitigate the proposer’s own duty to give full notice and planned mitigation for all potential organizational conflicts, as discussed below.)

All Proposers and proposed subcontractors must affirm whether they are providing scientific, engineering, and technical assistance (SETA) or similar support to any DARPA technical office(s) through an active contract or subcontract. All affirmations must state which office(s) the Proposer supports and identify the prime contract numbers.

Affirmations shall be furnished at the time of proposal submission. All facts relevant to the existence or potential existence of organizational conflicts of interest (FAR 9.5) must be disclosed. The disclosure shall include a description of the action the Proposer has taken or proposes to take to avoid, neutralize, or mitigate such conflict. In accordance with FAR 9.503 and without prior approval or a waiver from the DARPA Director, a Contractor cannot simultaneously be a SETA and Performer. Proposals that fail to fully disclose potential conflicts of interests and/or do not have plans to mitigate this conflict will be rejected without technical evaluation and withdrawn from further consideration for award.

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

B. Cost Sharing/Matching

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

IV. APPLICATION AND SUBMISSION INFORMATION

A. Address to Request Application Package

This solicitation contains all information required to submit a proposal. No additional forms, kits, or other materials are needed. This notice constitutes the total BAA. No additional information is available, nor will a formal Request for Proposal (RFP) or additional solicitation regarding this announcement be issued. Requests for same will be disregarded.

B. Content and Form of Application Submission

1. Security and Proprietary Issues

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

The Government anticipates proposals submitted under this BAA will be unclassified.

However, if a proposal is submitted as “Classified National Security Information” as defined by Executive Order 13526 as amended, then the information must be marked and protected as though classified at the appropriate classification level and then submitted to DARPA for a final classification determination.

Proposers choosing to submit a classified proposal from other classified sources must first receive permission from the respective Original Classification Authority in order to use their information in replying to this BAA. Applicable classification guide(s) should also be submitted to ensure the proposal is protected at the appropriate classification level.

Classified submissions shall be appropriately and conspicuously marked with the proposed classification level and declassification date. Submissions requiring DARPA to make a final classification determination shall be marked as follows:

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

Classified submissions shall be in accordance with the following guidance:

Confidential and Secret Collateral Information: Use classification and marking guidance provided by previously issued security classification guides, the Information Security Regulation (DoD 5200.1-R), and the National Industrial Security Program Operating Manual (DoD 5220.22-M) when marking and transmitting information previously classified by another Original Classification Authority. Classified information at the Confidential and Secret level may be mailed via appropriate U.S.

Postal Service methods (e.g., (USPS) Registered Mail or USPS Express Mail). All classified information will be enclosed in opaque inner and outer covers and double wrapped. The inner envelope shall be sealed and plainly marked with the assigned classification and addresses of both sender and addressee. The inner envelope shall be addressed to:

Defense Advanced Research Projects Agency Attn: TTO Reference: BAA 11-01 3701 North Fairfax Drive Arlington, VA 22203-1714

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

Defense Advanced Research Projects Agency Security & Intelligence Directorate, Attn: CDR 3701 North Fairfax Drive Arlington, VA 22203-1714

All Top Secret materials: Top Secret information should be hand carried by an appropriately cleared and authorized courier to the DARPA CDR. Prior to traveling, the courier shall contact the DARPA CDR at 571-218-4842 to coordinate arrival and delivery.

Special Access Program (SAP) Information: SAP information must be transmitted via approved methods. Prior to transmitting SAP information, contact the DARPA SAPCO at 703-526-4052 for instructions.

Sensitive Compartmented Information (SCI): SCI must be transmitted via approved methods. Prior to transmitting SCI, contact the DARPA Special Security Office (SSO) at 703-248-7213 for instructions.

Proprietary Data: All proposals containing proprietary data should have the cover page and each page containing proprietary data clearly marked as containing proprietary data. It is the Proposer’s responsibility to clearly define to the Government what is considered proprietary data.

Security classification guidance via a DD Form 254, “DoD Contract Security Classification Specification,” will not be provided at this time since DARPA is soliciting ideas only. After reviewing the incoming proposals, if a determination is made that the award instrument may result in access to classified information a DD Form 254 will be issued and attached as part of the award.

Proposers must have existing and in-place prior to execution of an award, approved capabilities (personnel and facilities) to perform research and development at the classification level they propose. It is the policy of DARPA to treat all proposals as competitive information, and to disclose their contents only for the purpose of evaluation. Proposals will not be returned. The original of each proposal received will be retained at DARPA and all other non-required copies destroyed. A certification of destruction may be requested, provided the formal request is received at this office within 5 days after unsuccessful notification.

2. Proposal Submission Information

Proposers are required to submit full proposals by the time and date specified in this BAA in order to be considered during the initial round of selections. DARPA may evaluate proposals received after this date for a period up to six months from the date of posting on FedBizOpps. Ability to review late submissions remains contingent on availability of funds.

DARPA will accept unclassified proposals submitted under this BAA by mail or hand-delivery. Proposals must be submitted to:

DARPA/TTO

Attn: BAA 11-01 3701 North Fairfax Drive Arlington, VA 22203-1714

Proposers must submit an original and four (4) copies of the full proposal and two (2) CD-ROMs each containing an electronic copy of the full proposal as a single PDF file.

Each copy must be clearly labeled with BAA 11-01, proposer organization, proposal title (short title recommended), and Copy _ of 5.

Facsimile or electronic submissions will not be accepted.

For hand deliveries, the courier should deliver the package to the DARPA Visitor Control Center at the address specified above. The outer package, as well as the cover page of the proposal, must be marked “BAA-11-01.”

Responses to this BAA will not be returned.

3. Proposal Format

The proposal shall be delivered in a single volume including both technical and cost information. Proposals not meeting the format described in this BAA may not be reviewed.

The proposal shall include the following sections, each starting on a new page (where a "page" is 8-1/2 by 11 inches with type not smaller than 12 point, charts may use 10 point font, margins not smaller than 1 inch, and line spacing not smaller than single-spaced).

Fold-outs up to 11 by 17 inches may be used but will be counted as two pages. All submissions must be in English.