HQ085020S0002.pdf

Broad Agency Announcement (BAA)

Space Development Agency (SDA)

Mission-Specific Application Prototypes (MSAP)

HQ085020S0002

June 26, 2020

I. OVERVIEW INFORMATION

II. FULL TEXT OF THE ANNOUNCEMENT

A. Funding Opportunity Description B. Background C. Prototype Development Guidance D. Technical Areas

III. AWARD INFORMATION

A. General Award Information

IV. ELIGIBILITY INFORMATION

A. Eligible Applicants B. Organizational Conflicts of Interest C. Cost Sharing/Matching

V. APPLICATION AND SUBMISSION INFORMATION

A. Application Assistance B. Content and Form of Submission C. Submission Instructions D. Funding Restrictions E. Other Submission Requirements

VI. APPLICATION REVIEW INFORMATION

A. Evaluation Criteria B. Review of Submissions

VII. AWARD ADMINISTRATION INFORMATION

A. Selection Notices and Notifications B. Administrative and National Policy Requirements C. Reporting D. Electronic Systems

VIII. AGENCY CONTACTS

I. OVERVIEW INFORMATION

• Federal Agency Name – Space Development Agency

• Funding Opportunity Title – Mission-Specific Application Prototypes

• Announcement Type – Initial Announcement

• Funding Opportunity Number – HQ085020S0002

• Dates o Posting Date: June 26, 2020 o Executive Summary Due Date and Time: July 15, 2020 at 2359 Eastern Time o Anticipated Executive Summary Feedback Date: July 24, 2020 o Proposal Due Date and Time: August 21, 2020 at 2359 Eastern Time

• Concise description of the funding opportunity – The Space Development Agency is soliciting executive summaries and proposals for software prototypes that enable the mission-specific needs of the National Defense Space Architecture (NDSA). The three technical areas addressed in this BAA are (1) Custody, (2) Navigation, and (3) Tracking.

The developed prototypes will be used to demonstrate novel technical capabilities as well as inform architecture trades between ground and on-orbit processing. The period of performance for all proposed efforts should end no later than 30 September, 2021.

• Anticipated individual awards – Multiple awards are anticipated.

• Types of instruments that may be awarded – Procurement (FAR-based) contract or other transaction.

• Agency contact: Technical and administrative point of contact for this effort can be reached via: osd.pentagon.ousd-r-e.mbx.hq085020s0002@mail.mil

• Space Development Agency

ATTN: HQ085020S0002

3030 Defense Pentagon Washington, DC 20301-0001 mailto:osd.pentagon.ousd-r-e.mbx.hq085020s0002@mail.mil

II. FULL TEXT OF THE ANNOUNCEMENT

A. Funding Opportunity Description

This publication constitutes a Broad Agency Announcement (BAA) as contemplated in

Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016. Any resultant award negotiations will follow all pertinent law and regulation, and any negotiations and/or awards for procurement contracts will use procedures under FAR 15.4, Contract Pricing, as specified in the BAA. The following information is for those wishing to respond to the BAA.

B. Background

The National Defense Strategy (NDS) acknowledges that space is vital to the U.S. way of life, our national security, and modern warfare. In an era of renewed great power competition, maintaining our advantage in space is critical to winning these long-term strategic competitions.

Potential adversaries seek to undermine this goal by employing strategies that exploit real or perceived vulnerabilities in our current and planned National Security Space systems. In addition, these potential adversaries are developing and demonstrating multi-domain threats to national security much faster than we can deploy responsive space-based capabilities. The Department of Defense (DoD) established SDA on 12 March 2019 as a separate Defense Agency under the control, direction, and authority of the Under Secretary of Defense for Research and Engineering (USD(R&E)) as a response to this problem.

SDA is responsible for orchestrating the Department's future threat-driven space architecture and accelerating the development and fielding of new military space capabilities necessary to ensure our technological and military advantage in space for national defense. To achieve this mission, SDA will unify and integrate next-generation space capabilities to deliver the National Defense Space Architecture (NDSA), a resilient military sensing and data transport capability via a proliferated space architecture primarily in Low Earth Orbit (LEO). SDA will not necessarily develop and field all capabilities of the NDSA but rather orchestrate those efforts across DoD and fill in gaps in capabilities while providing the integrated architecture.

Initially the NDSA is comprised of the following layers, addressing the critical priorities for space identified within the DoD Space Vision:

• Transport Layer, to provide assured, resilient, low-latency military data and connectivity worldwide to the full range of warfighter platforms;

