NOAA GEO GS SE RFI Attachment 5 GGSS FPS.pdf

Effective Date: Date of Last Signature 416-GEO-FPS-0091 Responsible Organization: GOES-R/Code 416 Version 1.1 i

Geostationary (GEO) Ground Sustainment Services (GGSS) Functional and Performance Specification (F&PS)

Version 1.1 – March 20, 2024

U.S. Department of Commerce (DOC) National Oceanic and Atmospheric Administration (NOAA) National Environmental Satellite, Data, and Information Service (NESDIS) National Aeronautics and Space Administration (NASA) ii

GGSS Functional and Performance Specification

Approved by:

Signature on File

Kevin McMahon Date

GOES-R Ground Segment Project

Chief Engineer

Signature on File

Gyanesh Chander Date

Deputy Project Manager / Project Manager (Acting)

Vacant Date

Project Manager iii

CHANGE RECORD

GGSS Functional and Performance Specification

VERSION DATE

SECTIONS/PAGES

AFFECTED

DESCRIPTION

1.0 Apr. 4, 2022 All (CCR-03719) Initial Baseline

1.1 Mar. 20, 2024 pp. 194, 218 (CCR-03844) TLE format ref update

The document version number identifies whether the document is a working copy, final, revision, or update, defined as follows:

Working copy or Draft: A document not yet finalized or ready for distribution; sometimes called a draft. Use 0.1A, 0.1B, etc. for unpublished documents.

Final: The first definitive edition of the document. The final is always identified as Version 1.0.

Revision: An edition with minor changes from the previous edition, defined as changes affecting fewer than one-third of the pages in the document. The version numbers for revisions 1.1 through 1.9, 2.1 through 2.9, and so forth. After nine revisions, any other changes to the document are considered an update. A revision in draft, i.e. before being re-baselined, should be numbered as 1.1A, 1.1B, etc.

Update: An edition with major changes from the previous edition, defined as changes affecting more than one-third of the pages in the document. The version number for an update is always a whole number (Version 2.0, 3.0, 4.0, etc.)

iv

TABLE OF CONTENTS

1 INTRODUCTION

1.1 BACKGROUND

1.2 SCOPE

1.3 GOES-R MISSION OBJECTIVES

1.4 SPECIFICATION DERIVATION

1.5 TRACEABILITY

2 DOCUMENTATION

2.1 ORDER OF PRECEDENCE

2.2 DECLARATION OF REQUIREMENTS

3 GOES-R GROUND SYSTEM DESCRIPTION

3.1 GOES-R GS OVERVIEW

3.2 GOES-R GROUND SEGMENT REQUIREMENTS FUNCTIONAL DECOMPOSITION

3.3 GOES-R GS ROLE

3.4 GOES-R GS EXTERNAL INTERFACES

4 GS GENERAL REQUIREMENTS

4.1 OVERVIEW

4.2 PHYSICAL DEPLOYMENT AND REMOTE OPERABILITY

4.2.1 Primary Facilities

4.2.2 Consolidated Backup Facility

4.2.3 Operations Support Locations

4.3 GROUND SEGMENT MAINTAINABILITY

4.4 GROUND SEGMENT AVAILABILITY

4.5 LATENCY, REFRESH, AND PERFORMANCE

4.6 AUTOMATED TESTING/OPERATIONAL READINESS CHECKOUTS

4.7 MEASUREMENT

4.8 SECURITY

4.9 TELECOMMUNICATIONS

4.10 ACCESSIBILITY

4.11 ELECTROMAGNETIC INTERFERENCE

4.12 OPERATIONAL INTEGRITY

4.13 TIME REFERENCES

4.14 EXTENSIBILITY, MODULARITY, AND SCALABILITY

4.15 CONFIGURATION MANAGEMENT SYSTEM

4.16 ENHANCED AUDIT CAPABILITIES

4.17 DEVELOPMENT ENVIRONMENT

4.17.1 Calibration/Validation / WCDAS Product Maintenance

4.17.2 Level 2+ Algorithm Maintenance

4.18 INTEGRATION AND TEST ENVIRONMENT

4.19 OPERATOR HUMAN-MACHINE INTERFACE

5 ENTERPRISE MANAGEMENT REQUIREMENTS

5.1 OVERVIEW

5.2 GENERAL ENTERPRISE MANAGEMENT

5.2.1 Enterprise Management Data Management

5.2.2 Enterprise Management Performance

v

5.3 ENTERPRISE SUPERVISION

5.4 GROUND SEGMENT INFRASTRUCTURE

5.4.1 External Interface Supervision

5.4.2 Ground Segment Security Monitoring

6 MISSION MANAGEMENT REQUIREMENTS

6.1 OVERVIEW

6.2 OPERATIONAL VIEW

6.3 GENERAL MISSION MANAGEMENT

6.4 SATELLITE ENGINEERING TELEMETRY MONITORING

6.5 EVENT LOGS

6.6 MISSION MANAGEMENT REMOTE ACCESS

6.6.1 Remote Access to Mission Management Data

6.6.2 Mission Management Remote Access for Development

6.7 ANOMALY RESPONSE

6.8 GROUND DIRECTIVES

6.9 ENGINEERING TELEMETRY

6.10 ENGINEERING ANALYSIS

6.11 FLIGHT SOFTWARE MAINTENANCE

6.12 SATELLITE SIMULATOR INTERFACE

6.13 IMAGE NAVIGATION AND REGISTRATION

6.13.1 Image Navigation and Registration Monitoring and Performance

6.14 GRB PRODUCT MONITORING

6.15 COMMAND OPERATIONS

6.15.1 Command Verification

6.15.2 Ground Command Management

6.16 TELEMETRY

6.16.1 Pseudo Telemetry

6.16.2 Satellite State Monitoring

6.17 MISSION PLANNING AND SCHEDULING

6.18 SPACE-GROUND FUNCTIONAL COMMUNICATIONS

