Attachment_1_-_FORGE_MDP_Request_for_Information.pdf

SPACE AND MISSILE SYSTEMS CENTER

(SMC) REMOTE SENSING SYSTEMS

DIRECTORATE (RS)

REQUEST FOR INFORMATION AND ONE-ON-ONE NOTICE

1. Purpose – The Remote Sensing Systems Directorate is responsible for the delivery of the Space Based Infrared System (SBIRS) and Weather Systems. SBIRS is an Overhead Persistent Infrared (OPIR) system that addresses Department of Defense (DoD) requirements for Missile Warning (containing Strategic Missile Warning (SMW) and Theater Missile Warning (TMW)), Missile Defense (MD), Battlespace Awareness (BA), Technical Intelligence (TI) and Civil/Environmental (C/E) monitoring mission areas. The United States Air Force (USAF) needs to process all of the data acquired from the growing DoD and Intelligence Community (IC) OPIR constellations. The USAF seeks to modernize the existing Mission Data Processing (MDP) architectural solution (i.e. create an updated integrated infrastructure and mission processing set of capabilities) to meet the current diverse mission area requirements and be easily expanded to process and exploit data from future sensors.

Space is becoming a warfighting domain. HQ AFSPC is continuing to develop the Space Enterprise Vision (SEV) to address this change to include fielding a resilient enterprise ground architecture. At the heart of this ground enterprise is an integrated framework of ground mission services that provide flexible, data-centric, and automation driven capabilities to enable enhanced satellite operations, mission management, mission data processing, ground control, transport, dissemination, BMC2 and defensive cyberspace operations functions. Data and mission products will be available to external users and systems at multiple security levels.

The purpose of this Request for Information (RFI) is to obtain potential approaches and interest from industry which support SEV and meet the following objectives:

create a Government owned MDP solution (shared with other OPIR processing centers) develop a modular, scalable, flexible, extensible, and “open” MDP system meet current mission requirements (as listed above), providing non-degradation from existing SBIRS 1996 ORD Key Performance Parameters (KPPs) and extend to new KPPs as applicable in the SBIRS Follow-On draft Capabilities Development Document (dCDD) support OPIR evolving mission/user needs for civil, environmental, DoD, and weather products– extend to support processing data from other sources provide technical baseline and appropriate documentation (i.e., Interface Control Documents (ICD), system documentation (e.g. Software Development Kit (SDK), Application Programming Interfaces (APIs), data models, Software User’s Manual (SUM), System Administrator’s Guide (SAG)) which will enable utilization of any (Government selected) 3rd party application provider to create, evolve or replace system capabilities install this solution to the appropriate user and test locations (e.g. Mission Control Station (MCS), MCS-Backup (MCS-B), OPIR Battlespace Awareness Center (OBAC), Tools, Applications, and Processing (TAP) Lab) allow industry to periodically compete to provide MDP capabilities (i.e., integrator, mission application providers, and infrastructure provider)

USAF requests information from any interested contractor on how it would architect, design, build, deliver, and integrate an extensible system infrastructure and/or mission processing capabilities that address the aforementioned objectives. The USAF seeks to create this new ground mission processing architecture incorporating existing technologies, requirements, development approaches, and capable of meeting the evolving future requirements. Future Operationally Resilient Ground Evolution (FORGE) is the ground modernization effort that will accomplish this objective, and is envisioned to be a full and open competition. In support of this architecture, the Government is encouraging industry to propose an innovative FORGE MDP approach meeting current requirements, is extensible to support future requirements, and is sustainable. Industry can provide approaches for any/all of the following:

create an open architectural solution using 3rd party developed applications develop MDP applications supporting mission areas listed above integrate MDP applications onto the open architectural solution

2. Background – SMC is evolving the DoD’s OPIR data processing using two Open Framework Architectures (OFAs): the System Framework and the Mission Framework. SMC / Advanced Systems and Development Directorate (AD) is leading all System Framework efforts and SMC/Remote Sensing Systems Directorate Future Ground and Exploitation Division (RSX) is leading all Mission Framework efforts. The functions inside of the blue dotted line of Figure 1 illustrates the focus of this RFI. All other areas are only added for completeness and are not part of this RFI.

Figure 1: FORGE Prototype Architecture

Utilizing OFAs will enable SMC to: add payloads/spacecraft more efficiently; quickly and cost effectively integrate new capabilities; and ensure continuity of operations to support evolving warfighter needs. FORGE is acquiring these OFA approaches through two major efforts:

System Framework – the Enterprise Ground Services (EGS) is being led by

SMC/AD and is not part of this RFI Mission Framework – the FORGE MDP effort is being led by SMC/RSX and is the focus of this RFI. This effort is envisioned to create the mission Open Architecture (OA), create the MDP applications that support the specified mission areas, and integrate those applications onto that OA.

3. FORGE MDP Key Functional Areas – FORGE MDP has three focus areas: MDP Applications, MDP Infrastructure, and Integration, Verification, and Testing (IV&T).

3.1. MDP Applications

The Government believes that in order to develop applications that modernize and modularize SBIRS ground processing, such that the DoD OPIR data can be characterized into actionable information for current and future OPIR stakeholders, processing configurations must be created. Individual configurations will need to meet the MW, MD, BA, TI, and C/E mission area requirements and will be developed using individual mission processing applications that fall into one of three categories:

core – capabilities that each mission area must perform (e.g. external data ingestion, point source generation, and data conditioning) tailorable – capabilities that might be slightly different (i.e., tailored using configuration files or software build directives) from mission area to mission area (e.g. background management, wideband/globe displays, and data area management) unique – capabilities that are unique to a specific processing string within a mission area (e.g. specific mission trackers, and external message creation)

It is expected that unique applications will only be developed for specialized processing and, as such, their creation will be limited. MDP should not consist of multiple versions of the same capability that have simply been ported to a different operating system or just slightly “updated” to meet a new need. Figure 2 contains notional processing configurations consisting of core, tailorable, and unique software applications where each configuration is designed to meet the requirements of the specific mission area.

Each processing configuration will:

contain a series of plugins to meet a set of mission requirements maximize the use of mission core/tailorable plugins minimize the use of unique plugins as much as possible run plugins in both serial and parallel processing modes utilize the set of plugins to process the data into actionable information

It is anticipated that multiple processing configurations will be required to meet the complete set of existing system requirements and the mission processing demands of a rapidly changing world. Each string of processing will be in support of specific needs/requirements that may be based on mission area, region of interest, and mission criticality. In addition, some mission processing configurations will be more rigid as they must go through operational evaluation/certification. Other mission processing configurations may be dynamically configured based on the current needs. The approach of creating multiple processing configurations that meet different user requirements should minimize system impacts due to application flux.

Figure 2: Notional Mission Processing Configurations

In support of each mission area, sets of requirements must be met. However, there are core capabilities that each processing configuration must complete. Those core capabilities are expected to minimize the need to continuously modify existing capabilities to meet the needs of the evolving DOD OPIR constellation and world operational picture. To execute this approach the Government foresees defining a minimum set of interface definitions: e.g. raw data, raw calibrated data, exceedances, clusters, rep returns, tracks, events, and event messages. These interface definitions will allow the Government to leverage the expertise of potential MDP application providers.

Notional MDP application capabilities that are envisioned include, but are not limited to:

data ingestion and conditioning rep return generation data archiving and playback exceedance generation background management line-of-sight correction data filtering wideband/scene and rep return event tracking for all mission areas data fusion and event parameter estimation wideband and globe display message formatting data dissemination

The initial modular system must meet the strict ITW/AA requirements and existing SBIRS KPPs from the SBIRS 1996 ORD. SMC/RSX expects that the initial set of applications may be more complex than ultimately desired. However, SMC/RSX anticipates that the complex applications will be systematically refactored into smaller, less complex, more discrete applications over future evolutions. As the applications are refactored, the features available using MDP infrastructure (e.g., containerization and dynamic scaling) can be exploited. MDP processing configurations should maximize the capabilities developed under the MDP infrastructure development effort, support all levels of mission evaluation/certification, and support each mission area. It is also expected that multiple levels of training and continued customer support will be required to ensure that developers with varying degrees of MDP knowledge can deliver capabilities that will support the range of mission areas while ensuring AFSPC operators embrace the human-system interface.

The Government anticipates that all capabilities will be vetted through the TAP Lab.

The TAP Lab is one of the locations where technology maturation will occur and one of the TAP Lab’s missions is to continually enhance DOD OPIR performance. The Government foresees the following having to occur:

incremental delivery dates of capability will be identified applications will be Government owned or licensed system applications will perform (at least) all current SBIRS capabilities

3.2. MDP Infrastructure

The Government envisions that the MDP infrastructure capabilities will be similar to capabilities developed by commercial Application Service Providers (ASPs) and Cloud Providers (CPs). However, the infrastructure must support the higher DoD OPIR data rates (reference Appendix C) characteristic of remote sensing mission data and provide an infrastructure which will support MW, MD, BA, TI, and C/E mission areas requirements. Key capabilities should include functions such as:

ensuring that the solutions fit within the overall system security posture providing global infrastructure capabilities meeting computation processing requirements supporting MDP storage requirements ensuring the infrastructure can meet the database requirements providing application services (e.g., data pedigree, system monitoring, and processing configuration) providing system deployment & application management/chaining capabilities supporting integration with existing infrastructures supporting large throughput data rates abstracting capabilities away from specific vendor implementations providing capabilities that easily migrate to using future technologies providing MDP support applications supporting both single tenancy (i.e., sandbox) and multi-tenancy (i.e., integration/pre-ops/ops instances) architectures providing common look and operability across all MDP strings to simplify

AFSPC operators’ training and use of the architecture

As part of the overall development, a set of software development products (e.g. an SDK, a set of APIs, a SUM, and a SAG) must be developed, evolved, validated, and delivered.

It is also expected that varying levels of training and continued customer support will be required to ensure that developers with varying degrees of MDP knowledge can deliver capabilities.

The infrastructure must support all levels of mission processing certification requirements: from the R&D TAP Lab environment to the uncertified and certified reporting environments. In addition, the infrastructure must support all processing timelines:

Offline Near-Real-Time Real-Time (non-mission critical) Real-Time (mission critical)

The final infrastructure solution should maximize the use of proven software technologies and leverage Commercial Off-The-Shelf (COTS) / Government Off-The- Shelf (GOTS) / Free or Open Source Software (FOSS) to the fullest, while ensuring that the solutions fit within the overall system security posture. To sum up, infrastructure must meet the MDP mission area needs using the appropriate set of selected mission applications, interface with EGS and help ensure that the IV&T task is successful.

3.3. IV&T

IV&T will be responsible for integrating and deploying a validated system which will include the following functions:

integrating the mission applications with the infrastructure verifying the functionalities performing all aspects of test (e.g. design-for-test, automate system level test strategies, performance testing, and requirements sell-off) deploying the systems

The Government realizes that the integration effort will be extensive and may accept a complete solution from a single Integrator. The integrated solution must provide a diverse team with domain knowledge in MDP applications, infrastructure and IV&T.

The integrated solution should help reduce the IV&T’s exposure to unknown mission area risks as IV&T is a crucial MDP infrastructure/application stakeholder and must have complete visibility into the MDP application (e.g., dependencies, requirements, and performance). Reference Section 5 for overall Transition approach. It is also expected that varying levels of training and continued customer support will be required to ensure that developers with varying degrees of MDP knowledge can deliver capabilities.

The Government anticipates that integrated system capabilities will meet all system requirements and foresees the following having to occur:

incremental delivery dates of capability will be identified system applications will perform (at least) all current AFSPC OPIR capabilities

4. MDP Overall Architecture – Figure 3 depicts the expected overall SBIRS MDP architecture which illustrates Block 20 Relay Ground Stations (RGS) capabilities will remain untouched. To ensure success, the Government also expects to maximize the re-use of key SBIRS infrastructure elements (e.g. SBIRS backbone, ICDs, requirements, and applications).

Figure 3: FORGE MDP Architecture

In order to achieve the targeted FORGE MDP architecture, current AFSPC OPIR capabilities must be migrated without impacting weapon system operators or data/information recipients.

To accomplish this, the Government expects to leverage investments spent on existing programs and tools.

5. FORGE Transition Plan – FORGE integration must bridge the gap between technology maturation and operational use. As previously stated, EGS is modernizing SBIRS C2 and this announcement only focuses on AFSPC OPIR MDP. However, much of the required transition effort described herein applies to both the AFSPC OPIR MDP and AFSPC

OPIR C2.

5.1. For AFSPC OPIR MDP, technology maturation will occur in the TAP Lab and one of the TAP Lab’s missions will be to continually enhance DOD OPIR performance.

The TAP Lab will be the place to experiment with changes to the OFA-based Remote Sensing Ground segment. Those changes can be for all aspects of the architecture: e.g., framework “bus”, APIs, applications that will run on the framework. Overall capabilities will be developed using a phased approach which will include risk mitigation and demonstrations at each phase. To begin the phased approach the Government plans to start with an initial prototyping phase. The Government expects to fund bidder(s) to develop prototype capabilities and use those prototypes as a key criterion when determining final contract awards.

Once the development is under way, lessons learned from previous phases will be applied to the next phase. The TAP Lab will support this approach utilizing three environments:

The “sandbox” environment is for proving that individual enhancements work in the manner that developers expected or claimed.

The “integration” environment ensures all applications/features that worked in a

“sandbox” environment will work when integrated with other/existing/proven capabilities and the new features do not degrade existing capabilities.

The “ops-like” environment is as close as possible to the operational hardware and software. (With new generations of hardware evolving every 18 months or so and with the evolution of supporting COTS, absolute matching to the operational environment may not always be possible.)

Integration will take the lab products (including all of the underlying supporting elements) and operationalize them within operational facilities. That operationalized total product is then turned over to the depot/sustainment team to support the operational user.

The Government anticipates that the transition to open framework will start with the “modularization” of legacy mission data processing in order to build confidence among operators and provide a performance baseline for developers.

At least a partial list of governance rules for the integration process will include:

Establishment, control, and maintenance of baselines

The integrator will need at least two environments (e.g., test and operational) and those environments will pass to depot/sustainment at the end of the integration process. This will include version control, COTS/GOTS/FOSS versions and licenses.

Developmental and ops acceptance testing This element will include automated testing routines and models and simulations.

The integrator must coordinate the testing program among all stakeholders and provide the documentation (e.g., plans, procedures, and scripts).

Manage facilities from a technical support standpoint This element identifies and mitigates any impacts on space, power, and cooling for the new hardware and communications/network provisions. It includes addressing security / cyber defense issues and coordinating all this with the sustainment organization.

Provide facilities integration support This element transitions the capabilities to an OFA without impacting legacy operations. This will include design and buildout and will include space for realistic testing as well as interim ops.

Identify and implement training that is impacted by the new architecture Deployment will likely involve creating additional training space for operators to avoid impacts to legacy operations. Training must also be provided for the maintenance support crews and depot personnel.

Assist in personnel planning The final element involves continuing legacy ops while training crews for the new capability and will likely require the operating command to “overman” for some period of time. The integrator must identify how many, what skillset, when, and for how long. Working with the depot/sustainment organizations, cross training for maintenance personnel must be planned and executed.

5.2. Reference OPIR constellations are:

a) SBIRS SMW mission: at least 8 satellites in Geosynchronous Equatorial Orbit GEO (both Scanner and Starer) and 4 sensors in Highly Elliptical Orbit (HEO) for a total of 20 sensors.