• Battle Management Command Control and Communications Layer (BMC3), to provide architecture tasking, mission command and control, and data dissemination to support time-sensitive kill chain closure at campaign scales;

• Tracking Layer, to provide global indications, warning, tracking, and targeting of advanced missile system threats, including hypersonic missile systems;

• Custody Layer, to provide 24x7, all-weather custody of time-sensitive, surface mobile targets left-of-launch. Custody supports creation of firing solutions for advanced weapons systems;

• Navigation Layer, to provide alternate position, navigation, and timing (A-PNT) for GPS-denied environments;

• Support Layer, to enable ground and launch segments to support a responsive space architecture.

Organizationally, SDA is structured with product delivery cells (e.g., Transport Cell) focused on each of these functional capabilities, as well as an Emerging Capabilities Cell to incubate new functional capabilities and address emerging or evolving threats, such as a Deterrence Capability to deter hostile action in deep space, beyond Geosynchronous Earth Orbit (GEO) up to lunar distances.

SDA's mission begins and ends with the warfighter. SDA recognizes that sufficient or

"good enough" capabilities in the hands of the warfighter sooner may be better than delivering the perfect solution too late. SDA will deliver capabilities to our joint warfighting forces in two-year tranches.

Tranche 0, or the warfighter immersion tranche, will be delivered as early as Fiscal Year

(FY) 2022 and consists of tens of Transport and Tracking layer satellites providing periodic, regional sensing and data transport capabilities, including the capability to detect hypersonic glide vehicles and to disseminate time-sensitive firing solutions over tactical data links.

SDA envisions a capstone demonstration in the 2nd and 3rd Quarters of FY23 integrating all of these elements to allow the warfighter to gain familiarity with the capabilities of the architecture and to provide feedback prior to the larger investments of Tranche 1 (henceforth “Tranche 0 Capstone”). The broader goals of the Tranche 0 Capstone are to demonstrate:

• Interoperable network of Transport satellites that can pass data to warfighter platforms via tactical data link.

• Tracking satellites with OPIR sensors that are sensitive enough to show scaling for global persistent advanced missile detection and tracking, can pull tracks out of clutter, and send targeting solutions via tactical data links.

• Custody data able to be sent from mission partners via ground to Transport satellites and pass data for targeting solutions via Transport tactical data links. Custody data fusion and tip and cue processing demonstrated on ground to emulate future onboard processing.

• Experimentation of the BMC3 module for on-orbit software updates and mission-specific onboard processing.

• Limited alternate position, navigation, and timing (A-PNT) for GPS-denied environments.

C. Prototype Development Guidance

The vision for the BMC3 layer is that it will integrate all of the functional layers in the NDSA to deliver capabilities to the warfighter that mitigate emerging threats and close time-critical kill chains. All NDSA satellites will be interoperable at the physical, data link, and network layers of the Open Systems Interconnection (OSI) model. The BMC3 hardware module will reside on each of those satellites and will utilize software applications to direct higher-order functions, maintain a common operating picture, process time-sensitive data and provide an application layer interface with the ground segment. The on-orbit mesh network and tactical communications provided by the Transport layer will be used to transfer data and actionable intelligence to other air, space, maritime, and ground nodes.

Software applications within the on-orbit BMC3 module will need to tackle evolving threats, overwhelming volumes of data, and an increasingly fast operational tempo. Threats constantly evolve, so the plan is to maximize on-orbit compute and utilize on-orbit software updates to fix vulnerabilities and add new capabilities for the warfighter. Every new tranche of satellites will provide the opportunity to update the onboard processing to the latest cutting-edge performance. Once the initial software and hardware architecture is in place, it will enable the use of spiral development to deliver on-orbit capability to meet the most pressing needs of the warfighter. The timeline, expense, and complexity of software improvements will be minimized through the use of a modular and open architecture and a standard Software Development Kit.

The entire architecture will be built on a solid foundation in Cyber and Information Assurance to secure the on-orbit mesh network and software applications.

With the overall BMC3 vision in mind, SDA is using this Mission-Specific Application Prototypes (MSAP) BAA to develop software prototypes in three different technical areas associated with the Custody, Navigation, and Tracking layers. The details for each technical area are listed in § II.D, and the recommended deliverables are listed in § V.B.2. Prototypes are expected to flesh out the hardware, software, and input data dependencies required for a successful transition to operations. The resulting prototypes will also help inform ongoing architecture trades between ground and on-orbit processing.