6.19 LAUNCH SEGMENT INTERFACE

6.20 SPACE SEGMENT INTERFACE

6.21 ANTENNA

6.22 TELEMETRY DOWNLINK RECEIVE

6.22.1 Telemetry Monitoring

6.23 RAW INSTRUMENT DATA PRE-PROCESSING

6.23.1 Ranging Services

6.23.2 Space-Ground Communications Performance

6.24 SPACECRAFT NAVIGATION

6.25 ORBIT DETERMINATION

6.26 LEVEL 0 PROCESSING

6.27 MISSION MANAGEMENT STORAGE

6.27.1 Raw Data Recorder

6.28 CALIBRATION SCHEDULING

7 PRODUCT GENERATION REQUIREMENTS

7.1 OVERVIEW

7.2 OPERATIONAL VIEW

7.3 PRODUCT GENERATION

vi

7.4 METADATA GENERATION

7.5 PRODUCT GENERATION SUPERVISION

7.6 GENERATE LEVEL 1 PRODUCTS

7.7 INSTRUMENT RADIOMETRIC (INCLUDING PHOTOMETRIC) AND ENERGETIC PARTICLE

CALIBRATION

7.8 GENERATE LEVEL 2+ PRODUCTS

7.9 PRODUCT GENERATION STORAGE

7.10 OPERATIONAL INSTRUMENT CALIBRATION DATA METRICS MONITORING

8 PRODUCT DISTRIBUTION REQUIREMENTS

8.1 OVERVIEW

8.2 PRODUCT AND DATA DISSEMINATION

8.3 AUTHORIZED USER SERVICES

8.4 DATA PRODUCT DELIVERY

8.5 PRODUCT DISTRIBUTION STORAGE

9 GS ANTENNA ELEMENT REQUIREMENTS

9.1 OVERVIEW

9.1.1 Background

9.1.2 Scope

9.2 SYSTEM-LEVEL REQUIREMENTS

9.2.1 General

9.2.2 Primary and Backup Site Functions

9.2.3 System Capabilities

9.2.4 System Life / Availability

9.2.5 Infrastructure

9.2.6 Environmental Requirements

9.2.7 Security

9.2.8 Software Maintenance

9.3 SAFETY

9.3.1 Personnel Safety Units (PSUs)

9.3.2 Emergency Provisions

9.3.3 Physical Safety

9.3.4 Safety Lighting

9.4 ANTENNA STATION REQUIREMENTS

9.4.1 Physical Structure

9.4.2 Drive System

9.4.3 Equipment Shelter

9.5 RADIO FREQUENCY (RF) REQUIREMENTS

9.5.1 General

9.5.2 Performance

9.5.3 Polarization, Axial Ratio, and Isolation

9.5.4 Radio Frequency Interference (RFI) / Electromagnetic Interference (EMI)

9.5.5 Receive Chain

9.5.6 Transmit Chain

9.5.7 DCS Pilot

9.6 ANTENNA MONITOR, CONTROL, AND TEST

9.6.1 General

9.6.2 Antenna Operating Modes

9.6.3 Antenna Control Unit (ACU)

vii

9.6.4 Personnel Maintenance Unit (PMU)

9.6.5 GOES-R Antenna Monitor, Control, and Test (GAMCATS)

9.6.6 Antenna Element Test

9.7 INTERMEDIATE FREQUENCY DISTRIBUTION

9.7.1 General

9.7.2 Auxiliary Distribution System (ADS)

9.7.3 Local Control Unit (LCU)

viii

TABLE OF FIGURES

FIGURE 1: GGSS REQUIREMENTS FLOWDOWN

FIGURE 2: GOES-R GS OVERVIEW

1 INTRODUCTION

1.1 Background

The current generation Geostationary Operational Environmental Satellites (GOES), designated the GOES-R Series, are required to provide continuity and improvement of remotely-sensed environmental data from a geosynchronous orbit. The first satellite launched in 2016. When the second GOES-R series satellite became operational in 2019, the GOES-R constellation became fully operational. There are two additional satellites in the GOES-R Series. Each satellite has an expected on-orbit lifetime of fifteen (15) years, thus extending the mission lifetime until at least 2035. The GOES-R Program, which has the responsibility to acquire and implement the GOES- R mission, is being implemented and sustained through the GOES-R Ground Segment Project (GSP) and the GOES-R Flight Project. The GSP manages the integrated, distributed GOES-R Ground System (GS) that conducts satellite operations and instrument product generation and distribution. Details about the GOES-R conceptual architecture, functionality, and operations are documented in the GOES-R Program Concept of Operations (410-R-CONOPS-0008).

1.2 Scope

This document, together with all GOES-R GS Interface Control Documents (ICDs) and the Geostationary Ground Sustainment Services (GGSS) Applicable and Reference Documents List (416-GEO-LIST-0090), specifies the functional and performance requirements with which the Core Ground Segment (CGS) and the Antenna Element, as defined in Section 1.4, complies.

Sections four (4) through nine (9) of this specification contain the high level functional and performance requirements of the GS. Each requirement includes the GSP Dynamic Object- Oriented Requirements System (DOORS) Identification (ID) Number and any rationale, assumption, and/or waiver noted.

1.3 GOES-R Mission Objectives

a) To maintain GOES mission continuity and quality in environmental observations, through at least 2035

b) To provide enhanced environmental data products

c) To improve services and data being provided to Users

d) To be responsive to technology infusion to meet evolving User needs

1.4 Specification Derivation

The GOES-R Series Level I Requirements Document (LIRD) (410-R-LIRD-0137) levies National Environmental Satellite, Data, and Information Service (NESDIS) requirements on the GOES-R Program. The Mission Requirements Document (MRD) (410-R-MRD-0070) captures the program - level system requirements and allocates a subset of those to the Geo Ground F&PS (416-GEO-FPS-0094), as shown in the hierarchy below in Figure 1. The GGSS F&PS (416- GEO-FPS-0091) defines derived GS level requirements applicable to the GGSS contractor.