b) All other missions: SMW constellation plus all available non-SMW SBIRS GEO, SBIRS HEO, Defense Support Program (DSP), Wide Field of View (WFoV), and tracklets from all Space Tracking and Surveillance System (STSS) and IC OPIR sensors.

Notes:

i. Reference constellations are for information only; actual constellations are classified

ii. MDP infrastructure and application solutions must easily scale to support the growing constellation.

5.3. Reference mission system parameters are:

a) SMW operational requirements are assumed to be based upon the SBIRS Operational Requirements Document (ORD) (dated 15 Aug 1996), Operational Requirements Document for SBIRS (dated 14 Jan 2002), and SBIRS Follow-on Draft Capabilities Development Document (approved Feb 2017)

b) BA operational change to capabilities are assumed to be based upon the OPIR Battlespace Awareness Center (OBAC) Annex SBIRS System Concept (dated November 2016)

6. Response Content – Interested vendors must submit a response to Section 6.1 and may choose to submit responses to Section 6.2. This RFI will directly support and inform the DOD OPIR MDP infrastructure and application market research and acquisition planning.

6.1. Corporate Capabilities and Expertise – All interested parties who believe they have the capability to produce and/or support a solution that meets the USAF needs in this RFI shall submit a Statement of Capability (SOC) in accordance with administrative requirements in Section 8. The SOC must include the following:

a) Company name

b) Your company’s ownership and other relevant information

c) Personnel/Business size classification (Small/Large Business, HUB, and veteran)

d) Mailing address

e) Point of Contact (POC) and telephone numbers

f) Experience: specific work previously performed or work performed which is relevant to this effort. Corporate expertise should focus on any or all of (1) infrastructure, (2) MDP application development, and (3) MDP system integration and test to the greatest extent possible. Please also provide information related to:

1. Company history with OPIR programs (if applicable)

2. Your company’s relevant products and services

3. Effort to be subcontracted and the subcontractor's capabilities

4. Any work performed by small businesses

In addition to the SOC, respondents are required to fill out the Appendix A (Market Research Questionnaire) for each white paper submitted to Section 6.2.

6.2. Mission Data Processing Approach and Technical Solution – Please submit a white paper in accordance with the administrative requirements in Section 8. The white paper should detail your company’s ability to offer the Government your best solution to design, produce, and complete any/all of the following:

create an open architectural solution that will utilize 3rd party developed applications develop MDP applications that support the MW, MD, BA, TI, and C/E mission areas integrate MDP applications onto the open architectural solution

The USAF is particularly interested in the following:

What MDP focus areas (i.e. OA solution, applications, or IV&T) is your company interested in pursuing?

Is the Government missing any other key MDP focus areas?