The transition of capabilities to the on-orbit BMC3 modules will be an iterative process that starts with everything on the ground. The timing of when specific capabilities are migrated to the BMC3 module on-orbit will be driven by mission priorities and military utility, technical feasibility, and cost effectiveness. Selected performers on this BAA will also develop the end-to-end concept of operations (CONOPS) that would be required to transition their prototype to the optimal operational configuration. A specific capability may reside wholly within on-orbit BMC3 modules, or it may require a complementary ground component. The performer is expected to ensure their CONOPS satisfies the mission needs outlined under the specific technical areas below.

The NDSA BMC3 architecture is still in development, so the focus of MSAP BAA will be on prototype demonstration rather than specific implementation to the exact target architecture.

Performers are encouraged to utilize the draft Software Development Standard provided in Attachment 1 to align with SDA’s current thoughts on software development approaches. SDA is also interested in industry feedback on the draft standard and approach. Unless otherwise specified, performers are expected to provide their own software development environment, training data, and demonstration capability. SDA plans to create a standard BMC3 software development environment and Software Development Kit for the eventual development of onboard Space Vehicle Applications (SVAs), but they will not be available until the end of FY21. The prototype development funded under this BAA will conclude by the end of FY21, so the resulting code/algorithms will be demonstrated in the performers’ ground development environment. Once the BMC3 development environment and SDK are available, mature portions of the BAA developed prototypes could be ported to the flight BMC3 module for on-orbit testing within Tranche 0 or Tranche 1 under a separate solicitation. Prototypes should be hardware-agnostic and minimize dependencies on proprietary interfaces in order to streamline any further development of prototypes into compliant SVAs.

D. Technical Areas

1. Technical Area 1 - Custody

a) Custody Mission

The Custody Layer will maintain track of left-of-launch time-critical targets with sufficient confidence and quality to enable the creation of a firing solution from the sensor to the warfighter in operationally relevant timelines. Timelines will be shortened through increasing levels of automation as trust is established. The automation levels are defined further in the Additional “Attachment 2 - Custody Layer Reference Material” document, § A (henceforth referred to as “Reference Material”). The Custody Layer will serve the warfighter who can request data in a particular Area of Interest (AOI) or a specific target to be tracked.

Custody does not anticipate developing and fielding its own spaceborne sensing capabilities, but will orchestrate and partner with space-based tactical-ISR capabilities (henceforth, referred to as “Custody sensor mission partners”) and fill gaps where necessary.

Custody will also develop software to fuse relevant Multi-INT data to enable firing solutions (henceforth, referred to as “Custody application”). Multi-INT data will be utilized to increase confidence that a target is correctly identified, improve the accuracy of a geolocation, and/or identify emergent features not present in individual sensors or single phenomenologies. This software will initially execute on the ground, but could eventually be migrated to a form factor consistent and compatible with the BMC3 architecture. High-consequence decisions will be made based on the fusion and sense-making that SDA will use and, as such, several key guidelines outlined in the Reference Material § B should be followed. For Tranche 0 demonstrations, SDA anticipates partnering with national and tactical organizations with the capability to fuse Multi-INT data as well (henceforth, referred to as “Custody data fusion partners”). SDA is currently negotiating an agreement to partner with the Deputy Chief of Naval

Operations (DCNO) Information Dominance (DCNO N2/N6) in its developments and operations accomplished through the Naval Integrated Fires Element (NIFE)1.

b) Custody Architecture

Custody will rely on Transport to provide resilient, low-latency connectivity worldwide to warfighter platforms. The high-capacity crosslinks on the Transport Layer will allow mission partners to transfer data for either bulk data dissemination or data fusion. The fusion application will reside within the BMC3 module onboard NDSA satellites. BMC3 will provide core application management, communication, and connectivity between Custody application execution and data flow management from one satellite to the next. The Custody Layer will run both in space and on the ground. Ground-based fusion will involve more computationally-intensive applications, while the onboard application will be simplified and provide automated operations. Fusion algorithms ranging from combining sub-object data with other sensing phenomena (Level 0) to eventually including human interaction (Level 5) will be implemented.

Levels of fusion are defined in further detail in the Reference Material, § C. Algorithms will be trained on the ground to achieve a particular probability of detection and false alarm rate or accuracy. Once the algorithms are trained and the results verified, the locked and trusted versions will be uploaded to the space nodes.

When data fusion is performed, satisfaction will be assessed to initiate new requests for data if the confidence and/or quality is not sufficient to support tactical edge firing solutions.

Tips will include available data and needed data. Cues will be created that request additional collects or access to other data sources. Note the definitions for tips/cues in the Reference Material document, § D. BMC3 will request additional data needed to create a fusion solution by interfacing with partner sensing constellations via the Transport Layer, sending requests and adjudicating the requests against other priorities. Ultimately, the Custody application will produce firing solutions or tips/cues for distribution to the tactical edge.