These derived requirements are allocated to the GOES-R Antenna Element or the CGS. The CGS encapsulates Mission Management (MM), Product Generation (PG), Product Distribution (PD), and Enterprise Management (EM). Note that DO is a collection of the PG and PD functions; depending upon the context, they are sometimes referenced together as DO element or independently as PG and/or PD. Other documentation may reference the Infrastructure (IS) element, however, no GGSS requirements are allocated to IS. Parallel documents, such as the GOES-R Spacecraft Functional and Performance Specification (S-F&PS) (417-R-PSPEC-0014), and its associated ICDs, exist for the Space Segment.

Figure 1: GGSS Requirements Flowdown

1.5 Traceability

These requirements are controlled, managed, and traced using the GOES-R GSP DOORS requirements management tool. This document is configuration managed according to the GSP Configuration Management (CM) Plan (416-R-PLN-0169) and is maintained in the GSP CM tool.

2 DOCUMENTATION

2.1 Order of Precedence

Any inconsistency in this solicitation or contract will be resolved in accordance with Contract Clause 52.215-8 Order of Precedence.

Any inconsistency in other documents, exhibits, and attachments will be resolved by giving precedence in the following order:

a) The Performance Work Statement (PWS) and Task Order (TO) PWSs

b) The Functional and Performance Specification

c) The Interface Requirements Documents

d) The Interface Control Documents

e) Other exhibits and attachments included in Section J of the GGSS contract

f) The Applicable Documents

g) The Reference Documents Terminology applicable to this GGSS F&PS is documented in the GOES-R Series Acronym and Glossary Document (410-R-LIST-0142). In the event of conflict between terminology in this handbook and any other dictionary, the GOES-R terminology will take precedence.

The full lists of applicable and reference documents, with associated document number and date of issue for each, are maintained in the GGSS Applicable and Reference Documents List (416-

GEO-LIST-0090).

Applicable documents are Government prepared and controlled documents and industry standards documents.

Reference documents amplify or clarify the information presented in this document.

In the event of any unresolved conflict, the Contractor will request conflict resolution by the Contracting Officer.

2.2 Declaration of Requirements

The following requirements terminology is used throughout this document:

a) The term "shall" means that the function, service, or capacity described is a mandatory requirement for the GS.

b) The terms "shall provide the capability," "shall have the capability," "shall be capable," "shall enable," "shall permit," and "shall allow," means that the function, service or capacity described is a mandatory requirement for the GS, but that the capability, service or capacity may not necessarily be exercised continuously (e.g., event driven, operator selected, operator initiated).

c) All other declarative statements, including use of the term “will”, only designate statements of fact or intentions of the Government and are not to be interpreted as contractor requirements.

d) The term “(TBS)” means “to be supplied” and identifies missing or incomplete information, values, or data needed to fulfill a requirement.

e) The term “(TBD)” means “to be determined” and identifies a missing requirement.

f) The term “(TBR)” means “to be refined/reviewed” and identifies that the requirement is subject to review for appropriateness and subject to revision.

g) Requirements that contain the word "satellite" (singular) apply for all GOES-R series satellites operated in the multi-satellite environment, unless stated otherwise, consistent with the GS overall requirement for concurrent multiple satellite operations.

Refer to the PWS and TOs for Government and contractor responsibilities associated with TBSs, TBDs, and TBRs.

3 GOES-R GROUND SYSTEM DESCRIPTION

3.1 GOES-R GS Overview

Section 3 describes the GOES-R GS in terms of the high-level physical architecture, notional functional architecture, and external interfaces. Figure 2 shows an overview of the operational concept of the GOES-R GS.

Figure 2: GOES-R GS Overview

The GOES-R GS operates from three sites and two Operations Support Locations (OSLs).

The GS includes separate development and integration and test (I&T) environments for the purposes of ongoing development, improvement, and integration throughout the GOES-R mission. Portions of these environments are located at both the NOAA Satellite Operations Facility (NSOF) in Suitland, MD and the Wallops Command and Data Acquisition Station (WCDAS) in Wallops, VA to support local site development, integration, and test activities.

The satellites are commanded throughout their mission lifetime from the NOAA Satellite Operational Control Center (SOCC) located at NSOF with the ground station radio frequency (RF) interface located at the WCDAS or the Consolidated Backup (CBU) facility in Fairmont, WV. The engineering telemetry streams are received and processed at the WCDAS/CBU and ground relayed to the SOCC for processing and monitoring. The raw sensor data are received by the WCDAS, processed, reformatted, and rebroadcast through the GOES Rebroadcast (GRB) transponder.

The raw sensor data are received by the WCDAS, processed by the PG function at the WCDAS to create Level 1b (L1b) and some Level 2+ (L2+) products, and rebroadcast through the GRB transponder. In addition to the GRB transmission through the satellite, the data are also transmitted via terrestrial networks to support intra-system site-to-site transfer. The GRB data are then received at the NSOF where the PG function creates the rest of the L2+ products. The L1b and L2+ products are then either sent directly to or made available to users. At the CBU, the raw sensor data are received through its RF interface and processed by the PG function at the CBU. The CBU is limited to the production of data to support distribution via GRB and the production of Cloud and Moisture Imagery (CMI) and Sectorized CMI (Key Performance Parameters (KPPs)).

The GOES-R Series system provides the following unique payload services (UPS):

a) HRIT/EMWIN: EMWIN is a service that includes watches, warnings, forecasts, graphics, and other hydro-meteorological products provided by the National Weather Service (NWS). The High Rate Information Transmission (HRIT) data stream is comprised of satellite imagery, Data Collection System (DCS) products, derived products from GOES and Polar programs, and weather analysis and forecast maps from the NWS. The NESDIS Office of Satellite and Product Operations (OSPO) creates and merges the data streams (one for each of GOES East and GOES West) and provides to the GOES-R GS as an Intermediate Frequency (IF) signal for uplink.