How can your applications and/or infrastructure be easily extended to meet the growing OPIR system capabilities?

How is your company’s approach to providing the OA infrastructure a truly open approach?

How will your OA infrastructure approach not preclude other companies from providing the best of breed applications?

What is your approach to ensure that the mission processing ITW/AA and TES certifications are successful?

Are there any shortcomings with respect to the objectives listed in Section 1.0?

What (if any) aspects of your company’s proposed design and implementation would be construed as proprietary?

Should the Government purchase all applications or consider licensing applications?

What additional interface definitions besides those listed in Section 3.1 should the

Government consider pre-defining?

What methodologies should the Government choose that will ensure effective and efficient deployment, provisioning and integration of infrastructure and application components?

What else should the Government be thinking about when seeking a modernized MDP architectural solution?

The response should:

a) Discuss your company’s part of the solution which can support meeting the SBIRS 1996 ORD and (OBAC) Annex SBIRS System Concept described capabilities

b) Discuss how your company addresses the following technical challenges:

1. addresses the areas of interest listed above

2. is extensible to handle data rates of the constellation specified in 5.2

3. provides a solution that is extensible to meet both the evolving constellation and the changing operational requirements

c) Discuss the MDP area of expertise and proposed technologies that will be utilized

d) Discuss technical risk associated with the solution and estimated delivery times

e) Describe corporate experience to create, integrate and test the technical solution

f) Discuss any cost drivers, cost tradeoffs, and schedule considerations

g) Include a high level schedule with the following assumptions:

1. ATP to Initial Capability with a medium risk profile; for purposes of this RFI assume an ATP of Mid 2019

2. Include key GFE items

h) Follow the submission instructions in section 8.3.

Notes:

i. Respondents may include additional information not explicitly identified within this section, if necessary, as long as it does not exceed the page limit.

7. One-On-One Sessions– SMC/RS will host UNCLASSIFIED FORGE MDP One-On- One sessions at Los Angeles Air Force Base ~15 days after RFI responses have been received.

SMC/ RS Exploitation Division, Future Ground Integration Branch (RSXI) will send information packages to the company primary Point of Contact (POC) upon valid One-On- One Session registration. The information package will include details on the FORGE MDP One-On-One session as well as area access and parking information.

7.1. One-On-One Day Background - The FORGE MDP One-On-One session will briefly outline the objectives of (1) infrastructure, (2) MDP application development, and

(3) MDP system integration and test. SMC/RS will provide an overview of FORGE MDP strategy, questions and/or comments resulting from the RFI submittals. The session may either be UNCLASSIFIED or SECRET. Advance questions may be submitted in writing to SMC/RSXI as identified in Section 10.

7.2. One-On-One Registration Instructions– Registration must be submitted NO LATER THAN, 10 business days after announcement of One-on-one sessions. To register, complete Appendix B and submit it via e-mail to the Primary POC identified in Section 10. Interested attendees must also submit a visit request via JPAS to SMC/RS (SMO Code: RSSD) for a classified session. The total number of attendees each company may bring to the FORGE MDP One-On-One session is limited to five (5) representatives.

7.3. Small Business Consideration – The NAICS code for this project is 541715 “Research and Development in the Physical, Engineering, and Life Sciences (except Biotechnology)”. The Small Business size standard is 1,250 employees. Participation from small and small disadvantaged businesses is highly encouraged. SMC’s Small Business points of contact are Mr. Willard Strozier and Ms. Audrey Campbell. They can be reached at smallbus@us.af.mil.

8. Response and Submittal Instruction

8.1. Response Classification – All material provided in response to this notice shall be UNCLASSIFIED, non-confidential, and non-proprietary to the maximum extent practicable. Firms providing confidential/proprietary information shall separately and clearly identify and mark all confidential/proprietary information. The USAF will take all necessary steps to protect/safeguard any confidential/proprietary information provided. The USAF will NOT be held responsible for any proprietary information not clearly marked.

8.2. Response Format – Responses may be provided in Microsoft Word, Microsoft Project, and/or PDF formats. Responses are not to exceed a total of twenty five (25) pages:

five (5) pages for each area of interest (i.e., architectural/infrastructure solution, MDP applications, and integrator) five (5) pages for questions that the USAF expressed a particular interest in five (5) pages for areas of vendor interest

Responses to the Market Research Questionnaire do not count against the page limits.