c) Custody Prototype Focus Areas

In the near term (FY20-22), the Custody Layer will develop and demonstrate functionality towards its longer-term vision via the Tranche 0 Capstone in FY 2023. The initial focus will be on the prototype multi-INT fusion software application that is the focus of this BAA. In parallel, SDA intends to work with N2N6 to integrate the NIFE’s ground-based fusion capabilities into the NDSA for low-latency dissemination of firing solutions to the tactical edge using the Transport layer. For Custody, the Tranche 0 Capstone culminates with sensor mission partner data passing from ground terminals, ground-based processing and fusing, and the

1 In August of 2018 the Navy Integrated Fires Element (NIFE) was commissioned and this marked the beginning of a new high-end warfighting capability, made possible through the novel integration of intelligence expertise, warfare disciplines, and technology. Initially, at IOC the NIFE was tasked to support eight hours of operation, five days per week, and to maintain cognizance over only one Area of Responsibility (AOR) at a time. As the NIFE has matured and increased capabilities brought online, its utility across the DoD for its unique tracking and targeting capability has never been more apparent, and the NIFE has been asked to expand to meeting 24x7, 365 multi-AOR and multi-domain operational support to Combatant Commanders and Allies. Currently, dual AOR feasibility exists, with Multi-AOR support in progress. NIFE also works with CUXS (NUST) and collaborates with MTCE (multi-domain live sources for target validation and mission support). This capability is now supporting USN, USMC, USCG and USA elements in real world and live exercise trainings and integration.

creation of a firing solution that is disseminated to the tactical edge via Link-16. See Figure 2, Functional Block Diagram, in § I of the Reference Material and associated top level requirements in § H.

For Tranche 0, while the threshold capability focuses on the integration of N2N6/NIFE capabilities into the NDSA, the objective capability includes mission specific processing, algorithms and applications for testing and evaluation. As such, proposals are requested to be end-to-end solutions to the Custody mission that will enable development of algorithms that can be encoded to a small satellite on-board processor for demonstration of the Custody functions on orbit in stages. End-to-end refers to the full range of activities needed to develop software-based multi-INT fusion models/algorithms that will maintain track of targets in all-weather and in timelines short enough to support geolocation and track leading to a weapons quality firing solution. This can include, but is not limited to:

• Definition of models/algorithms and the suitability/applicability of the fused results to specifically identified weapons systems (see Table 1 in Reference Material § G, Algorithms Definition and Table 3, Enabling Tracking of Left-of-Launch Time- Sensitive Targets for the suggested response format to ensure enough details are included)

• Prototyping and potential deployment of fusion capability to ground-based platforms that would add value to the NIFE; development of an end-to-end CONOPS that would be required to transition the prototype to a space-based application and eventually the optimal operational configuration. (see Reference Material § F, Objectivities and Emphasis Areas for SDA Custody Mission in developing CONOPs and Table 4 in Reference Material § G, Ground and In-Space Processor Units Required for the suggested response format)

• Verification and validation of the models/algorithms; identification, collection, storage and delivery of training data for these models; Near-real time connectivity to Multi-INT fusion sensor data sources; Training of the models in performer-provided software development environment; Modeling and Simulation capabilities to predict algorithm behavior and demonstration capability (see Table 2 in Reference Material § G, Algorithm Validation for the suggested response format).

• Creation of a fusion watchdog with the ability to maintain provenance of sensor data up to the TS//SCI level to ensure data is only used once in the fusion solution

• Tip/cue capability to obtain additional data to improve geolocation and enable a targeting solution

The performer needs to clearly identify which of these end-to-end activities it will perform and which are expected as Government Furnished Information/Equipment (GFI/GFE).

GFI/GFE needs must be specified in sufficient detail for SDA to either provide itself or to procure a performer to provide. Please see § E in the Reference Material for additional guidance for proposal submissions.

2. Technical Area 2 - Navigation

a) Navigation Mission

The SDA enterprise operations will require precise knowledge of each of the SDA satellites’ Position, Navigation, and Timing (PNT). This PNT data will be used to support satellite operations including providing PNT data for the various integrated SDA payloads. In Tranche 0, these PNT services will be supported by on-board GPS receivers, however, to support mission robustness, SDA will conduct experiments performing Tranche 0 mission operations in a GPS-denied environment for extended periods.

b) Navigation Architecture