b) DCS: The GOES DCS is a relay system used to collect information from earth-based platforms. These platforms transmit an electronic signal, containing the environmental data observed by the sensors on the platform, at predefined wavelengths and times. The transponder on board the GOES-R satellite detects this signal, and then continuously rebroadcasts it so that it can be received by the ground equipment only located at the WCDAS.

c) SARSAT: The GOES Search and Rescue Satellite Aided Tracking (SARSAT) transponder receives emergency beacon transmissions for relay to ground stations responsible for search efforts.

The GOES-R GS directly provides GOES-R data to the interface for the Advanced Weather Interactive Processing System (AWIPS). AWIPS is a computer workstation and communication network that serves as the nerve center of operations of all NWS Weather Forecast Offices (WFOs) and NWS River Forecast Centers (RFCs).

GOES-R provides data to the Level Zero Storage Service (LZSS) through PDA to provide archive services for GOES-R data. LZSS provides the archive and access services for the collection, archiving, and dissemination of environmental data collected by a variety of in situ and remote sensing observing systems.

3.2 GOES-R Ground Segment Requirements Functional Decomposition

The GOES-R GS requirements fall into five primary functional categories: MM, PG, PD, EM, and Antenna. These categories have been defined as a basis for grouping functional attributes of the GS. Necessary interface and support functions are included within the GS. The GS encompasses more than hardware and software systems, it includes the processes, services, and personnel required to accomplish a set of functional tasks.

3.3 GOES-R GS Role

The details and descriptions of each of the elements of the GOES-R GS (MM, IS, DO, Antenna, and EM) are provided in the GOES-R Series Concept of Operations (410-R-CONOPS-0008).

3.4 GOES-R GS External Interfaces

The GOES-R CGS and Antenna Element interfaces to the following entities:

a) GOES-R Space Segment

b) GOES-R Launch Segment

c) Unique Payload Services (HRIT/EMWIN, DCS)

d) Product Distribution and Access (PDA)

e) Advanced Weather Interactive Processing System (AWIPS)

f) Space Weather Prediction Center (SWPC) PG-PD systems

g) LZSS

h) N-Wave Trusted Internet Connections (TIC)

4 GS GENERAL REQUIREMENTS

4.1 Overview

Section four (4) specifies operational, functional, and performance requirements allocated across elements of the GOES-R GS as an end-to-end system. Requirements for facilities, security, reliability, maintainability, and availability (RMA), design and construction, verification and validation, and external interfaces are also included in this section.

4.2 Physical Deployment and Remote Operability

The GOES-R GS functionality is installed and operated at three sites and two Operations Support Locations (OSL). The NSOF and WCDAS are facilities that host GOES systems. Together, they serve as the GOES-R primary facilities for operations. The CBU hosts a subset of the GS functionality and enables continuity of operations. The OSL1 is located at the GGSS Contractor's factory facility and consists of workstations and network infrastructure, with no redundancy for local operators. OSL2 is located at the NOAA Center for Weather and Climate Prediction (NCWCP) in College Park, MD. Similar to OSL1, it consists of only workstations and network infrastructure, with no redundancy for local operators.

4.2.1 Primary Facilities

GGSSANT-1

GS Antenna Element functionalities described in this requirements document, unless specified otherwise, shall be deployed at the WCDAS.

GGSSCOR-1

CGS functionalities described in this requirements document, unless specified otherwise, shall be deployed at the WCDAS and NSOF (“the CGS primary facilities”).

Rationale: Constrains the location of all GS functionality to WCDAS and NSOF unless specifically identified as CBU-located. Functionality must reside at these locations in order to meet user/operator needs and to interface with legacy operations as directed by NOAA/NESDIS.

Assumptions: OSLs shall be treated separately from the other sites as far as the requirements are concerned.

GGSSCOR-2

The CGS at NSOF shall include the workstations for interfacing with Mission Management (MM), Enterprise Management (EM), and the Product Generation (PG) and Product Distribution (PD) functions as well as primary processing for select PG and PD functions.

Rationale: This aligns with NESDIS concepts of operations.

GGSSCOR-3

The CGS at WCDAS shall include the primary space communications services, EM and MM functions, and selected PG and PD functions.

Rationale: This aligns with current GOES operations and future NESDIS concepts of operations.

GGSSANT-2

The GS Antenna Element shall include all functionalities necessary for the RF uplink and reception of GRB at the WCDAS facility.

GGSSCOR-4

The CGS shall include all functionalities necessary for the production and terrestrial transmission of GRB at the WCDAS facility.

Rationale: WCDAS must be able to create GRB without dependence on other sites. This aligns with current GOES operations and future NESDIS concepts of operations.

GGSSCOR-8

The CGS shall include all functionalities necessary for the reception of terrestrial GRB at the NSOF facility.

Rationale: GRB is the only source of L1b data at NSOF. This is required to create higher-level products via the data contained in the GRB stream. GRB data will be the source for higher level product generation.

GGSSCOR-9

The CGS shall provide NSOF functionality that is operable from the NSOF.

Rationale: All functions at NSOF can be operated locally without dependence on other sites.

This ensures that the operators at a given site have the capability to operate independently of each other.

GGSSCOR-5

The CGS shall provide WCDAS functionality that is operable from the WCDAS.

Rationale: All functions at WCDAS can be operated locally without dependence on other sites. This ensures that the operators at a given site have the capability to operate independently of each other.

GGSSANT-5

The GS Antenna Element shall provide the capability to operate all WCDAS-deployed functionalities remotely from the NSOF.

GGSSCOR-7

The CGS shall provide the capability to operate all WCDAS-deployed functionalities remotely from the NSOF.

Rationale: Since the primary control operations occur at NSOF, NSOF must also be capable of operating WCDAS functions remotely. This capability could be used for contingency situations or for other non-emergency operations.

GGSSANT-67