The USAF will not consider information in excess of those page restrictions. Margins shall be 1” on all pages; Times New Roman; text font size shall not be smaller than 11 point; font size within graphics and tables shall not be smaller than 8 point. Front matter such as transmittal letter, cover page, and table of contents will not count against the page limit. The USAF will not accept company literature or marketing materials in response to this RFI.

8.3. Submission Instructions – Submit an electronic copy of a white paper. All responses shall be sent to the POCs identified in Section 10 prior to the due date.

Hard copy responses will not be accepted.

8.4. Response Due Date – Responses to this RFI are due NO LATER THAN 1700 PT on Monday, 15 May 2017. Respondents should indicate if they would like to schedule a one hour one-on-one meeting to present their inputs. These sessions will be available at the UNCLASSIFIED and SECRET levels.

9. Reference Data – The Government is willing to provide the following reference documents listed below upon request.

Respondents are asked to contact the Primary POC named in Section 10 for transmission of the document(s).

REFERENCE DOCUMENTS:

1996 SBIRS Operational Requirements Document (ORD), SECRET AFROCM 05-13-07, SBIRS ORD Update, 16 May 2013, SECRET Initial Capabilities Document (ICD) For the Overhead Persistent Infrared (OPIR)

Enterprise, November 2010, SECRET Enterprise Systems Engineering Plan (ESEP), June 2015, UNCLASSIFIED SBIRS High Component Technical Requirements Document (TRD), April 1996, SECRET

Project West Wing Threat Matrix, 2016, SECRET/NOFORN SBIRS Specifications:

o High Component System Specification for SBIRS (SR0000), SECRET/RESTRICTED/US-ONLY o Interface Control Document (ICD) SBIRS to Air Force Satellite Control Network (AFSCN)(SS0006) – 12 December 2013, UNCLASSIFIED o SBIRS Space to SBIRS Ground ICD (SI1005), 9 September 2015, UNCLASSIFIED o SBIRS to Backbone Communication ICD (SS0014), UNCLASSIFIED AFSPC Security Classification and De-Classification Guide, including Annexes A & T, 22 April 2016 National System for Geospatial Intelligence (NSG) Security Classification Guide for

Overhead Persistent Infrared (OPIR), 28 Dec 2010, SECRET Overhead Persistent Geospatial-Intelligence (GEOINT) Architecture (OPGA) Data

Description Document (DDD), Rev C, 11 Sep 2015 - and updates, SECRET Battlespace Awareness Messaging Cell (BAMC) Concept of Operations (CONOPS), Nov 2014 – and updates, SECRET OPIR Battlespace Awareness Center (OBAC) Annex SBIRS System Concept, November 2016 – SECRET OPIR Real-Time Transfer Service Interface Control Document (O-RTS ICD), Rev C, 16 Apr 2015 - and updates, SECRET USSTRATCOM Strategic Instruction 534-21, Configuration Management for the

Theater Event System (TES), SECRET Integrated Broadcast Service (IBS) Common Message Format (CMF) Standard, 30 Jun

2014, SECRET

SBIRS Follow-On Draft Capabilities Development Document (dCDD), 3 Feb 2017, approval by HQ USAF/CC

10. Communications & Questions – All communications & questions associated with this RFI shall be submitted in writing to all POCs listed below. All Unclassified/Non- PROPRIETARY question and answers will be published to the Federal Business Opportunities website on a non-attributional basis.

Points of Contact

Primary POC:

Major Louis Aldini Deputy Chief, Future Ground Integration Branch, 310-653-3344 Unclassified e-mail: SMC.RSX.FORGEMDPContract@us.af.mil

Alternate POC:

Captain Adam Golden Program Manager MDP, Future Ground Integration Branch, 310-653-2433 Unclassified e-mail: SMC.RSX.FORGEMDPContract@us.af.mil

Contracting POC:

Ms. Doreen Grosvirt-Dramen Contracting Officer, 310-653-3295 Unclassified e-mail: doreen.grosvirt-dramen@us.af.mil

11. Disclaimers and Notes – THIS IS A REQUEST FOR INFORMATION ONLY. This RFI is issued solely for information and planning purposes. It does not constitute a solicitation (Request for Proposal or Request for Quotations) or a promise to issue a solicitation in the future. This RFI does not commit the USAF to contract for any supply or service whatsoever. Furthermore, the USAF is not, at this time, seeking proposals. Responders are advised that the USAF will not pay for any information or administrative costs incurred in response to this RFI. The Government will not assume liability for costs incurred by any attendee for travel expenses or marketing efforts. All costs associated with responding to this RFI will be solely at the responding party's expense.