The Navigation layer requires an advanced software architecture that combines inputs from multiple sources to ensure a robust PNT solution. When GPS service is available, GPS will likely be the primary source of PNT, but will be aided by additional inputs from the platform’s on-board systems such as the inertial navigation system (INS), star tracker and clock.

Additionally, the platform’s integrated crosslinks are expected to provide accurate, persistent relative ranging/timing information between the SDA satellites with intermittent space-to-ground range measurement. The crosslinks’ measurements are the key to operating for long durations in a GPS-denied environment.

The SDA satellite crosslinks require precise knowledge of the satellite position, velocity, and time (PVT) and orientation relative to the rest of the SDA constellation for link closure. A PVT prediction service will be included in this SDA PNT architecture baseline. These high-accuracy PVT predictions will be included in crosslink data exchanged between satellites and to the ground terminals. As part of this development all interfaces are to be documented and coordinated with hardware elements.

c) Navigation Prototype Focus Areas

The Navigation layer is seeking proposed solutions for an integrated satellite PNT algorithm, ICDs, and associated CONOPS. The prototype algorithm will initially execute on the ground, but could eventually be migrated to a form factor consistent and compatible with the BMC3 architecture. The proposed solution shall cover the development of a PNT determination software application, platform data interface control documents and all processing and PNT related data distribution. SDA is planning to use Optical Inter-Satellite Links (OISL) to exchange high speed data and make ranging/timing measurements between all satellites in the constellation. In addition, the OISLs will be capable of connecting to optical ground terminals which can also provide range/timing estimates. SDA may use RF crosslinks as a backup if OISL technology is not available in time for Tranche 0. Either of these crosslink technologies are expected to produce high-quality one-way and two-way intersatellite range/timing measurements.

This Orbit and Clock Determination Application (OCDA) should process inputs from a variety of PNT sources such as GPS, INS, star trackers, clock, and, most critically, the satellite crosslink ranging and timing measurements. The algorithm should automatically de-weight information if unavailable or untrusted. Most importantly, the OCDA must be able to operate if GPS observations are no longer available or become untrusted. When GPS is denied or untrusted, space-to-ground measurements could provide the reference to UTC and the surveyed coordinates (WGS84) needed to keep the constellation tied to the Earth surface. This ODCA may end up being demonstrated in Tranche 0 by post-processing data using ground computing assets.

Ground simulations will be an important tool for demonstrating the performance and CONOPS of a completed Transport layer constellation. The SDA is also planning an interoperable Tracking layer constellation that will also provide crosslink range measurements and should be included in this simulation tool. From a PNT perspective, the Transport and Tracking constellations will likely operate under a unified PNT architecture.

CONOPS solutions should define how the processing tasks will be divided, the data requirements for the OCDA, and interface standards for communication between and within each platform. Additional CONOPS should propose solutions for data management of all the PNT source information needed to support the OCDA application. Each of the platform payload systems may consume OCDA data with different prediction intervals (minutes to days) depending on the payload’s needs. This data will also be made available to the ground for satellite constellation management and to support special analysis.

3. Technical Area 3 - Tracking

a) Tracking Mission

The Tracking Layer will provide global indications, warning, and tracking of advanced missile threats, including hypersonic missile systems. Two programs will collaborate in the tracking layer: a Wide Field of View (WFOV) program focusing on technologies necessary to populate a proliferated LEO constellation and a Medium Field of View (MFOV) program focusing on technologies necessary for additional performance. The WFOV satellites are planned to be fielded in late FY22, and the MFOV satellites are planned to be fielded in mid-FY23; both sets of satellites will provide complementary mission data to C2 and operational interfaces.

b) Tracking Architecture

The WFOV Tracking constellation consists of satellites provided by multiple vendors.

Each of the satellites is expected to have the capability to process its own sensor measurements.

The Tracking satellites will also contain a BMC3 module that is sized to support several key mission functions, including sensor data processing, data fusion from multiple satellites to create 3D tracks, and Tracking satellite tasking and scheduling.

The BMC3 module will demonstrate on-board processing and fusion of payload data.

Nominally this will include generation of tracks and exceedance handoffs between Tracking satellites and data fusion from choreographed operations. For later tranches, BMC3 is expected to provide additional capability, e.g. for enhanced onboard processing, networking, and autonomous constellation management. All Telemetry, Tracking and Command (TT&C), PNT, space vehicle crosslink and other payload data shall be made available to the BMC3 module.

c) Tracking Prototype Focus Areas

Tracking application developers should strive to incorporate mission-specific processing, algorithms, and applications to meet these objectives.