The GS Antenna Element shall meet functional and performance specifications for four operational GOES-R satellites simultaneously.

GGSSANT-10164

The GS Antenna Element at the CBU shall meet functional and performance specifications for three operational GOES-R satellites simultaneously.

GGSSCOR-131

The CGS shall meet functional and performance specifications for four operational GOES-R satellites simultaneously.

Rationale: The GS capabilities must support simultaneous operations for two operational GOES-East and GOES-West satellites, and two storage satellites. COOP events will leverage Near Earth Network (NEN) assets to be used to manage the fourth satellite.

GGSSCOR-1321

The CGS at NSOF shall include the primary EM and MM functions and selected PG and PD functions.

GGSSCOR-1344

The CGS shall integrate into the existing NESDIS facilities infrastructure.

GGSSCOR-1381

The CGS WCDAS shall provide all functions necessary to generate GOES-U Compact Coronagraph (CCOR) L0 data as specified in the GOES-R Ground Segment (GS) and Space Weather Follow On (SWFO) GS Command and Control (C2) to Space Weather Prediction Center (SWPC) Interface Control Document (ICD) (TBD).

GGSSCOR-1382

The CGS WCDAS shall provide all functions necessary to distribute GOES-U CCOR L0 data to SWPC as specified in the GOES-R GS and SWFO GS C2 to SWPC ICD (TBD).

GGSSCOR-1383

The CGS WCDAS shall provide GOES-U CCOR-relevant data to SWPC as specified in the GOES-R GS and SWFO GS C2 to SWPC ICD (TBD).

Rationale: GOES-U CCOR-relevant data will include both CCOR housekeeping data and SUVI housekeeping data.

4.2.2 Consolidated Backup Facility

GGSSCOR-11

The CGS shall provide CBU functionality at the CBU.

Rationale: The GS CBU location was determined based on proximity to NSOF, geographic coverage, and non-interference with other RF carriers as documented in multiple trade studies.

GGSSANT-6

The GS Antenna Element shall provide CBU functionality that is operable from the NSOF.

GGSSCOR-10

The CGS shall provide CBU functionality that is operable from the NSOF.

Rationale: The CBU will not be staffed with operations personnel; thus remote operations from the primary facilities will be required. This capability will be used for contingency situations or for other non-emergency operations.

GGSSANT-10157

The GS Antenna Element shall provide CBU functionality that is operable from the WCDAS.

GGSSCOR-6

The CGS shall provide CBU functionality that is operable from the WCDAS.

Rationale: The CBU will not be staffed with operations personnel; thus remote operations from the primary facilities will be required. This capability may be used for contingency situations where certain elements of the CBU need to be operated by WCDAS personnel or for other non-emergency operations.

GGSSANT-7097

The GS Antenna Element at the CBU shall be operable from the CBU.

GGSSCOR-12

The CGS shall provide CBU functionality that is operable from the CBU.

Rationale: The CBU must have operator interfaces at the facility in the event that local CBU operations are required.

GGSSCOR-15

The CGS shall provide CBU functionality without on-site staff.

Rationale: During routine operations, the CBU will not be staffed with operations personnel.

Some maintenance personnel may be available either on-site or on-call, depending on the implementation and RMA approach for the CBU.

GGSSCOR-16

The CGS at the CBU shall provide all PG functions necessary to produce KPPs for Mode 3, Mode 4, and Mode 6 identified in the GS Product Catalog (416-GEO-CAT-0099).

Rationale: The CBU will not produce all L2+ products. However, it must be capable of producing mission-critical cloud and moisture imagery products as listed in the GS Product Catalog. This ensures the continuity of KPP production during a NSOF and/or WCDAS outage.

GGSSANT-9

The GS Antenna Element shall include all functionalities necessary for the RF uplink, and reception of GRB at the CBU.

GGSSCOR-18

The CGS shall include all functionalities necessary for the production, and terrestrial transmission of GRB at the CBU.

Rationale: This ensures the continuity of GRB during a NSOF and/or WCDAS outage.

GGSSCOR-19

The CGS at the CBU shall provide all PD functions necessary to distribute KPPs to AWIPS as specified in the GOES-R Series Ground Segment (GS) to Advanced Weather Interactive Processing System (AWIPS) Interface Control Document (ICD) (416-R-ICD-0382).

Rationale: KPP distribution includes the sectorization and distribution of cloud and moisture imagery via AWIPS to the AWIPS demarcation point as described in the GS-to-AWIPS IRD.

This ensures the continuity of KPP product distribution during a WCDAS outage.

Assumptions: CBU L2+ PD capability will be limited to KPP distribution to AWIPS.

GGSSCOR-1384

The CGS CBU shall provide all functions necessary to generate GOES-U CCOR L0 data as specified in the GOES-R GS and SWFO GS C2 to SWPC ICD (TBD).

GGSSCOR-1385

The CGS CBU shall provide all functions necessary to distribute GOES-U CCOR L0 data to SWPC as specified in the GOES-R GS and SWFO GS C2 to SWPC ICD (TBD).

GGSSCOR-1386

The CGS CBU shall provide GOES-U CCOR-relevant data to SWPC as specified in the GOES- R GS and SWFO GS C2 to SWPC ICD (TBD).

Rationale: GOES-U CCOR-relevant data will include both CCOR housekeeping data and SUVI housekeeping data.

GGSSCOR-20

The CGS shall be capable of supporting the following single functions or combination of functions at the CBU:

a) Space - Ground Communications

b) Command Generation and Telemetry Data Processing

c) Raw (instrument) Data Processing to Level 0

d) Mission Operations to include real-time console operations, offline engineering and trending, bus and instrument health and safety monitoring, anomaly detection and resolution and procedure development

e) Signal Monitoring

f) Mission Scheduling and Planning

g) Orbit Determination and Maneuver Planning

h) Image Navigation and Registration Monitoring

i) Routine Instrument Calibration Support and Product Monitoring