All information received in response to this RFI that is marked PROPRIETARY will be handled accordingly. The USAF shall not be liable for or suffer any consequential damages for any proprietary information not properly identified. Proprietary information will be safeguarded in accordance with the applicable USAF regulations.

The following companies/organizations may review the submitted white papers and may be in attendance at the One-On-One session: The Aerospace Corporation, Integrity Applications Incorporated, The MITRE Corporation, SAIC Corporation, and TASC an Engility Company --all are bound by appropriate non-disclosure agreements with the USAF. For further information regarding these agreements, contact the Contracting Officer identified above.

APPENDIX A

Market Research Questionnaire:

1. Which efforts would your company be interested to fulfill?

2. Considering each effort that your company would be interested in, what percentage of the work would likely be performed using in-house capabilities?

3. Considering each effort that your company would be interested in, what percentage of the work might be subcontracted/teamed with large business?

4. Considering the work to be subcontracted/teamed, what percentage of the work might be subcontracted/teamed with small business?

5. What contracting strategy do you recommend to accomplish this scope of work? (e.g. fixed priced, IDIQ contracts, etc). Describe your experience with that type of contract offering.

6. Are you aware of any potential OCI issues and what is your mitigation strategy?

APPENDIX B

FORGE MDP One-On-One Registration

All companies interested in attending a FORGE MDP One-On-One Session must complete and submit this form to SMC.RSX.FORGEMDPContract@us.af.mil.

COMPANY NAME:

PRIMARY POINT OF CONTACT (LAST, FIRST):

CONTACT PHONE NUMBER:

CONTACT E-MAIL ADDRESS:

CONTACT MAILING ADDRESS:

Does your company anticipate submitting a response to a corresponding Request For Information (RFI) concerning your ability to provide solutions to meet USAF’s need to acquire a Mission Data Processing (MDP) architectural solution that can easily be expanded to handle the growing constellations and can easily be tailored to meet the diverse mission areas?

YES NO

Space and Missile Systems Center, Los Angeles Air Force Base Entry Access List

Maximum of 5 individuals per company will be allowed to attend FORGE MDP One-On-One Session (UNCLASSIFIED or SECRET). Individuals attending One-On-One Sessions must provide the information below. All fields below are MANDATORY. The below information will be used to clear each member through the Los Angeles Air Force Base, Visitor Control Center. NOTE: Individuals interested in attending unclassified session must also submit a visit request via JPAS to SMC/RS (SMO Code: RSSD).

For Each Individual

FORGE MDP One-On-One Session (UNCLASSIFIED): YES/NO

FULL NAME (LAST, FIRST, MIDDLE):

DATE OF BIRTH (MM/DD/YYYY):

CITIZENSHIP:

DRIVER’S LICENSE STATE:

DRIVER’S LICENSE NUMBER:

APPENDIX C

SBIRS Sensors Data Rate Overview

Table 1 RGS Uplink/Downlink Summary*

UPLINK / DOWNLINK SUMMARY

VEHICLE LINKS U/D BAND LINK

CRITICALLITY DATA

RATE SURV AJ LINK CONTENTS NOTES

G E O

Link 1s

(SMCS/SRGS)

D K MC

20.2525 GHz (Backup -

20.4525 GHz)

1 Mbps Y N Scanner Exceedences, Status

Survivable Global ONLY (includes H&S), Has an Interleaver

Link 1t

(RGS)

D K MC

20.4525 GHz (Backup -

20.4625 GHz)

2.5 Mbps N N1 L1s + Starer Exceedences

Same content as L4, Does not have Interleaver

Link 2 (Freq Hopping)

U (76.5 dBW)

Q MC

Fc = 44.5 GHz (Classified

BW)

19.2 Kbps N Y Commands, HEO Data Relay "Normal" Uplink, CMD Binary

Link 3 D K ME 20.7525 GHz 100 Mbps N N L1t + Scanner / Starer Raw Data Wideband Link, Includes L4

Link 4 D S MC

2.2525 GHz (Primary -

2.2625 GHz)

2.5 Mbps N N1 Same as L1t

Theater Link, Narrowband, Includes Link 1s, Available FOV of Vehicle

Link 5 D S MC 2.2375 GHz (SGLS 8) 32 Kbps3 N N Status/State of Health SGLS Status/State of Health (Primary for AFSCN ARTS / BU for

RGS)

Link 6 U

(72 dBW) S MC 1.791748 GHz (SGLS 8) 1 Kbps N N Commands