• Threshold: Object Sighting Messages (OSMs, aka tracklets per OPGA 79) generated on-board Tracking satellite and passed to the Missile Defense Agency (MDA) C2BMC (Command and Control, Battle Management and Communications) via the SDA Transport layer and back through the chain.

• Goal: Exceedances and OSMs (or more data) generated on-board Tracking satellites passed to BMC3 on Tracking or Transport, fused with data from other Tracking satellites for full 3D tracks, and passed directly to theater user terminal via the Transport Layer. Fusion of data from multiple sensors consists of combining processed or minimally processed data from the sensors to determine 3D geolocation of a target.

Algorithms should account for how a minimum or maximum number of sensors impacts the results and assess error bars on any given solution.

Proposed software solutions for on-orbit sensor scheduling and tasking should account for data quality when processing Tracking data from multiple satellites with varying levels of performance. For example, this may consist of identifying the Tracking satellites best suited for a specific mission based on look angle optimization together with solar-sensor geometry and signal-to-noise ratio. When global coverage is not available, the tasking application should determine and provide a predicted data quality assessment to the Tracking satellites to enable tasking for optimized coverage from the constellation for a given geographic area (e.g., CONUS). The tasking prototype should:

• Identify the satellites and sensors in a manner that balances efficiency and optimization and converts any required attitude to executable commands by the space vehicle on a timeline consistent with the necessary viewing.

• Allow for two days (48 hours) of optimization, planning, and re-planning as taskings and priorities may change.

• Rapidly reoptimize the constellation schedule, pointing, and collections and provide an assessment of the time needed for computation (goal 10 min) and execution (goal 30 min).

• Manage the data routing and associated prioritization from space vehicle generation, to multi-satellite fusion, to user.

Proposals should also address the extent to which their solution can interface with the Persistent GEOINT Mission Manager (PGMM) architecture used by other DOD and mission partner OPIR platforms.

Proposals should address the all-weather capabilities of the proposed solutions. All weather refers to the capability to sense to the ground under the most common weather and lighting conditions sufficiently to support military operations.

III. 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 one, multiple, or none of the proposals received in response to this solicitation and to make an award without discussions with a proposer. The Government also reserves the right to conduct discussions if it is later determined to be necessary. If warranted, portions of resulting award may be segregated into pre-priced options. Additionally, the Government reserves the right to accept proposals in their entirety or to select only portions of a proposal for award. In the event that the Government desires to award only portions of a proposal, negotiations may be opened with that proposer. The Government reserves the right to fund proposals in phases with options for continued work, as applicable.

Awards under this BAA will be made to a proposer on the basis of the evaluation criteria listed below (see § VI, “Application Review Information,”) 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 § VII.B.4, “Representations and Certifications”). The Government reserves the right to remove proposals from award consideration, should the parties fail to reach agreement on award terms, conditions, and/or cost/price within a reasonable time, or the proposer fails to provide requested additional information in a timely manner. 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. Any requests for or assumptions regarding Government Furnished Equipment (GFE) or Government Furnished Information (GFI) should be clearly stated in the proposal.

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

In all cases, the Government contracting officer shall have sole discretion to select award instrument type, regardless of instrument type proposed, and to negotiate all instrument terms and conditions with the selectee.

Any award resulting from this BAA will include a requirement for SDA permission before publishing any information related to the SDA-funded effort. The following, or similar, language will be incorporated into awards:

There shall be no dissemination or publication, except within and between the contractor and any subawardees, of information developed under this contract or contained in the reports to be furnished pursuant to this contract without prior written approval of SDA. All technical reports will be given proper review by the appropriate authority to determine which Distribution Statement is to be applied prior to the initial distribution of these reports by the Contractor.

When submitting material for written approval for open publication, the contractor/awardee must submit a request for public release to SDA and include the following information: (1) Document Information: document title, document author, short plain language description of technology discussed in the material (approx. 30 words), number of pages (or minutes of video) and document type (e.g., briefing, report, abstract, article or paper), event date, desired date for SDA’s approval; (2) SDA Program Manager/COR and contract number; and (3) Contractor/Awardee’s Information: POC name, email and phone. Allow four weeks for processing; due dates under four weeks require a justification. Unusual electronic file formats may require additional processing time. Requests may be sent either via email to osd.pentagon.ousd-r-e.mbx.hq085020s0002@mail.mil or by mail at Space Development Agency, 3030 Defense Pentagon, Washington, DC 20301-0001.

IV. ELIGIBILITY INFORMATION

A. Eligible Applicants