j) Production of Level 1b Products and Global Lightning Mapper (GLM)

k) Generation of KPPs

l) Terrestrial GRB Assembly and Rebroadcast

m) Sectorized Product Distribution to AWIPS

n) Life of mission storage (e.g., telemetry, EM event messages)

o) 5-day temporary revolving storage

p) Enterprise Management to include system control and monitoring, security management, and service desk

q) Antenna Monitor, Control, and Test

Rationale: This list of functions is a subset of GS capabilities to be provided by the CBU.

Since the CBU will not provide a complete MM, PG, PD, or EM backup, this list breaks down the element functionality into a more granular functional level. The intent is that each of these functions will be independently usable at the CBU, such that one function could fail-over to the CBU without the need to fail over the entire set of NSOF or WCDAS operations. Failover by function is in response to contingency planning and failover strategies being employed by current operations. These include failover of KPP production and distribution if NSOF KPP processing goes down, however, remote SOCC operations may still be accomplished from the NSOF. Failover by function allows more flexibility in the use of the CBU to meet availability requirements in the event of maintenance downtime without full failover.

4.2.3 Operations Support Locations

GGSSCOR-1322

The CGS shall provide OSLs for mission support within the NOAA 5050 boundary.

GGSSCOR-22

The portion of the CGS located at OSL1 shall include workstations and supporting network infrastructure deployed as part of the Non-Supervisory Control and Data Acquisition (Non- SCADA) Security Domain (NSD) and the SCADA Security Domain (SSD).

GGSSCOR-23

The portion of the CGS located at OSL2 shall include workstations and supporting network infrastructure deployed as part of the NSD.

GGSSCOR-24

The CGS shall prevent satellite commands from originating at any OSL.

GGSSCOR-25

The CGS shall prevent any OSL workstation from taking primary commanding authority, regardless of operator privilege.

Rationale: OS/COMET is the current T&C tool, providing Workstation in Control (WIC) capability.

GGSSCOR-26

The portions of the CGS located at any OSL shall be remotely operable and updatable from any of the primary three CGS sites.

4.3 Ground Segment Maintainability

GGSSANT-11

The GS Antenna Element design shall enable hardware and software maintenance of the GS while maintaining compliance with the functional and performance requirements of the GOES-R Series System.

GGSSCOR-27

The CGS design shall enable hardware and software maintenance of the CGS while maintaining compliance with the functional and performance requirements of the GOES-R Series System.

Rationale: The GS must remain within specifications while undergoing maintenance. This includes maintaining availability and Maximum Time to Restore Service (MaxTTRS) within specifications.

GGSSANT-13

The GS Antenna Element shall include diagnostic tools to support maintenance of all internal GS interfaces.

GGSSCOR-29

The CGS shall include diagnostic tools to support maintenance of all internal GS interfaces.

Rationale: Diagnostic tools are to be delivered with the GS to support its interfaces. These tools will enable the maintainer to diagnose interface issues without the need for additional support.

GGSSANT-14

The GS Antenna Element shall include diagnostic tools to support maintenance of all external GS interfaces.

GGSSCOR-30

The CGS shall include diagnostic tools to support maintenance of all external GS interfaces.

Rationale: Diagnostic tools are to be delivered with the GS to support its interfaces. These tools will enable the maintainer to diagnose interface issues without the need for additional support.

GGSSANT-15

All elements of the GS Antenna Element shall make all locally collected performance and status measurements available to EM.

GGSSCOR-31

All elements of the CGS shall make all locally collected performance and status measurements available to EM.

Rationale: The EM element will collect and monitor all performance and status for all GS systems, subsystems, components, and configuration items. If an element is collecting performance and/or status metrics, those will be available to the EM element as well.

GGSSANT-16

All elements of the GS Antenna Element shall make all locally detected hardware and software event messages available to EM.

GGSSCOR-32

All elements of the CGS shall make all locally detected hardware and software event messages available to EM.

Rationale: The EM element will collect and monitor all anomalies for all GS systems, subsystems, components, and configuration items. If an element is performing anomaly detection and reporting, those reports will be available to the EM element as well.

GGSSANT-17

The GS Antenna Element shall make resource operational status and performance data available to EM, including: resource utilization (processing, storage, network and communications status), processing throughput, equipment configuration and availability, to support operations, trending, and performance analyses.

GGSSCOR-33

All elements of the CGS shall make resource operational status and performance data available to EM, including: resource utilization (processing, storage, network and communications status), processing throughput, equipment configuration and availability, data accounting, data processing status, transfer status, and product status, to support operations, trending, and performance analyses.

Rationale: This describes a set of status and performance data types that will be made available to EM. Other requirements may impose additional data types as the GS is designed and implemented.

GGSSANT-18

The GS Antenna Element shall have the capability to export any operator designated file to removable media.

GGSSCOR-34

The CGS shall have the capability to export any operator designated file to removable media.

Rationale: Allows any file to be copied from the system (as permitted by security requirements). This may be needed for offline analysis or for other uses. Examples of removable media include thumb drive, compact disk, tape, etc.

GGSSANT-19

The GS Antenna Element shall have the capability to store any operator designated file to removable media.

GGSSCOR-35

The CGS shall have the capability to store any operator designated file to removable media.

Rationale: Allows any file to be copied from the system (as permitted by security requirements). This may be needed for offline analysis or for other uses. Examples of removable media include thumb drive, compact disk, tape, etc.

GGSSANT-7198

The GS Antenna Element shall permit an operator to install or upgrade software from any site within the GS.

GGSSCOR-36

The CGS shall permit an operator to install or upgrade software from any site within the GS.