SGLS Commands, CMD Ternary (Primary for AFSCN ARTS / BU for

RGS)

H E O

WBT D n/a MC n/a 100 Mbps N N Scanner Raw Data, IRPL Status None HRT D n/a MC n/a 104 Kbps N N IRPL Status None

Cmd Req U n/a MC n/a n/a N N IRPL Commands None

D S P

Link 1/2 D S MC 2.2325 GHz (SGLS 8)

L1-1.024 Mbps

L2-128 Kbps

N2 N Scanner Exceedence, Status None

Link 2 D S MC 2.2375 GHz (SGLS 8) 128 Kbps N N Status/State of Health None

Link 3 U

(72 dBW) S MC 1.791748 GHz (SGLS 8) 1 Kbps N N Commands None

Table Notes:

1. Some downlink AJ capability provided by simultaneous transmission of S-band (L4) and K-band (L1t)

2. DSP downlink survivability provided by M3P S-band kits for strategic M3Ps

3. GEO Link 5 is nominally 4 or 8 Kbps

4. S-Band range is 2.2 - 2.3 GHz; K-Band Range is 18-27 GHz; Q-Band Range is 30-50 GHz

5. Link 1s, 1t, & 4 contain IR data exceedences (above threshold data and surrounding samples) plus real-time tasking information, ephemeris states, gyro & encoder data and state of health data

6. Link 3 contains compressed raw data (all samples), partially calibrated onboard the spacecraft for GEO to improve its compression rates

*Extracted from SR3020 Vol 5 Appendix C/Revision A

ACRONYMS

Acronym Description AD Advance Systems and Development Directorate AD Advance Systems and Development Directorate API Application Programming Interfaces ASP Application Service Provider BA Battlespace Awareness BA Battlespace Awareness BOA Ballistic Missile Defense System (BMDS) OPIR Architecture C/E Civil/Environmental C2 Command and Control CIB Common Interactive Broadcast CMF Common Message Format COTS Commercial Off-The-Shelf CP Cloud Provider DCGS Distributed Common Ground System DDD Data Description Document DoD Department of Defense DSP Defense Support Program DSP Defense Support Program EGP Exceedance Generation Processing EGS Enterprise Ground Services eWIT enhanced Wideband Imagery Tool FORGE Future Operationally Resilient Ground Evolution FOSS Free or Open Source Software GC Ground Control GCN Global Communication Networks GEO Geostationary Earth orbit or Geosynchronous equatorial orbit GOTS Government Off-The-Shelf HEMI Highly Efficient Mission Integrator HEO Highly Elliptical Orbit IBS Integrated Broadcast Service IC Intelligence Community ICD Initial Capabilities Document / Interface Control Document ISR Intelligence, Surveillance and Reconnaissance ITW/AA Integrated Tactical Warning and Attack Assessment IV&T Integration, Verification, and Testing JMS Joint Space Operations Center (JSpOC) Mission System JOG Joint OPIR Ground JWICs Joint Worldwide Intelligence Communications System KPP Key Performance Parameter MCS Mission Control Station MCS-B Mission Control Station-Backup MD Missile Defense MDP Mission Data Processing MVP Minimum Viable Product MW Missile Warning N/CGA Neptune / Common Ground Architecture NASIC National Air and Space Intelligence Center NIPR Non-Classified Internet Protocol Router Network NOMS Network-Independent Open Source Messaging Service OA Open Architecture OBAC OPIR Battlespace Awareness Center OFA Open Framework Architecture ODP Object Dependent Processing

Acronym Description OPGA Overhead Persistent Ground Architecture ORD Operational Requirements Document PGMM Persistent GEOINT Mission Management (PGMM) POC Point Of Contact PoR Program of Record RFI Request for Information RGS Remote Ground Station RS Remote Sensing Systems Directorate RSOC Remote Space Operations Center RSX Remote Sensing System Directorate Exploitation Division RSXI Remote Sensing System Directorate Exploitation Division Future Ground Integration Branch RTS Real-time Transfer Service SAG System Administrator’s Guide SAGE Space Awareness Global Exploitation SARC Satellite Anomaly Resolution Center SBIRS Space-Based Infrared System SDK Software Development Kit SIPR Secret Internet Protocol Router Network SMC Space and Missile Systems Center SMW Strategic Missile Warning SOC Statement of Capability SOFA Sensor Open Framework Architecture SPOTS Satellite Payload Orbital Test Station SSP Sensor Signal Processing STSS Space Tracking and Surveillance System SUM Software User’s Manual TAP Tools, Applications, and Processing TI Technical Intelligence VMOC Virtual Mission Operations Center