All responsible sources capable of satisfying the Government's needs may submit a proposal that shall be considered by SDA. Submissions including profane or racially charged language will not be reviewed.

1. Federally Funded Research and Development Centers (FFRDCs), University Affiliated Research Centers (UARCs), and Government Entities

a) FFRDCs and UARCs

FFRDCs and UARCs are subject to applicable direct competition limitations and cannot propose to this BAA in any capacity unless they meet the following conditions. (1) FFRDCs/UARCs must clearly demonstrate that the proposed work is not otherwise available from the private sector. (2) FFRDCs/UARCs 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 FFRDCs/UARCs compliance with the associated FFRDC/UARC sponsor agreement’s terms and conditions. These conditions are a requirement for FFRDCs/UARCs proposing to be awardees or subawardees.

All proposers are expected to address transition; transition is part of the evaluation criteria in § VI.A. However, given their special status, FFRDCs should describe how and when a proposed technology/system will transition and identify to which Non-FFRDC organization(s).

b) Government Entities

Government Entities (e.g., Government/National laboratories, military educational institutions, etc.) are subject to applicable direct competition limitations. Government Entities must clearly demonstrate that the work is not otherwise available from the private sector and provide written documentation citing the specific statutory authority and contractual authority, if relevant, establishing their ability to propose to Government solicitations 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, SDA 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. SDA 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. Non-U.S. Organizations and/or Individuals

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.

3. Classified Proposals

If a submission contains Classified National Security Information or the suspicion of such, as defined by Executive Order 13526, applicants will ensure all industrial, personnel, and information systems processing security requirements are in place and at the appropriate level (e.g., Facility Clearance Level (FCL), Automated Information Security (AIS), Certification and Accreditation (C&A), and any Foreign Ownership Control and Influence (FOCI) issues are mitigated prior to submission. Additional information on these subjects can be found at http://www.dcsa.mil.

B. Organizational Conflicts of Interest

FAR 9.5 Requirements

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

FAR 9.505-4.

Agency Supplemental OCI Policy

In addition, SDA has a supplemental OCI policy that prohibits contractors/performers from concurrently providing Scientific Engineering Technical Assistance (SETA), Systems Engineering and Integration (SE&I), 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, SE&I, A&AS, or similar support to SDA 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, SE&I, A&AS, or similar support is being or was provided to SDA, the proposal must include:

• The prime contract number;

• Identification of proposed team member (subawardee, consultant) providing the support;

and

• An OCI mitigation plan in accordance with FAR 9.5.

Government Procedures

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

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 SDA 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:

https://www.dau.edu/guidebooks/Shared%20Documents/Other%20Transactions%20(OT)%20G uide.pdf

V. APPLICATION AND SUBMISSION INFORMATION

A. Application Assistance

All administrative correspondence and questions on this solicitation, including requests for information on how to submit an executive summary or full proposal to this BAA, should be directed to osd.pentagon.ousd-r-e.mbx.hq085020s0002@mail.mil.

B. Content and Form of Submission

Proposers are strongly encouraged to submit an executive summary in advance of a full proposal. This procedure is intended to minimize unnecessary effort and cost in proposal preparation and review. The period of performance for all proposed efforts should end no later than 30 September, 2021.

All submissions must be written in English with type not smaller than 12-point font. A page is defined as being no larger than an electronically formatted page of 8.5” by 11.0” with type not smaller than 12 point. Smaller font may be used for figures, tables, and charts. Copies of all documents submitted must be clearly labeled with the SDA BAA number, proposer organization, SDA focus area(s) as described in § II.D, and proposal title/proposal short title.

For a proposal that includes both classified and unclassified information, the proposal may be separated into an unclassified portion and a classified portion. The proposal should use the unclassified portion to the maximum extent reasonable. Submissions should be made according to the instructions outlined in § V.C.

NOTE: Non-conforming submissions that do not follow the instructions herein may be rejected without further review.

1. Executive Summary (ES) Format https://www.dau.edu/guidebooks/Shared%20Documents/Other%20Transactions%20(OT)%20Guide.pdf https://www.dau.edu/guidebooks/Shared%20Documents/Other%20Transactions%20(OT)%20Guide.pdf

Proposers are strongly encouraged to submit an executive summary in advance of a proposal. Proposers should specifically and clearly address the innovation of their proposed system or subsystem component development, the scientific or technical basis for innovative claims, and the impact of the proposed development on military mission capabilities, efficiency, or effectiveness. SDA policy is to treat all submissions as source selection information (see FAR

2.101 and 3.104), and to disclose their contents only for the purpose of evaluation. The executive summary should be clearly marked “EXECUTIVE SUMMARY,” and the total length shall not exceed two [2] pages. All executive summary submissions must be written in narrative form. No formal transmittal letter is required, but submissions must include the organization name, submission title, SDA focus area(s) as described in § II.D, and technical POC information (e-mail and mailing address).

2. Full Proposal (FP) Format

All proposals must be in the format given below. Non-conforming proposals may be rejected without review. The typical proposal should express a consolidated effort in support of one or more related technical concepts or ideas. Disjointed efforts should not be included into a single proposal. Proposals shall consist of two volumes: 1) Volume I, Technical and Management Proposal (composed of three parts), and 2) Volume II, Cost Proposal. The maximum page limit for Volume I is 15 pages (30 pages if the proposal total value exceeds $1 million). Bracketed numbers by each section denote page limits. The page limitation for full proposals includes all figures, tables, and charts.