Rationale: Software modifications within the GS can occur from any GS authorized site to any other site. This requirement provides for software at NSOF or CBU to be installed/upgraded from WCDAS, software at WCDAS and CBU to be installed/upgraded from NSOF, and software at NSOF/WCDAS to be installed/upgraded from CBU. This may also include access from the GS Factory, Satellite Factory, and/or other locations as defined by the GSP. This enables the consolidation of software maintenance and/or development activities if desired by the operations personnel. It also enables rapid patch deployment or software distribution via a unified mechanism, improving configuration management capabilities and potentially reducing costs.

GGSSANT-7199

The GS Antenna Element shall enable access and inspection of software at any site, from any other site.

GGSSCOR-37

The CGS shall enable access and inspection of software at any site, from any other site.

Rationale: Software access and inspection within the GS can occur from any GS authorized site to any other site. This requirement provides for software at NSOF or CBU to be accessed and inspected from WCDAS, software at WCDAS and CBU to be accessed and inspected from NSOF, and software at NSOF/WCDAS to be accessed and inspected from CBU. This may also include access from the GS Factory, Satellite Factory, and/or other locations as defined by the GSP. This enables the consolidation of software maintenance and/or development activities if desired by the operations personnel. It also enables rapid inspection of software via a unified mechanism, improving configuration management capabilities and potentially reducing costs.

GGSSANT-10161

The GS Antenna Element shall enable modification of software at any site from any other site.

GGSSCOR-38

The CGS shall enable modification of software at any site from any other site.

Rationale: Software modifications within the GS can occur from any GS authorized site to any other site. This requirement provides for software at NSOF or CBU to be modified from WCDAS, software at WCDAS and CBU to be modified from NSOF, and software at NSOF/WCDAS to be modified from CBU. This enables the consolidation of software maintenance and/or development activities if desired by the operations personnel. It also enables rapid patch deployment or software distribution via a unified mechanism, improving configuration management capabilities and potentially reducing costs.

GGSSANT-7200

The GS Antenna Element shall enable testing of software at any site from any other site.

GGSSCOR-39

The CGS shall enable testing of software at any site from any other site.

Rationale: Software testing within the GS can occur from any GS authorized site to any other site. This requirement provides for software at NSOF or CBU to be tested from WCDAS, software at WCDAS and CBU to be tested from NSOF, and software at NSOF/WCDAS to be tested from CBU. This may also include access from the GS Factory, Satellite Factory, and/or other locations as defined by the GSP. This enables the consolidation of software maintenance and/or development activities if desired by the operations personnel. It also enables testing and troubleshooting of software via a unified mechanism, improving configuration management capabilities and potentially reducing costs.

GGSSANT-7201

The GS Antenna Element shall enable distribution of software at any site, from any other site.

GGSSCOR-40

The CGS shall enable distribution of software at any site, from any other site.

Rationale: Software distribution can occur between any GS authorized combination of sites.

The GS will have interfaces and connectivity that enable this distribution. Because of this, software development and maintenance activities may be consolidated, which could reduce costs and improve configuration management capabilities.

GGSSANT-12

The GS Antenna Element shall provide information and diagnostic tools, to include an online knowledge base, to isolate faults internal to the GS.

GGSSCOR-28

The CGS shall provide information and diagnostic tools, to include an online knowledge base, to isolate faults internal to the GS.

Rationale: The GS will enable operators to isolate and diagnose GS faults.

4.4 Ground Segment Availability

Operational availability is the fraction of time that the GOES-R Ground Segment (or a specified functionality contained within) is fully functional over a discrete 30-day period. This includes the GOES-R facilities, antennas, and networks out to the extent of the demarcations as defined in the ICDs. Maximum time to restore service (MaxTTRS) requirements are considered to be met at the 99.9 percentile (e.g., if an outage occurs, there is a 0.999 probability that service will be restored within the specified interval).

GGSSANT-25

The GS Antenna Element shall operate continuously for the life of the GOES-R System.

GGSSCOR-46

The CGS shall operate continuously for the life of the GOES-R System.

Rationale: The GS operates without interruption or scheduled halts in operations because the satellites are operating continuously.

GGSSCOR-51

The CGS shall have a minimum Operational Availability of 0.989 over the GOES-R System lifetime, except for functionality for which a higher Operational Availability has been specified.

Rationale: The GS is required to have a system availability of 0.989 to support operational requirements. Because of this, the overall GS availability must be at least 0.989. However, many mission critical functions (described below) have a higher availability that takes precedence over this value.

Assumptions: Operational Availability = Total uptime / Total time

The flight-provided offline engineering and trending tool is excluded from GS Operational Availability requirements.

GGSSANT-29

The GS Antenna Element shall have a MaxTTRS of 120 minutes for functions other than those for which a shorter MaxTTRS has been specified.

GGSSCOR-58

The CGS shall have a MaxTTRS of 120 minutes for functions other than those for which a shorter MaxTTRS has been specified.

Rationale: All functions within the GS must be restored to operational status within a maximum of 120 minutes. However, many mission critical functions (described below) have a more stringent maximum time to restore service that takes precedence over this value.

Assumptions: The flight-provided offline engineering and trending tool is excluded from GS MaxTTRS requirements.

Waiver: Portions of this requirement have been waived. DCN 7043166

GGSSCOR-52

The CGS shall have a minimum Operational Availability of 0.99988 for mission management functionality, averaged over a 30-day period.

Rationale: All of the Mission Management subsystem's functionality must be available

0.99988 of the time. If one Mission Management function is unavailable, then the period of unavailability counts against the Mission Management subsystem availability. In other words, the availability of all of the functions within the subsystem comprise the availability of the overall set, and so the availability of each function must exceed the availability of the subsystem.

This helps minimize the downtime of the subsystem and ensure its availability for system operations. Availability value supports 5 minutes of outage time per month (43195 minutes of uptime/43200 total minutes)=0.99988.

Assumptions: All MM capabilities except for GRB product monitor and the Flight-provided offline engineering and trending tool are included.

GGSSCOR-59

The CGS shall have a MaxTTRS of 5 minutes for mission management functionality.