Ensure that each section provides the detailed discussion of the proposed work necessary to enable an in-depth review of the specific technical and managerial issues. Specific attention must be given to addressing both risk and payoff of the proposed work that make it desirable to

SDA.

Volume I, Technical and Management Proposal, described below, must include an attached bibliography of relevant published technical papers or research notes which document the verification, testing, and real-world use of critical technologies, technical ideas and approaches upon which the proposal is based. Only one (1) citation reflecting the most technically mature state of each critical technology, technical idea, or approach is requested.

Published technical papers or research notes contained in the bibliography that are not publicly available must be included with the submission (no page limit). “Publicly available” is defined as openly available to the public without the need for professional society memberships (paid or unpaid), logins, or special access of any kind. Copies of not more than three (3) relevant papers not related to proposed critical technologies may be included with the submission. The bibliography and attached papers are not included in the page limits. The submission of additional supporting materials along with the proposals not requested in this BAA is strongly discouraged and will not be considered for review.

Volume 1, Technical and Management Proposal

Section I: Administrative

(a) Cover Sheet to include {no page limit}:

(1) BAA number (HQ085020S0002)

(2) Technical area;

(3) Lead organization submitting proposal;

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

BUSINESS,” “SMALL DISADVANTAGED BUSINESS,” “OTHER SMALL

BUSINESS,” “HBCU,” “MI,” “OTHER EDUCATIONAL,” OR “OTHER

NONPROFIT”;

(5) Proposer’s 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, telephone, electronic mail;

(9) Administrative point of contact to include: salutation, last name, first name, street address, city, state, zip code, telephone, electronic mail;

(10) Total funds requested from SDA, including total base cost, estimates of base cost in each year of the effort, estimates of itemized options in each year of the effort, and the amount of cost share (if any);

(11) Award instrument requested: cost-plus-fixed-fee (CPFF), cost-contract – no fee, cost sharing contract – no fee, or other type of procurement contract (specify), or other transaction;

(12) Place(s) and period(s) of performance;

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

(14) Name, address, and telephone number of the proposer’s cognizant Defense Contract Management Agency (DCMA) administration office (if known);

(15) Name, address, and telephone number of the proposer’s cognizant Defense Contract Audit Agency (DCAA) audit office (if known);

(16) DUNS number;

(17) TIN number;

(18) Cage code (lead organization);

(19) Proposal validity period (minimum 180 days);

(20) Affirmation of existing SETA support contracts (see § IV.B). If none, state

“none”;

(21) Statement of Unique Capability Provided by Government or Government- Funded

Team Member {no page limit};

(22) Per § IV.A – Eligible Applicants, proposals that include Government or

Government-funded entities (i.e., FFRDC’s, UARCs, National laboratories, etc.)

as prime, subcontractor or team member, shall provide a statement that clearly demonstrates the work being provided by the Government or Government- funded entity team member is not otherwise available from the private sector. If none of the team members belongs to a Government or Government-funded entity, then the proposer should state “Not Applicable.”

(23) Date proposal was submitted.

(b) Official transmittal letter {1}

(c) Table of Contents {no page limit}

Section II: Summary of Proposal {4}

Note: The Summary of Proposal should not have any unique information not contained in the Detailed Proposal Information.

(a) Innovation: Succinctly describe the uniqueness and benefits of the proposed research relative to the existing body of research and industry work. Provide a basic description of the scientific or technical basis for the innovative claims.

(b) Results: Provide a short description of the deliverables associated with the proposed research – discuss the results, products, transferable technology, and transition path.

(1) Include in this section all proprietary claims to the results, prototypes, intellectual property, or systems supporting 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…