Rationale: If a function is lost that supports Mission Management functionality, it must be restored within a time period such that full MM functionality is restored within 5 minutes in response to operational requirements.

Assumptions: The flight-provided offline engineering and trending tool is excluded from GS MaxTTRS requirements.

GGSSCOR-53

The CGS shall have a minimum Operational Availability of 0.99988 for functionality associated with the generation and GRB distribution of products, averaged over a 30-day period.

Rationale: All of the GS functionality associated with GRB generation and distribution must be available 0.99988 of the time. If one function is unavailable, then the period of unavailability counts against the overall subsystem availability. In other words, the availability of all of the functions comprises the availability of the overall set. This helps minimize the downtime of the subsystem and ensure its availability. Availability value supports 5 minutes of outage time per month (43195 minutes of uptime/43200 total minutes)=0.99988.

Assumptions: Includes all MM & PG element capabilities required to receive & process instrument data, generate L1b, assemble GRB & prepare for uplink, & monitor GRB.

GGSSCOR-60

The CGS shall have a MaxTTRS of 5 minutes for functionality associated with the generation and GRB distribution of products.

Rationale: If a GS function is lost that supports GRB generation and distribution, it must be restored within a time period such that full GRB functionality is restored within 5 minutes.

GGSSCOR-54

The CGS shall have a minimum Operational Availability of 0.99861 for functionality associated with the generation of sectorized cloud and moisture imagery products, averaged over a 30-day period.

Rationale: All of the GS functionality associated with sectorized cloud and moisture imagery product generation must be available 0.99861 of the time. If one function is unavailable, then that period of unavailability counts against the overall subsystem availability. In other words, the availability of all of the functions comprises the availability of the overall set. This helps minimize the downtime of sectorized cloud and moisture imagery generation. Availability value supports 60 minutes of outage time per month (43140 minutes of uptime/43200 total minutes)=.99861.

GGSSCOR-55

The CGS shall have a minimum Operational Availability of 0.99861 for functionality associated with the delivery of sectorized cloud and moisture imagery products, as specified in the GS to AWIPS ICD (416-R-ICD-0382), to the AWIPS demarcation point, averaged over a 30-day period.

Rationale: All of the GS functionality associated with sectorized cloud and moisture imagery product generation must be available 0.99861 of the time. If one function is unavailable, then that period of unavailability counts against the overall subsystem availability. In other words, the availability of all of the functions comprises the availability of the overall set. This helps minimize the downtime of sectorized cloud and moisture imagery distribution to the AWIPS demarcation point. Availability value supports 60 minutes of outage time per month (43140 minutes of uptime/43200 total minutes)=0.99861.

GGSSCOR-61

The CGS shall have a MaxTTRS of 60 minutes for functionality associated with sectorized cloud and moisture imagery products data collection, processing, and distribution to the AWIPS demarcation point.

Rationale: If a GS function is lost that support cloud and moisture imagery sectorization and distribution, it must be restored within a time period such that full functionality is restored within 60 minutes.

GGSSCOR-56

The CGS shall have a minimum availability of 0.9998 for components associated with the generation of non KPP Level 2+ products, averaged over a 30 day period.

Rationale: All of the GS functionality associated with non-KPP L2+ product generation must be available 0.9998 of the time. If one function is unavailable, then that period of unavailability counts against the overall subsystem availability. In other words, the availability of all of the functions comprises the availability of the overall set. This helps minimize the downtime of those functions required for non-KPP L2+ product generation activities.

GGSSCOR-57

The CGS shall have a minimum Operational Availability of 0.9999, averaged over a 30-day period, for those functions associated with the distribution of End Products to the PDA.

Rationale: All of the core GS functionality associated with non-KPP L2+ product distribution must be available 0.99 of the time. If one function is unavailable, then that period of unavailability counts against the overall subsystem availability. In other words, the availability of all of the functions comprises the availability of the overall set. This helps minimize the downtime of those functions required for non-KPP L2+ product distribution activities.

GGSSCOR-47

The CGS shall have no single point of failure at any site in mission management functionality.

Rationale: Redundancy is necessary in mission critical functionality such as Mission Management. Designing a system to avoid single point failures helps minimize the likelihood of a catastrophic failure that jeopardizes the system's health and safety.

GGSSANT-26

The GS Antenna Element shall have no single point of failure at any site in GRB product distribution functionality.

GGSSCOR-48

The CGS shall have no single point of failure at any site in L0, L1b, GLM, GRB, and sectorized cloud and moisture imagery product generation and distribution functionality.

Rationale: Redundancy is necessary in mission critical functionality such as these.

Designing a system to avoid single point failures helps minimize the likelihood of a catastrophic failure that jeopardizes the system's ability to generate the key data products that GOES-R will produce and provide them to the user.

Assumptions: This does not apply to EM functionality.

GGSSANT-27

The GS Antenna Element shall be designed such that a failure in any function of the system does not impact the ability of redundant, back-up, or contingency instances of the functionality to perform the function.

GGSSCOR-49

The CGS shall be designed such that a failure in any function of the system does not impact the ability of redundant, back-up, or contingency instances of the functionality to perform the function.

Rationale: Intended to limit the potential for cascading failures due to common failure modes. If a function fails at NSOF, it must not also fail at CBU for the same reason at the same time. Independence of operations between primary, backup, and contingency instances helps to increase the system's operational availability.

GGSSCOR-50

The CGS shall isolate anomalies by function and by site.

Rationale: Intended to limit the potential for cascading failures due to an anomaly at a given site in a given function. The intent is that a failure is limited to the function in which it occurred and at the site in which it occurred. This will help to increase overall system operational availability.

GGSSANT-33

The GS Antenna Element shall initiate transmission of failover configuration messages for a given function to a functionality's backup site upon detection of a loss of that functionality at the primary site.

GGSSCOR-65

The CGS shall initiate transmission of failover configuration messages for a given function to a functionality's backup site upon detection of a loss of that functionality at the primary site.

Rationale:…