GPS OCCULTATION SENSOR (GPSOS)
Sensor Requirements Document (SRD)
for
NATIONAL POLAR-ORBITING OPERATIONAL ENVIRONMENTAL SATELLITE SYSTEM (NPOESS) SPACECRAFT AND SENSORS
Prepared by
Associate Directorate for Acquisition
NPOESS Integrated Program Office
17 March 1997
Integrated Program Office
Silver Spring MD 20910
Table of Contents i1. SCOPE 81.1 IDENTIFICATION 81.2 SENSOR OVERVIEW 81.3 DOCUMENT OVERVIEW 81.3.1 Conflicts 91.3.2 Requirement Weighting Factors 91.4 SYSTEM CLASSIFICATIONS N/A 92. APPLICABLE DOCUMENTS 102.1 GOVERNMENT DOCUMENTS 102.2 NONGOVERNMENT DOCUMENTS 112.3 REFERENCE DOCUMENTS 113. SENSOR REQUIREMENTS 143.1 DEFINITION 143.1.1 Sensor Description 143.1.1.1 General Sensor Characteristics 143.1.2 System Segments N/A 173.1.3 Specification Tree. 173.1.4 Top-Level Sensor Functions 183.1.5 Sensor Modes 183.1.5.1 Common Sensor Modes 183.1.5.1.1 Sensor Off Mode 183.1.5.1.2 Operational Mode 183.1.5.1.3 Sensor Diagnostic Mode 193.1.5.1.4 Sensor Safe Hold Mode 193.1.5.2 GPSOS Sensor Specific Modes 193.1.5.3 Payload Mode Documentation 193.1.6 Operational and Organizational Concept 193.1.6.1 Launch Operations Concept 193.1.6.1.1 Pre Launch 193.1.6.1.2 Launch 193.1.6.2 On-orbit Operational Concept 203.1.6.2.1 Overview 203.1.6.2.2 On-orbit Tests 203.1.6.2.3 Operations 203.1.6.2.4 GPSOS Sensor Checkout and Diagnostics 223.1.6.2.5 GPSOS Contractor Responsibilities 223.1.7 Missions 233.2 SENSOR CHARACTERISTICS 233.2.1 Performance Characteristics 233.2.1.1 Performance Requirements 233.2.1.1.1 GPSOS Environmental Primary Vs Secondary EDRs 233.2.1.1.1.1 Definition - Primary EDR 243.2.1.1.1.2 Definition - Secondary EDR 243.2.1.1.2 EDR Requirements 243.2.1.1.2.1 Requirements Format 243.2.1.1.2.2 Attribute Values 243.2.1.1.2.3 Attribute Values Expressed as Percentages 243.2.1.1.2.4 Vertical Height 253.2.1.1.3 GPSOS EDRs 253.2.1.1.3.1 Primary GPSOS EDRs 253.2.1.1.3.2 Secondary GPSOS EDRs 273.2.1.1.3.3 Multiple Sensor Requirements 273.2.1.1.4 RDR Requirements 273.2.1.1.5 Earth Location Requirements 273.2.1.1.6 Scientific Algorithms 283.2.1.1.7 Scientific Algorithm Convertibility to Operational Code 283.2.1.1.8 GPSOS Interface to GPS & GLONASS Satellites 283.2.1.2 Sensor Calibration , See Section 3.1.1.1 293.2.1.3 Data Access 293.2.1.4 Data Format 293.2.1.5 Data Time Synchronization 293.2.2 Sensor Capability Relationships 293.2.2.1 Reference Timelines & Master Satellite Clock Synchronization 293.2.2.2 Relationships between Sensors 303.2.3 Interface Requirements 303.2.4 Physical and Interface Characteristics 323.2.4.1 Mass Properties 33Error!3.2.4.1.1 Sensor Mass Documentation 333.2.4.1.2 Sensor Mass Variability Documentation 333.2.4.1.3 Center of Mass 333.2.4.1.3.1 Center of Mass Allocation 333.2.4.1.3.2 Center of Mass Measurement and Documentation 333.2.4.1.4 Moments of Inertia 333.2.4.1.4.1 Moments of Inertia Measurement 333.2.4.1.4.2 Moments of Inertia Accuracy 343.2.4.1.4.3 Moments of Inertia Documentation 343.2.4.1.4.4 Moments of Inertia Variation Documentation 343.2.4.2 Dimensions 343.2.4.2.1 Physical Interface 343.2.4.2.1.1 Stowed and Critical Clearances 343.2.4.2.1.2 Mounting Provisions 353.2.4.2.1.3 Alignment 363.2.4.2.1.4 Structural Support 373.2.4.2.1.5 Sensor Structural Dynamics 373.2.4.3 Power 383.2.4.3.1 Sensor Internal Power 383.2.4.3.1.1 Peak Power TBD 383.2.4.3.1.2 Power Cycle TBD 383.2.4.3.1.3 On-orbit Power TBD 383.2.4.3.1.4 Launch Power TBD 383.2.4.3.1.5 End-of-life Power TBD 383.2.4.3.2 Sensor External Power 383.2.4.3.3 Electrical Power Interface Requirements 383.2.4.3.3.1 Electrical Interfaces 383.2.4.3.3.2 Electrical Current 403.2.4.3.3.3 Grounds, Returns, and References 403.2.4.3.3.4 Power Harnesses 413.2.4.3.3.5 Signal Cabling 413.2.4.4 Survivability 423.2.4.5 Endurance (TBR) 423.2.4.6 Protective Coatings and Finishes 423.2.4.7 Thermal 433.2.4.7.1 General 433.2.4.7.2 Thermal Isolation to Spacecraft 433.2.4.7.3 Heat Transfer 433.2.4.7.3.1 Heat Transfer 433.2.4.7.3.2 Radiation 433.2.4.7.4 Temperature Ranges 443.2.4.7.4.1 Spacecraft Temperature Range 443.2.4.7.4.2 Thermal Uncertainty Margins 443.2.4.7.4.3 Sensor Temperature Range 443.2.4.7.5 Temperature Monitoring 443.2.4.7.5.1 Mechanical Mounting Interface Temperature Monitoring 443.2.4.7.5.2 Sensor Temperature Monitoring 443.2.4.7.5.3 Temperature Sensor Locations 453.2.4.7.6 Thermal Control Design 453.2.4.7.6.1 Thermal Control Hardware 453.2.4.7.6.2 Survival Heater Design 453.2.4.7.6.3 Multilayer Insulation 463.2.4.7.6.4 Other Considerations 463.2.4.8 Data and Command Interface 463.2.4.8.1 General Command Electrical 463.2.4.8.1.1 Interface Conductors 463.2.4.8.1.2 Interface Circuitry Isolation 463.2.4.8.1.3 Interface Fault Tolerance 463.2.4.8.1.4 Power Bus 463.2.4.8.2 Command and Telemetry Data Bus Requirements 473.2.4.8.2.1 Bus Functions 473.2.4.8.2.2 Bus Type 473.2.4.8.2.3 Bus Configuration 483.2.4.8.3 General Bus Requirements 483.2.4.8.3.1 Electrical Interface 483.2.4.8.3.2 Data Bus Monitoring 493.2.4.8.4 Sensor Commands and Memory Load 493.2.4.8.4.1 Command Types 493.2.4.8.4.2 Packetization for Commands and Memory Loads 493.2.4.8.4.3 Documentation 493.2.4.8.4.4 Critical Commands 503.2.4.8.4.5 Frame Sync and Time Code Data 503.2.4.8.5 Health and Status Telemetry Data 503.2.4.8.5.1 Telemetry Diagnostic Data 503.2.4.8.6 Low Rate Science Data 503.2.4.8.6.1 Telemetry and Low Rate Data Packetization 503.2.4.8.7 Data Bus Sampling Rate 503.2.4.9 High Rate Bus 513.2.4.9.1 Bus Functions 513.2.4.9.2 High Rate Data Bus Transmission Rate 513.2.4.9.3 Bus Type 513.2.4.9.4 High Rate Data Packetization 513.2.5 Sensor Quality Factors 513.2.5.1 Reliability 513.2.5.1.1 Operational Service Life 513.2.5.1.2 Maintainability 513.2.6 Environmental Conditions 523.2.6.1 Natural Environment Characteristics 523.2.6.1.1 Total Ionizing Dose Environment 523.2.6.1.2 Cosmic Ray and High Energy Proton Environment 533.2.6.1.2.1 Single Events Radiation Environment 533.2.6.1.2.2 Displacement Damage 543.2.6.2 Launch Environment 543.2.6.2.1 Thermal (TBS) 543.2.6.2.1.1 Temperatures 543.2.6.2.1.2 Heat Flux (TBS) 553.2.6.2.1.3 Free Molecular Heating 553.2.6.2.2 Shock (TBS) 563.2.6.2.3 Acceleration Load Factors 563.2.6.2.4 Vibration 563.2.6.2.5 Acoustics 563.2.7 Transportability 583.2.8 Flexibility and Expansion 593.2.8.1 Operational Computer Resource Reserves 593.2.8.1.1 Computer Resource Reserves for Operational Space Elements 593.2.8.1.1.1 Data Processing Processor Reserves 593.2.8.1.1.2 Data Processing Primary Memory Reserves 593.2.8.1.1.3 Data Processing Peripheral Data Storage (Secondary Memory) Reserves 593.2.8.1.1.4 Data Processing Data Transmission Media 603.2.8.1.1.5 Data Processing Software/Firmware 603.3 DESIGN AND CONSTRUCTION 603.3.1 Materials 603.3.1.1 Toxic Products and Formulations 603.3.1.2 Parts Selection 603.3.1.3 Material Selection 613.3.2 Electromagnetic Radiation 613.3.2.1 Electromagnetic Interference (EMI) Filtering of Spacecraft Power 613.3.2.2 Electromagnetic Compatibility 613.3.2.2.1 General 613.3.2.2.2 Baseline Requirements 623.3.2.2.2.1 Sensor Electromagnetic Compatibility 623.3.2.2.2.2 Interface Margins 623.3.2.2.3 External Environment 623.3.2.2.2.3 Spacecraft Charging from All Sources 633.3.2.3.3 Wiring 633.3.2.3.4 Conducted and Radiated Interface Requirements 633.3.2.3.4.1 Radiated Emission RE101 633.3.2.3.4.2 Radiated Emissions RE102 633.3.2.3.4.3 Radiated Susceptibility RS101 633.3.2.3.4.4 Radiated Susceptibility RS103 633.3.3 Nameplates and Product Marking (See 5.2) 643.3.4 Workmanship 643.3.5 Interchangeability 643.3.6 Safety Requirements 643.3.6.1 Design Safety Criteria 643.3.7 Human Engineering 653.3.8 Nuclear Control 653.3.9 Security 653.3.9.1 Communications Security (COMSEC) 653.3.9.2 Computer Security (COMPUSEC) 663.3.10 Government Furnished Property Usage 663.3.11 Computer Resources 663.3.11.1 Operational Computer Resources 663.3.11.1.1 Operational Computational Equipment 663.3.11.1.2 Operational Application Software (TBD) 663.3.11.1.3 Operating Systems Used in Operational Computers 663.3.11.1.3.1 Sensors Flight Software Requirements 663.3.11.1.3.2 Programming Language 663.3.11.1.4 Software Coding Conventions 673.3.11.1.5 Year 2000 Software Requirements 673.3.12 Sensor Design Requirements 673.3.12.1 General Structural Design 673.3.12.2 Strength Requirements 673.3.12.2.1 Yield Load 673.3.12.2.2 Ultimate Load 673.3.12.3 Stiffness Requirements 683.3.12.3.1 Dynamic Properties 683.3.12.3.2 Structural Stiffness 683.3.12.3.3 Component Stiffness 683.3.12.4 Structural Factors of Safety 683.3.12.4.1 Flight Limit Loads 683.3.12.4.2 Pressure Loads (TBR) 693.3.12.5 Design Load Conditions 703.3.12.6 Sensor Fluid Subsystems 703.3.12.6.1 Tubing 703.3.12.6.2 Separable Fittings 703.3.12.7 Moving Mechanical Assemblies 713.3.12.7.1 Actuating Devices (See 3.3.6.1) 713.3.12.7.2 Sensor Disturbance Allocation 713.3.12.7.3 Sensor Mechanisms 713.3.12.7.4 Uncompensated Momentum 713.3.12.7.5 Sensor Disturbance Allocations 713.3.12.7.5.1 Constant and Periodic Disturbance Torque Limits 713.3.12.7.5.2 Torque Profile Documentation 723.3.12.7.5.3 Thrust Direction Definition 723.3.12.8 Magnetics 723.3.12.9 Access 733.3.12.9.1 Access Identification 733.3.12.9.2 General Access 733.3.12.10 Mounting/Handling 733.3.12.10.1 Handling Fixtures 733.3.12.10.2 Mounting Orientation 733.3.12.10.3 Sensor to Spacecraft Integration and Test Mounting 733.3.12.10.4 Non-Flight Equipment 733.3.12.11 Venting 743.3.13 Operational Ground Equipment: General Design Requirements (TBD) 743.3.14 Non-operational Ground Equipment: (TBD) 743.3.15 General Construction Requirements 743.3.15.1 Processes and Controls for Space Equipment 743.3.15.1.1 Assembly Lots 753.3.15.1.2 Contamination (TBR) 753.3.15.1.2.1 Contamination Control Requirements 753.3.15.1.2.2 Facility Environmental Requirements 763.3.15.1.2.3 Sensor Inspection and Cleaning During I&T 763.3.15.1.2.4 Sensor Purge Requirements 763.3.15.1.2.5 Fabrication and Handling 763.3.15.1.2.6 Device Cleanliness 773.3.15.1.2.7 Outgassing Sensor Sources of Contamination 773.3.15.1.2.8 Atomic Oxygen Contamination 773.3.15.1.3 Electrostatic Discharge 783.4 DOCUMENTATION 783.4.1 Specifications 783.4.2 Interface Control Documents 783.4.3 Drawings and Associated List 783.4.4 Software (Including Databases). 783.4.5 Technical Manuals 783.5 LOGISTICS (TBD) 783.5.1 Maintenance Planning (TBD) 783.5.1.1 Sensor Maintenance Concepts (TBD) 793.5.2 Support Equipment (TBD) 793.5.3 Packaging, Handling, Storage, and Transportation (PHS&T) (TBD) 793.5.4 Facilities (TBR) 793.6 PERSONNEL AND TRAINING (TBD) 793.7 SENSOR SUITE COMPONENT CHARACTERISTICS (if required) (TBD) 794. QUALITY ASSURANCE AND TESTING PROVISIONS 804.1 Quality Assurance 804.1.1 SPECIAL TESTS AND EXAMINATIONS 804.1.1.1 Inspections and Tests of the Sensor 804.1.1.1.1 Sensor Parts, Materials, and Process Controls. 804.1.1.1.2 Sensor Records. 804.1.1.1.3 Sensor Manufacturing Screens 814.1.1.1.4 Non-conforming Material 814.1.1.1.5 Sensor Design Verification Tests 814.2 TESTING 814.2.1 Philosophy of Testing 814.2.2 Location of Testing 814.2.3 Physical Models 814.2.3.1 Engineering Development Unit (EDU) 814.2.3.2 Mass Model 824.2.3.3 Spacecraft/Sensor Mechanical Interface Simulator (TBS) 824.2.3.4 Spacecraft/Sensor Electrical Interface Simulator (TBS) 824.2.4 Math Model Requirements 824.2.4.1 Finite Element Model 824.2.4.2 Thermal Math Model 824.2.5 Structural Analyses 834.2.6 Developmental Testing 834.2.7 Acceptance and Protoqualification Testing 834.2.7.1 Random Vibration Testing 844.2.7.1.1 Acceptance Level Random Vibration Testing 844.2.7.1.2 Protoqualification Level Random Vibration Testing 854.2.7.2 Sine Vibration Testing 864.2.7.2.1 Acceptance Level Sine Vibration Testing 874.2.7.2.2 Protoqualification Level Sine Vibration Testing 874.2.7.2.3 Design Strength 874.2.7.3 Acceleration Testing 874.2.7.4 Shock Testing 884.2.7.4.2 Protoqualification Level Sensor Shock Testing 884.2.7.5 Acoustic Testing 894.2.7.5.1 Acceptance Level Acoustic Testing 894.2.7.5.2 Protoqualification Level Acoustic Testing 904.2.7.6 Thermal Testing 904.2.8 EMC/EMI Testing 904.2.9 Current Margin Testing 914.2.10 Deployment Testing 914.2.11 Outgassing 914.2.12 Requalification of Existing Designs. 914.2.13 Lifetime Testing 914.2.14 Pre-launch Validation Tests. 914.2.14.1 Sensor Pre-launch Validation Tests. 924.3 VERIFICATION 924.3.1 Standard Scenes 924.3.2 Verification Methods 924.3.3 Requirements Validation 934.3.4 Data Bases 934.3.5 External/Built-in Testing 944.3.6 Burn-in 945. PREPARATION FOR DELIVERY 945.1 PRESERVATION AND PACKAGING 945.2 MARKINGS 94
LIST OF FIGURES
Figure 3.1.3 Specification tree 18Figure 3.2.3 Partial System Internal Interfaces 31Figure 3.2.4.3.3.1. Spacecraft-Sensor Electrical Interfaces 39Figure 3.2.4.8.2. Data Transfer Interface 47Figure 3.2.4.8.2.3. Command and Data Handling Interface Topology 48Figure 3.2.6.2.1.1 Maximum PLF Inner Temperatures 55Figure 3.2.6.2.3 MLV Quasi-Static Load Factors 56Figure 3.2.6.2.5 MLV Acoustic Levels 57Figure 3.3.12.7.5.1 Allowable Transmitted Torque 72Figure 4.2.7.1.1 Random Vibration - Acceptance Levels 85Figure 4.2.7.1.2 Random Vibration - Protoqualification Levels 86Figure 4.2.7.2.2 Sinusoidal Protoqualification Test Levels 87Figure 4.2.7.4 Shock Spectrum (Q=10) 88
LIST OF TABLES
Table 3.1.1.1 GPSOS Sensor Characteristics 17Table 3.2.4.7.3.2 Worse-Case Hot and Cold Environments 44Table 3.2.4.7.6.1. Thermal Control Hardware Responsibility 45Table 3.2.6.1.1 Total Ionizing Dose Environment 52Table 3.2.6.2.5 Maximum Acoustic Levels 58Table 3.3.12.4.1 Structural Design Factors of Safety 68Table 3.3.12.4.2 Factors of Safety for Pressurized Components 69Table 4.2.7.1.1 Random Vibration - Acceptance Test Levels 84Table 4.2.7.1.2 Random Vibration - Protoqualification Levels 86Table 4.2.7.2.2 Sinusoidal Test Levels 87Table 4.2.7.5.1 Acceptance Acoustics Levels 89
This Sensor Requirements Document (SRD) sets forth the requirements for a Global Positioning System Occultation Sensor (GPSOS) of the National Polar-orbiting Operational Environmental Satellite System (NPOESS).
The GPSOS sensor has two principal functions: a) provide navigation data to the satellite and b) satisfy the Environmental Data Records (EDRs), as described below. The GPSOS sensor makes observations of navigation signals from the GPS and Russia's Global Navigation Satellite System (GLONASS) satellite constellations. The GPSOS provides six main data types:
Data types-2 through 5 are composed of signal phase, amplitude and Pseudorange at the L1 and L2 frequencies for GPS and the L1 and L2 frequency bands for GLONASS. Note: within the next 5-7 years, the GPS Block IIF may have a third frequency, designated as L5 at approximately 1140 MHz. The GPSOS sensor shall take advantage of this upgraded capability to improve the delineation of the ionosphere refraction and the navigational precision.
Two types of occultations are possible: rising and setting. A setting occultation starts when the combined orbital motions of the NPOESS satellite and one of the GPS or GLONASS satellites being tracked by the GPSOS sensor are such that the GPS or GLONASS satellite, as viewed from NPOESS satellites, drops below the NPOESS local horizontal plane and ends when the GPS or GLONASS satellite, as viewed from NPOESS, drops behind the Earth's limb. Setting occultations occur for GPS/GLONASS satellites that are in the hemisphere behind the NPOESS satellite (anti-velocity direction). A rising occultation is the inverse of a setting occultation. Rising occultations occur for GPS/GLONASS satellites in the hemisphere in front of the NPOESS satellite. Both setting and rising occultations are to be tracked by GPSOS sensor. Tracking of rising occultations requires that the GPSOS sensor be capable of rapidly locking on the GPS/GLONASS signals as they appear from behind the Earth's limb.
This document contains all performance requirements for sensor suite. This document also defines all sensor-spacecraft interfaces for the sensor suite. The contractor should use the document as the basis of a proposed sensor suite specification. The documentation listed in section 2.0 follows an approach of minimum specs and standards. The contractor may add to or revise the documents listed in section 2.0 in coordination with the government. The term "[TBD]" applied to a missing requirement means that the contractor should determine the missing requirement in coordination with the government. The term "[TBS]" means that the government will supply the missing information in the course of the contract. The term "[TBR]" means that the requirement is subject to review for appropriateness by the contractor or the government. The government may change "[TBR]" requirements in the course of the contract.
Appendix A contains a definition of the terms used throughout the document. Appendix B, NPOESS survivability requirements, is classified and, if applicable, will be made available after contract award. Appendix C is a Sensor Data Record Characteristics section presently TBR. Appendix D contains the NPOESS EDR requirements. Appendix E contains the RDRs and EDRs required for each Central and Field Terminal (TBR). Appendix F defines the acronyms and abbreviations used throughout the document. Appendix G describes Potential Pre-planned Product Improvements. Appendix H is the Verification Cross Reference Matrix (TBD).
SRDX1.3.1-1
In the event of conflict between the referenced documents and the contents of this specification, the contents of this specification shall be the superseding requirements.
SRDX1.3.1-2
In the event of a conflict involving the external interface requirements, or in the event of any other unresolved conflict, the contracting officer shall determine the order of precedence.
The requirements stated in this specification are not of equal importance or weight. The following three paragraphs define the weighting factors incorporated in this specification.
a. Shall designates the most important weighting level; that is, mandatory. Any deviations from these contractually imposed mandatory requirements require the approval of the contracting officer.
b. Should designates requirements requested by the government and are not mandatory. Unless required by other contract provisions, noncompliance with the should requirements does not require approval of the contracting officer.
d. Will designates the lowest weighting level. These will requirements designate the intent of the government and are often stated as examples of acceptable designs, items and practices. Unless required by other contract provisions, noncompliance with the will requirements does not require approval of the contracting officer and does not require documented technical substantiation.
The following documents of the exact issue shown form a part of this SRD to the extent specified herein. In the event of conflict between the documents referenced herein and the contents of this specification, see Section 1.3.1. Tailoring of documents in this section is (TBR).
SPECIFICATIONS:
Military
DOD-E-83578A General Specification for Explosive Ordnance
May 96 for Space Vehicles,
Mil-A-83577B Moving Mechanical Assemblies for Space Launch
Feb 88 Vehicles
STANDARDS:
Federal
FED-STD-209E Airborne Particulate Cleanliness Classes in Sep 92 Cleanrooms and Clean Zones
Military
MIL-STD-461D Electromagnetic Emission and Susceptibility
Jan 93 Requirements for the Control of Electromagnetic
Interference
MIL-STD-462D Measurement of Electromagnetic Interference
Jan 93 Characteristics
MIL-STD-1540C Test Requirements for Launch, Upper Stage, and
Sep 94 Space Vehicles
MIL-STD-1541A Electromagnetic Compatibility Requirements for
Dec 87 Space Systems
MIL-STD-1553B Digital Time Division Command/Response
Jan 96 Multiplex Data Bus
MIL-STD-1773B Fiber Optics Mechanization of an Aircraft
May 88 Internal Time Division Command/Response
Multiplex Data Bus
Department of Commerce/NOAA: None (TBR)
OTHER PUBLICATIONS:
Regulations
AFM 91-201 Explosive Safety Standards
7 Oct 94
EWR 127-1 Eastern and Western Range Safety Requirements
31 Mar 95
Handbooks: None (TBR)
Bulletins: None (TBR)
Other
GPS ICD 200 REV "NAVSTAR GPS Space Segment/Navigation User
C, 19 January Interface"(U)
1995 UNCLASSIFIED
GPS ICD 203, REV "NAVSTAR GPS SA/AS Requirements(U)-SECRET
B 22 Dec 1993
(Contractors requiring copies of specifications, standards, handbooks, drawings, and publications in connection with specified acquisition functions should obtain them from the contracting activity or as directed by the contracting officer.)
The following documents of the exact issue shown form a part of this SRD to the Extent specified herein. In the event of conflict between the documents referenced herein and the contents of this specification, see Section 1.3.1.
SPECIFICATIONS: None (TBR)
STANDARDS:
CCSDS 203.0-B-1 CCSDS Recommendations for Space Data System
Jan 87 Standards. Telecommand, Part 3: Data
Management Service, Architectural Definition,
Issue 1
CCSDS 701.0-B-2 CCSDS Recommendations for Advanced Orbiting
Dec 87 Systems, Networks and Data Links, Architectural
Specification
National Hazardous Materials Management Program
Aerospace
Standard (NAS)
411
Rev 2, 29 Apr 94
DRAWINGS: None (TBR)
OTHER PUBLICATIONS: None (TBR)
The following documents are for reference only and do not form a part of this specification. They are listed here because various parts of the SRD refer to them.
SPECIFICATIONS:
Military: None (TBR)
STANDARDS:
DOD 5200.28-STD Department of Defense Trusted Computer System
Mar 88 Evaluation Criteria
MIL-STD-129M Marking for Shipment and Storage Notice 1, 15
1 Jun 93 Sep 89
MIL-STD 961D DoD Standard Practice for Defense
Aug 95 Specifications, w/ Notice 1
MIL-STD-498 Software Development and Documentation
5 Dec 94
MIL-STD-882c System Safety Program Requirements
Jan 93
MIL-STD-1246C Military Standard Product Cleanliness Levels
Apr 94 and Contamination Control Program
MIL-STD-1522A Standard General requirements for Safe Design
May 84 and Operation of Pressurized Missile and Space
Systems
MIL-STD-1542B Electromagnetic Compatibility (EMC) and
Nov 91 Grounding Requirements for Space Systems
Facilities
MIL-STD-1543B Reliability Program Requirements for Space and
Oct 88 Launch Vehicles
MIL-STD-1547A Parts and Materials Program for Space and
Dec 92 Launch Vehicles
MIL-STD-1809 (USAF) Space Environments for USAF Space
Feb 91 Vehicles
TM-86-01 Technical Manual Contract Requirements
Department of Commerce
DOC Sep 95 National Telecommunications and Information Edition Administration, Manual of Regulations for Sep 95 Federal Radio Frequency Management
NOAA
S24.801 Preparation of Operations and Maintenance
2 Dec 88 Manuals
S24.806 Software Development, Maintenance, and User
30 Apr 87 Documentation
S24.809 Grounding Standards
Dec 89
NASA
PPL-21 Preferred Parts List, Goddard Space Flight
March 1995 Center (Updated May 1996)
SP-R-0 022A General Specification, Vacuum Stability
(JSC) Requirements of Polymeric Material for
9 Sep 74 Spacecraft Application
NASA Tech Memo Orbital Debris Environments for Spacecraft
100471 Designed to Operate in Low Earth Orbit
SP 8031 NASA Space Vehicle Design Criteria/Structures
1969
OTHER PUBLICATIONS:
Regulations: None (TBR)
Handbooks
DOD-HDBK-263B Electrostatic Discharge Control Handbook for
(date) Protection of Electrical and Electronic Parts,
Assemblies, Equipment
MIL-HDBK-340 Application Guidelines for MIL-STD-1540B
1 Jul 85
DOD-W-83575 Gen Spec for Wiring Harness, Space Vehicle,
Jun 96 Design and Testing
MIL-I-46058 Insulating Compound. Electrical (for Coating
Printed Circuit Assemblies)
1985 Handbook of Geophysics and Space Environments
AFM 15-111 Surface Weather Observations
1 Sep 96
Bulletins
Other
TRD for NPOESS Technical Requirements Document (TRD) for
(current National Polar- Orbiting Operational
version) Environmental Satellite System (NPOESS)
Spacecraft Payloads
IRD for NPOESS Interface Requirements Document (IRD) for
(current National Polar-Orbiting Operational
version) Environmental Satellite System (NPOESS)
Spacecraft
IORD for NPOESS Integrated Operational Requirements Document
28 Mar 96 (IORD) for National Polar Orbiting Operational
Environmental Satellite System (NPOESS)
Spacecraft Payloads
ASTME-595-93 Standard Test method for Total Mass Loss and
(current Collected Volatile Condensable Materials for
version) Outgassing in a Vacuum Environment
Attachment C AMSU-A Instrument Performance and Operation
S-480-80 Revised Specification (for the EOS/METSAT Integrated
Programs); NASA GSFC
December 1994
SYS/AMS/J0105/BAE AMSU-B Instrument System Specification (British
Aerospace)
03 Feb 1993
(Technical society and technical association specifications and standards are generally available from reference libraries. They are also available in technical groups and using federal agencies. Contact the contracting officer regarding any referenced document not readily available from other sources.)
The GPSOS sensor is one of several sensors under development by the Integrated Program Office (IPO) for utilization by POES/DMSP and NPOESS era satellite constellations. The GPSOS sensor provides real-time, on-orbit positioning, timing, and acquires data to enable ground processing yielding precise orbit determination (POD), and occultation event phase / amplitude data to within the specifications listed below. The offeror's proposal addresses each of the areas and provide rationale and supporting analysis for all deviations. The Government desires to provide early NPOESS data to users by possibly flying one or more of the GPSOS sensors on POES and DMSP. This Sensor Requirement Document (SRD) for GPSOS defines the NPOESS GPSOS sensor requirements. The NPOESS era constellation is planned to contain 3 satellites: 2 US built and 1 built by EUMETSAT.
There will be approximately 5200 occultation events daily experienced by the NPOESS constellation using the GPS and GLONASS satellite signals. The GPSOS sensor measured occultation data will support determination of atmospheric vertical profiles of: a) ionospheric electron density , and b) provide tropospheric temperature, pressure, and moisture content (when merged with other ground-based data sensor data).
The GPSOS sensor and antennas interface with the host satellite (DMSP/POES/METOP and NPOESS). There are several nadir viewing sensors on-board the satellite and the GPSOS sensors and antennas cannot interfere with DMSP/POES/METOP or NPOESS missions.
There are additional concerns regarding potential multipath effects on the GPS/GLONASS signals attributable to the host satellite structure. The GPSOS Antenna(s) design minimizes these multipath effects. Assuming a 0 dB antenna gain with GPS/GLONASS signals, the GPSOS receiver sensitivity requirement is estimated to be -130 dBm for Right Hand Circular Polarization (RHCP).
SRDG 3.1.1.1-1
Spurious multipath signals of Left Hand Circular Polarization (LHCP) shall be rejected by an additional 20 dB.
SRDG3.1.1.1-2
The GPSOS sensor developer shall work with the spacecraft contractor to determine the exact location(s) for the antenna(s).
SRDG3.1.1.1-3
The GPSOS sensor provides sensor status or housekeeping data to the spacecraft for use in the downlink. The GPSOS sensor shall have the capability to internally measure power supply voltages and temperatures to 1% accuracy.
SRDG3.1.1.1-4
For test and pre-flight sensor checkout, an auxiliary RS-422 serial port shall support direct communication with the GPSOS sensor and mechanism to retrieve mission data and sensor housekeeping data. Over this port, a technician has control of the sensor using a laptop and is able to receive mission data, command responses, and housekeeping data. See Table 3.1.1.1 Footnote (d).
SRDG3.1.1.1-5
Receiver data quality shall be sufficient to support satellite navigation (autonomous, on-board) and provide time information to the satellite, i.e. to within 100.0 nanoseconds (ns) accuracy. See the Navigation column in Table 3.1.1.1.
SRDG3.1.1.1-6
The GPSOS sensor GPS subsystem shall produce a 1 pulse per second (pps) time stamp clock signal to the satellite computer for accurate time tagging data from all sensor subsystems that is accurate to within 100 ns RMS.
SRDG3.1.1.1-7
The GPSOS sensor shall be able to operate automatically with "power on", but also be able to be reconfigured by simple ground commands, e.g. redundancy commands, changes in sampling frequencies, etc.
SRDG3.1.1.1-8
Receiver data quality shall be sufficient to support troposphere/stratospheric occultation measurement analysis. The latter involves ground based precise orbit determination using GPSOS data combined with non-NPOESS ground data (e.g., IGS) to determine the position and velocity of the NPOESS and GPS/GLONASS satellites. EDR values will be updated within 20 minutes of receipt of the data at the Central or Tactical site. The Navigation/POD and Troposphere/Stratosphere columns in Table 3.1.1.1 provide the requirements levied on the receiver associated with this analysis.
SRDG3.1.1.1-9
The GPSOS sensor contractor shall be responsible for definition of the ground based processing algorithm yielding NPOESS velocity uncertainty to less than 0.5 mm/sec and position uncertainty to less than 0.5 m.
SRDG3.1.1.1-10
Nominal channels: 5-6 channels each, for navigation both GPS and GLONASS; 8 channels for GPS occultations, and 8 channels for GLONASS occultations. A single channel shall be defined as all observables associated with a single satellite at both L1 and L2 frequencies (GPS) or both L1 and L2 frequency bands (GLONASS). Note: Within the next 5-7 years, the GPS Block II F satellites may have an additional frequency, i.e. L5 at approximately 1140 MHz. The GPSOS sensor will utilize L5 capability to improve the delineation of the ionosphere refraction and navigational precision as a GPSOS sensor Preplanned Product Improvement (P3I) capability, when available.
SRDG3.1.1.1-11
The GPSOS sensor shall support single difference occultation processing. This requires a very low short term clock drift specification (<10 mm in 50 seconds) and low phase noise close to the carrier (<0.10 degrees of phase uncertainty).
SRDG3.1.1.1-12
The GPSOS shall provide four configurable sample rates (see Table 3.1.1.1) within each altitude range: A) Troposphere from 0 km to 20 km - configurable sample rate between 10-100 Hz; B) Middle atmosphere/E-region above 20 km to 150 km, configurable sample rate between 5-20 Hz; C) Ionosphere >150 km sample rate configurable within the range of 0.5 to 5.0 Hz, (e.g. 0.5, 1.0, 2.0, 5.0 Hz) ; and D) NAV data configurable sampling rate range 1-300 seconds (e.g.1,5,10,30,60 & 300 seconds).
SRDG3.1.1.1-13
The GPSOS shall be capable of removing the effects of Selective Availability meeting all specifications when Y-code is enabled.
SRDG3.1.1.1-14
On a daily basis, > 98% of the available occultation events (rising and setting for GPS and GLONASS) shall be measured, i.e. 98% of the available occultation events within plus or minus 180 degrees of the satellite's velocity vector.
SRDG3.1.1.1-15
The GPSOS shall have the ability to perform: on-orbit inter-frequency bias calibrations, calibrate hardware induced absolute channel delays on each channel, and calibrate the interchannel bias for both GPS and GLONASS.
SRDG3.1.1.1-16
GPSOS sensor software shall be 100% fully reprogrammable by command to the satellite from the ground. The boot strap loader resides in ROM.
SRDG3.1.1.1-17
The GPSOS sensor memory shall be twice what is required to support the mission on Day #1.
SRDG3.1.1.1-18
GPSOS sensor shall be able to maintain track on occulted satellites (GPS and GLONASS) to within 5 km above the Earth’s limb (setting occultations) and acquire track within 10 km (rising occultations) above the Earth’s limb with a >90% probability.
SRDG3.1.1.1-19
The GPSOS sensor shall be compatible with "NAVSTAR GPS Space Segment/Navigation User Interface" - UNCLASSIFIED, GPS ICD 200 REV C, 19 January 1995, and "NAVSTAR GPS SA/AS Requirements (U)" - SECRET, GPS ICD 203, REV B, 22 Dec 1993.
SRDG3.1.1.1-20
There shall be no single point electronic component failure in the GPSOS sensor subsystem
SRDG3.1.1.1-21
These specifications (Table 3.1.1.1) shall be analyzed (Physical Optics - PO, Geometric Theory of Diffraction - GTD or Method of Moments - MOM, as appropriate and verified using compact range measurements on full or sub-scale model, as appropriate.
SRDG3.1.1.1-22
These analysis and corresponding compact range performance verification measurements shall serve as the basis for factory acceptance testing of the GPSOS sensor.
Table 3.1.1.1 GPSOS Sensor Characteristics
Receiver RT Navigation Navigation/POD Ionosphere Troposphere/Stratosphere
Parameter d
1. Configurable 0.10 Hz 0.10 Hz 1 Hz 100 Hz
Sample Rate
2. Carrier 3.0 mm 3.0 mm 3.0 mm 0.1 mm (L1 @ 1 sec)
Phase Precision 0.4 mm (L2 @
@ Sample Rate b 1 sec) c
3. Systematic 1.0 mm / sec 0.1 mm/sec 0.1 mm/sec 0.1 mm/sec
Carrier Phase
Drift/Accuracy
4. Carrier N/A N/A < 1.0 < 1.0
Amplitude
Stability (%
change over 60
seconds) a
5. Carrier N/A N/A < 2.0 < 2.0
Amplitude RMS
Jitter (% @ 20
msec)
6. Pseudorange 0.25 m P-code 0.3 m (dual 0.3 m threshold N/A
Position (m) 15.0 m frequency, 10 L1-L2
C/A-code sec) differential
7. Pseudorange TBS 0.01 N/A N/A
Systematic
Errors (m)
8. N/A N/A Every 10 sec N/A
Scintillation derived from
Parameters underlying
high rate
amplitude &
phase
8. Amplitude 8 bits 10 bits 12 bits 12 bits
Precision
Footnotes:
Figure 3.1.3 shows a partial specification tree for the NPOESS System.
Figure 3.1.3 Specification tree
See Section 3.1.6.2.
SRDG3.1.5.1.1-1
In the sensor off mode, no power shall be supplied to the sensor.
The sensor maintains operational modes as follows:
SRDG3.1.5.1.2-1
The sensor shall be in full functional configuration during this mode.
SRDG3.1.5.1.2-2
Data collection Mission and housekeeping data shall be collected.
SRDG3.1.5.1.2-3
Calibration Calibrations shall be done during regular operations.
SRDG3.1.5.1.3-1
Diagnostic mode shall include trouble shooting and software updates.
In the Safe Hold mode, health and status data are collected and transmitted. Mission and calibration data are not collected. Safe State - Most Components turned off, with survival heaters activated.
SRDG3.1.5.1.4-1
The Safe Hold Mode is a power conservation mode. The GPSOS sensor shall be commanded into this mode automatically by the spacecraft in the event the satellite enters an anomalous configuration or orientation as determined by the satellite computer. A power subsystem anomaly is such an event.
The C&DH will issue power conservation re-configuration commands to the sensors via the data bus that will place the sensor in a safe configuration. The return to the Operations Mode requires ground intervention.
SDRG3.1.5.2-1
The GPSOS sensor shall provide Navigational data and master clock data (Table 3.1.1.1) to the satellite computer in all modes, except the sensor off mode, as defined in Section 3.1.5.1.
SRDG3.1.5.3-1
The sensor ICD shall define Payload (Sensor) modes.
SRDG3.1.5.3-2
The ICD SAFE shall define Mode re-configuration commands.
The satellite will be transported directly to the launch base for final vehicle preparations and checkout. Final inter-segment and launch system verification tests will be accomplished prior to launch.
The GPSOS sensors will be delivered and integrated onto the specified satellite platforms.
SRDG3.1.6.1.1-1
During integration various GPSOS verification tests are required. The GPSOS sensor shall provide data interface and sensor diagnostics as described in Section 3.1.1.1. The satellite will be transported directly to the launch base where final vehicle preparations and checkout will be accomplished. Final inter-segment and launch system verification tests will be accomplished prior to launch.
The GPSOS sensor will be turned on as soon as is practical to assist in the satellite early orbit tracking and provide ephemeris data.
SRDG3.1.6.1.2-1
During launch and injection to the operational orbit, the GPSOS sensor shall be powered on unless recommended otherwise by the vendor in order to provide protection from the launch and injection environments. Specifically the GPSOS sensor can support early anomaly resolution by providing Navigational data to the Satellite and is useful for monitoring satellite vehicle status.
SRDG3.1.6.1.2-2
Satellite telemetry, which includes GPSOS navigational data, shall be transmitted to ground monitoring stations to be used to the extent practicable during the injection phase.
SRDG3.1.6.1.2-3
After insertion into its operational orbit and separation from the launch vehicle, appropriate deployments shall be initiated by memory command. Early orbit check-out will be conducted at the NPOESS primary SOC in Suitland, MD.
The NPOESS satellite will operate in a near circular, sun-synchronous orbit. The nominal orbit for the satellite is 833 km altitude, 98.7 (TBR) degree inclination. The orbit will be a "precise" orbit (i.e., altitude maintained to TBS km, nodal crossing times maintained to 10 minutes throughout the mission lifetime ) to minimize orbital drift (precession). NPOESS must be capable of flying at any equatorial node crossing time. However, the nominal configuration is with the satellite orbits equally spaced, with 0530 and 1330 nodal crossing times for the U.S. Government satellites and 2130 for the METOP satellite.
The sun Beta angle, , is the angle between the solar vector (i.e. the satellite-sun line) and the orbit plane. For sensor thermal design purposes, the range of for the NPOESS missions is ± 90 degrees. The satellite will maintain the sun on the appropriate side of the satellite to meet the ‘all beta’ requirement. Sensor suite design allows for approximately a 5 degree infringement of sun on the cold space side of the satellite in the case of a noon or midnight orbit.
The GPSOS is also a sensor with early flight opportunity potential on DMSP and POES. The above information describing NPOESS satellite orbital parameters is intended as guidance to the Contractor.
The initial on-orbit period is devoted to a complete satellite checkout and the calibration and performance verifications of the payload(s). The satellite and payload performance verification tests may be repeated at appropriate times during the operational phase of the mission.
SRDG3.1.6.2.3-1
The GPSOS sensor shall be capable of operating for 21 days with a goal up to 60 days without additional commands.
SRDG3.1.6.2.3-2
On-orbit storage of occulting and non-occulting satellite data for transmission to the satellite C3 subsystem shall be at variable rates dependent on the altitude of the GPS/GLONASS signal path above the Earth's surface (the "ray tangent altitude"). The GPSOS sensor sample rates are selectable by ground control commands selectable in each band between the defined limits in four atmospheric regimes/vertical profiles: a) troposphere -- surface to 20 km @ 10-100 Hz; b) stratosphere to E region ionosphere-- 20 km to 150 km @ 5-20 Hz; ionosphere 150 km to 1000 km @ 0.5 to 5.0 Hz) ; and navigation @ 1.0 - 0.03 Hz.. Data from these different regions is used in different ways during ground processing to produce different products as described below.
SRDG3.1.6.2.3-3
The GPSOS shall provide continuous satellite navigational data real-time 3D position and velocity to an accuracy of better than 15.0 meters (RMS) and 1.0 m/sec with a >99% probability referenced to GPS or GLONASS time (good to 100 ns) to the satellite system flight computer. In addition, the GPSOS should perform on-board calculation of scintillation parameters using the observed signal amplitude and phase of occulted GPS/GLONASS satellites. These scintillation parameters are stored for transmission to the ground together with the raw observables. It is important to note that while the raw observables are reported at variable rates, as described above, the scintillation parameter calculations are based on the highest internal data rate. The calculations are done on board to reduce the required telemetry rate.
SRDG3.1.6.2.3-4
With the exception of the scintillation parameters, processing of the GPSOS data into Environmental Data Records (EDRs) is performed on the ground. Two classes of EDRs are derived from the GPSOS data: tropospheric/stratospheric and Ionospheric. Both classes of EDR shall be produced in near real-time (i.e., within 20 minutes of receipt of the data at the Central or Tactical site). The GPSOS sensor contractor is responsible for producing EDRs from the GPSOS sensor RDRs.
Calculation of tropospheric/stratospheric EDRs (i.e., atmospheric temperature and water vapor profiles) involves determination of the atmospheric contribution to the observed GPS/GLONASS signal Doppler. However, prior to this determination, the observed signals are corrected for any clock errors associated with the GPSOS reference oscillator or the GPS/GLONASS satellite clocks. Clock errors within GPSOS are removed by use of a reference satellite.
SRDG3.1.6.2.3-5
When observing an occultation, the GPSOS shall simultaneously select and track a non-occulted reference satellite at the same higher rate as the occulted satellite.
This allows the use of the single-differencing data processing technique to correct GPSOS clock errors during ground processing. Clock errors in the GPS/GLONASS satellites are of one of two types: slow drift in the on-board atomic clocks (present for both GPS and GLONASS) and the intentionally induced errors associated with selective availability (GPS only). Apart from the effects of Selective Availability (S/A), the GPS and GLONASS satellite clocks are believed to be stable enough to allow accurate determination of EDRs without any corrections. With regard to the errors induced by S/A, other occultation sensors, i.e. GPS/ MET has used data from ground-based GPS receivers in a double-differencing scheme to make the needed corrections.
Given the observations after correction for clock errors, the atmospherically induced Doppler is determined by subtracting the Doppler due to relative GPS/GLONASS-NPOESS satellite motion from the observed Doppler. Determining the Doppler due to satellite motions in turn requires high precision orbit determination for both GPS/GLONASS satellites and for NPOESS. High accuracy GPS and GLONASS ephemeris are obtained on the ground through processing of data from ground-based (non-NPOESS) GPS and GLONASS receivers, i.e. the IGS system. The high accuracy GPS/GLONASS ephemeris are then used together with GPSOS observations of non-occulted satellites to determine high accuracy ephemeris for NPOESS.
SRDG3.1.6.2.3-6
In order for the precise ephemeris to be determined, the position of the GPSOS antenna(s) phase center(s) relative to the satellite center-of-mass shall be accurately known to < 1.0 cm.
In addition, an accurate map of antenna amplitude and phase as a function of look angle are known. With the high accuracy ephemeris of all satellite known, it is then possible to remove the orbital motion induced contribution to the signal Doppler and determine the atmospheric contribution. The atmospherically induced Doppler is related to the amount of bending of the ray path between NPOESS and the occulted satellite. The bending, after a dual frequency correction for the effects of the ionosphere along the ray path, is in turn related to the atmospheric refractivity profile. This profile will be obtained by applying the appropriate data inversion scientific algorithms. The refractivity profiles may be converted into atmospheric temperature and water vapor profiles.
Determination of electron density profiles and slant path TEC from GPSOS data should involve one of two techniques, or some combination thereof. A single frequency method based on ray path bending is possible which involves considerations similar to those described above for the troposphere/stratosphere (correction of clock errors and subtraction of geometric Doppler). Alternately, a dual frequency scientific algorithm exists whereby line-of-sight Total Electron Content (TEC) observations obtained from the differential Pseudorange and phase are converted into a vertical electron density profile. Occultations which occur off to the side of the NPOESS satellite (out-of-track occultations) provide useful information for NPOESS end users, but can not be processed into vertical electron density profiles due to the substantial change in tangent point location during the occultation. Slant path TEC observations from these types of occultations should be produced as part of the GPSOS ground processing. Accurate measurement of TEC requires knowledge of the inter-frequency bias of both the GPSOS receiver and the transmitters on the GPS and GLONASS satellites.
SRDG3.1.6.2.3-7
In addition to vertical electron density profiles, the GPSOS data shall also be used to produce observations of the total electron content (TEC) above the NPOESS satellite. Data from non-occulted satellites is used for this purpose.
SRDG3.1.6.2.3-8
In addition to analysis associated with occultations, the accuracy of the NPOESS ephemeris shall be improved via ground processing to support geolocation and orthorectification of data from NPOESS imaging sensors. To support NPOESS imager and sounding sensors, the GPSOS data provides on-orbit ephemeris better than 15.0 meter (RMS) position accuracy.
SRDG3.1.6.2.4-1
The GPSOS sensor shall be equipped with an RS422 serial port that permits direct access to the GPSOS sensor housekeeping, power supply status-temperature and voltage and communications link. This port permits full access and control of the GPSOS sensor using a laptop in order to receive data, command responses, and verify/measure sensor status and subsystem interfaces.
SRDG3.1.6.2.4-2
During flight operations the mission controllers shall be able to monitor the GPSOS sensor status and functions. For all diagnostic GPSOS sensor parameters are identified as well as specification of parameter range tolerances, sensor anomalies, fault diagnostics, failure modes. The GPSOS sensor operates with "power on", but also be reconfigurable by simple ground commands, e.g. redundancy commands, changes in sampling frequencies, etc.
The GPSOS sensor contractor is responsible for the following elements of the GPSOS system:
SRDG3.1.6.2.5-1
The GPSOS sensor contractor shall be responsible for the GPSOS spaceflight hardware and software.
SRDG3.1.6.2.5-2
The GPSOS sensor contractor shall be responsible for the Calibration of the GPSOS receiver and antenna(s).
SRDG3.1.6.2.5-3
The GPSOS sensor contractor shall be responsible for Ground based performance verification of sensor performance and acceptable multipath levels as verified by compact rage test on a full scale satellite (mock up) and GPSOS sensor.
SRDG3.1.6.2.5-4
The GPSOS sensor contractor shall be responsible for development of scientific algorithms that will be used for ground processing in the IDPS. When applied, the algorithms should be capable of providing ionospheric EDR's. RDR's shall be of sufficient accuracy and precision to allow processing of tropospheric/stratospheric EDR's (temperature or humidity) meeting the clear air accuracy defined for the CrIMSS sensor.
SRDG3.1.6.2.5-5
The GPSOS sensor contractor shall be responsible for Ground processing software for refining the GPSOS navigation data accuracy to the level required to support NPOESS imagery geolocation
SRDG3.1.6.2.5-6
The GPSOS sensor contractor shall be responsible for the following elements of the GPSOS system:
1) Ground processing software and auxiliary ground data sources needed to convert SDRs into ionospheric, troposphere, and stratospheric EDRs.
2) Each GPSOS sensor identifies itself with a unique serial number and ROM code version number every time it boots.
The GPSOS sensor makes observations of navigation signals from the GPS and GLONASS satellite constellations. The GPSOS provides six main data types:
SDRG3.2.1.1-1
In addition to the GPSOS related EDRs the sensor shall provide satellite navigational data (see Section SRDG Table 3.1.1.1.)
Definitions of "primary" and "secondary" EDRs appear in the glossary and are replicated below.
The GPSOS SRD levies on the GPSOS contractor only those EDR attributes for which the sensor has primary EDR scientific algorithm responsibility (primary EDR). Requirements for the sensor to provide data as a secondary input to an EDR scientific algorithm assigned to another sensor (secondary EDR) are (TBR) and will be established 60 days prior to SRR. Though not yet specified as requirements, the secondary EDRs are listed in the SRD to encourage investigation of secondary EDR capabilities in the GPSOS sensor design. Note also that the GPSOS sensor contractor identifies specifications for any data required from other sources in order to meet the attribute requirements of the primary EDR assigned to the GPSOS sensor.
EDR attributes for which a sensor contractor has been assigned primary sensor and scientific algorithm development responsibility. The scientific algorithm may or may not require the use of additional data from other than the primary sensor.
EDR attributes for which a sensor may provide data as a secondary input to an EDR scientific algorithm assigned as a primary EDR to another sensor contractor.
SRDG3.2.1.1.2-1
The environmental data records (EDRs) shall meet the requirements specified in this GPSOS SRD.
SRDG3.2.1.1.2-2
The primary EDRs shall meet the threshold levels as a minimum.
SRDG3.2.1.1.2-3
The modifications and clarifications of EDR requirements in this section shall take precedence over any conflicting requirements or statements in Appendix D of this SRD, the TRD, and the IORD.
EDR requirements are specified by a general definition of the required data content, the units for the reported data, and a set of attributes. These attributes fall into four categories: (1) those that further define data content in a precise, quantitative manner, (2) those that constrain the quality of the data to be provided, (3) those that constrain the reporting frequency for the EDR, and (4) the timeliness of EDR delivery to users. The attributes addressing data content are horizontal and vertical cell size, horizontal and vertical reporting interval, and horizontal and vertical coverage. The attributes addressing data quality are measurement uncertainty, measurement accuracy, measurement precision, long term stability, and mapping uncertainty. The primary attributes addressing reporting frequency are maximum local average revisit time and maximum local refresh. All of these attributes apply to data products, not to sensor performance characteristics, and are defined in the Glossary. The EDR requirements format is to address the data content attributes first, then the data quality attributes, and finally the reporting frequency attributes. The timeliness requirement is the same for all EDRs, and is specified as a global requirement . General EDR requirements fall into two classes: (a) explicit requirements on the EDR content, quality, refresh, and timeliness, and (b) requirements to be derived by the contractor based on requirements for other EDRs. The explicit and application-related requirements are specified below.
If a derived requirement conflicts with an explicit requirement and/or another derived requirement, the most stringent requirement shall be satisfied.
SDRG3.2.1.1.2.2-1
Unless otherwise specified, attribute values shall be interpreted as upper bounds anywhere in the area where measurements are obtained, including the edge of the measuring sensor field of regard. A threshold or objective is "met" or "satisfied" if the system performance value is less than or equal to the specified value.
Unless otherwise specified, a percentage appearing as a value for an attribute is to be interpreted as the percentage of the true value of the attribute. For any attribute where a percentage and a numerical value are specified, the greater of the two is the requirement.
Vertical height is measured either by atmospheric pressure or by height above the earth's surface. A value of zero km for height refers to the earth's surface. Negative values of height refer to depth below the earth's surface (land or water).
The attribute numbering is consistent with Appendix D except for the preface letter which indicates it is a unique requirement in this GPSOS SRD. Any difference in these GPSOS SRD attributes take precedence over Appendix D values as they reflects an intentional requirements allocation to this sensor.
The ionosphere is that portion of the Earth's upper atmosphere which is composed of electrically charged particles (electrons and various ions). A complete vertical electron density profile would extend from the D and E regions at altitudes between 60 and 150 km, through the F region within which the electron density reaches a maximum value nominally between altitudes of 250-350 km, through the topside up to 3,000 km, and into the plasmasphere. The Air Force requires global ionospheric specification to meet a number of operational needs. Electron density profile measurements, to include measurements of various important parameters associated with a complete profile, are required as inputs to and to augment the outputs of operational ionospheric models. The GPSOS sensor data will be used to produce slant path (NPOESS to GPS/GLONASS satellite) total electron content (TEC) measurements for all occultation events. In addition, for occultation events which occur in viewing directions close to the spacecraft orbit plane (within TBR degrees of the velocity or anti-velocity vectors), the GPSOS sensor data will be used to produce vertical electron density profiles for altitudes below the NPOESS altitude. Profile measurements above the NPOESS altitude are not required. However, the GPSOS sensor data from non-occulting satellites will be used to produce slant path TEC observations of the topside/plasmasphere.
Units:
electron density: cm-3
HmF2: km
TEC: 1016/m2 = 1 TEC unit
Para. No. Thresholds Objectives
G40.8.5-1 a. Horizontal Reporting (TBD) based 100%
Interval on >98% of
all possible
occultation
events.
G40.8.5-2 b. Vertical Reporting 10 km within 5 km
Interval 100 km of E/F
(Applicable to profile peaks, 20 km
only)) elsewhere
c. Horizontal Cell Size
G40.8.5-3 1. 0-30° latitude (TBD) 100 km
G40.8.5-4 2. 30-50° latitude (TBD) 250 km
G40.8.5-5 3. 50-90° latitude (TBD) 50 km
G40.8.5-6 d. Vertical Cell Size 10 km within 5 km
(Applicable to profile only) 100 km of E/F
peaks, 20 km
elsewhere
G40.8.5-7 e. Horizontal Coverage (TBD) based (TBD)
on >98% of
all possible
occultation
events
G40.8.5-8 f. Vertical Coverage (TBD) (TBD)
g. Measurement Range
G40.8.5-9 1. Density profile 3x105-107 104-107cm-3
cm-3
G40.8.5-10 2. Slant path TEC 3-1000 TEC 1-1000 TEC
units (TBR) units
h. Measurement Uncertainty
G40.8.5-11 1. Density profile greater of 104 cm-3
20% or 3 x105
cm-3 (TBR)
G40.8.5-12 2. HmF2 20 km 5 km
G40.8.5-13 3. HmE (TBD) (TBD)
G40.8.5-14 4. Slant path TEC 3 TEC units 1 TEC unit
G40.8.5-15 i. Maximum Local Average (TBD) (TBD)
Revisit Time
3.2.1.1.3.1.2 Ionospheric Scintillation
Temporal and spatial fluctuations in ionospheric electron density lead to fading or disruption of transionospheric communication and radar signals, a phenomenon known as scintillation. The extent of the effect depends on the relative motion of the ionosphere and the signal source, the frequency of transmission, and the amplitude and spectral characteristics of the ionospheric fluctuations. Direct measurements of scintillation in terms of amplitude and phase fluctuation indices S4 and sigma-ø are required. Spectral analysis of amplitude and phase measurements is desirable as well.
Units:
S4: dimensionless
sigma-ø: radians
Para. Thresholds Objectives
No.
G40.8.11- a. Horizontal Cell Size (TBD) 50 km
1
G40.8.11- b. Horizontal Coverage (TBD) (TBD)
2
c. Measurement Range
G40.8.11- 1. S4 0.1-1.5 (TBD)
3
G40.8.11- 2. sigma-ø 0.1-20 radians (TBD)
4
d. Measurement Uncertainty
G40.8.11- 1. S4 0.1 (TBD)
5
G40.8.11- 2. sigma-ø 0.1 radian (TBD)
6
G40.8.11- e. Local Time Range (TBD) (TBD)
7
3.2.1.1.3.2 Secondary GPSOS EDRs
GPSOS secondary EDR requirements are EDR attributes for which a sensor may provide data as a secondary input to an EDR scientific algorithm assigned as a primary EDR to another sensor contractor. These EDRs are regarded as secondary, because the scientific algorithms and the inter-relationship to other NPOESS sensors are TBS items. Following is a listing of secondary EDRs for the GPSOS.
D. Pressure Profile
3.2.1.1.3.3-1
The GPSOS sensor contractor shall identify any constraints on the relationships between the GPSOS and other co-located satellite sensors that are entailed by the contractor's algorithms for GPSOS primary EDRs. Such constraints might include, for example, relative pointing knowledge, relative pointing accuracy, synchronization. Based on this information and the corresponding information from other sensor development contractors, the government may impose modified or additional requirements on the GPSOS sensor and/or other sensor suites. (See Sec. SRDG3.2.2)
Since RDRs are processed into EDRs, RDRs are considered to have met their requirements when they are of an appropriate format, completeness, and quality to be adequately processed into their associated EDRs.
SRDG3.2.1.1.4-1
The GPSOS contractor shall be responsible for generating operational RDRs.
SRDG3.2.1.1.5-1
The GPSOS sensor navigational data (Table 3.1.1.1) shall help provide knowledge of all other, co-located payload sensor Line-of-Sight (LOS). The GPSOS provided navigational data (Table 3.1.1.1) will allow the Earth location of the all other satellite co-located sensor and their associated data in geodetic latitude and longitude to be corrected for altitude within the accuracy specified for each EDR in Appendix D.
SRDG3.2.1.1.6-1
The contractor shall provide EDR scientific algorithms.
SRDG3.2.1.1.6-2
The EDR scientific algorithms shall, when used on GPSOS data, provide EDRs that satisfy NPOESS requirements.
SRDG3.2.1.1.6-3
The contractor shall also identify use of any auxiliary data. The government's Operational Algorithm Teams (OATs), may also recommend science algorithms. These teams have contributed to the definition of the sensor requirements of Section 3. The OATs may also provide advisory information on GPSOS functional and calibration requirements.
SRDG3.2.1.1.6-4
The performance of the scientific EDR algorithms delivered by the GPSOS sensor contractor shall meet EDR thresholds and be no worse than the performance of algorithms utilized for current (TBR) operational data products for these EDRs, if such operational products exist.
SRDG3.2.1.1.6-5
The contractor shall identify and quantify any EDR performance degradation resulting from the lack of availability of any data base or other ancillary data.
The government considers the SDR and EDR algorithms adopted, adapted, or developed by the GPSOS contractor to be scientific, rather than operational, algorithms. The GPSOS contractor is not responsible for identifying or developing operational SDR and EDR algorithms for the GPSOS. (Any operational algorithms necessary for the generation of RDRs will ultimately be the responsibility of the GPSOS contractor, and the operational code implementing these algorithms will be part of the required flight software. This statement applies to the post-downselect phase, i.e. Post-PDR, of the GPSOS program.)
SRDG3.2.1.1.7-1
The scientific SDR and EDR algorithms delivered by the GPSOS contractor shall be convertible into operational code that is compatible with a 20 minute maximum processing time at either the DoD Centrals or DoD field terminals for the conversion of all pertinent RDRs into all required EDRs for the site or terminal, including those based wholly or in part on data from other sensor suites. The intent of this requirement is to preclude scientific algorithms that are so computationally intensive that any foreseeable implementation would stress or exceed the time available for delivery of EDRs in an operational environment. The GPSOS sensor contractor is to assume that the GPS Ground net data, i.e. IGS, is made available within the 20 minute maximum processing time as Government Furnished Information - GFI. The GPSOS contractor is to identify to the Government the IGS data input format requirement.
SRDG3.2.1.1.7-2
The contractor shall validate the requirement that scientific algorithms be convertible to operational code subject to the constraint specified in SRDG3.2.1.1.7 is (TBR).
SRDG3.2.1.1.7-3
The availability of any inputs required from data bases or other ancillary sources to generate data products shall also be adequate to allow EDRs to be generated at the DoD Centrals and DoD field terminals within the time constraint specified in 3.2.1.1.7-1.
SRDG3.2.1.1.8-1
The GPSOS shall support links to the GPS and GLONASS satellite constellations, in accordance with GPS-ICD200, GPS-ICD 203, and GPS-ICD 207.
SRDG3.2.1.3-1
The GPSOS sensor shall provide a timing reference (accurate to within 100ns) and satellite ephemeris information (position to within 15 m uncertainty in-track, cross-track and NADIR direction and velocity to with 1m/sec) supporting 60 day autonomous satellite operation. See section 3.1.1.
SRDG3.2.1.4-1
A single, interchangeable GPSOS sensor data format shall conform to the POES/DMSP/METOP system format and data rate (TBS).
SRDG3.2.1.4-2
For NPOESS satellites, the sensor shall conform to the Consultative Committee for Space Data Systems (CCSDS) packetization per the (TBS) real-time interface specification and the (TBS) stored-data interface specification.
SRDG3.2.1.4-3
If data compression techniques are used in stored data retrieval, the compression shall be lossless.
SRDG3.2.1.5-1
The time code data signals for the satellite shall be derived from the GPS and GLONASS navigational sensors, (see Sections 3.1.1 and Section 3.1.7)
SRDG3.2.1.5-2
The GPSOS shall provide to the satellite a frame sync and time code data signals to the Payloads or Subsystems via the satellite Data Bus (1553 data bus or 1773 data bus) using a BC to RT Broadcast message as described in MIL-STD-1553, Notice 2.
SRDG3.2.1.5-3
The format of the vehicle time code words shall be based on the use of the GPS UTC time representation.
SRDG3.2.1.5-4
As a baseline, on-board absolute correlation of time shall be within 100 ns.
SRDG3.2.1.5-5
Time representation shall be transmitted over the 1553 data bus or 1773 data bus once per second.
SRDG3.2.1.5-6
Time representation shall correspond to the time valid of the rising edge of the time-of-day pulse.
SRDG3.2.2.1-1
The GPSOS sensor shall provide master mission clock data to the main satellite computer (See Section SRDG3.1.1, SRDG3.2.1.1.2, and Section SRDG3.2.1.7).
SRDG3.2.2.2-1
The GPSOS sensor shall provide satellite master mission clock data and navigational data to the main satellite computer, See Section SRDG3.1.1, SRDG3.2.1.1.2 and SRDG3.2.1.7.
The GPSOS sensor must interface to potentially four satellites, including: DMSP, POES, METOP, and NPOESS as well as GPS (ICD-200, ICD-203, and ICD-207) and GLONASS as the sources of the occultation signals.
- DMSP and POES TBS
- NPOESS (GPSOS SRD) and METOP - TBS
- GPS (ICD 200, ICD 203, and ICD 207) and GLONASS (TBS)
The system interfaces relevant to the sensors are depicted in Figure 3.2.3 below.
Figure 3.2.3 Partial System Internal Interfaces
Weight, power, volume and data rates described herein are nominal values (with contingency) which were developed during initial studies at the Integrated Program Office. All values are defined as: TBR, indicating that specific allocations are negotiable. It is presently planned that definitive allocations will be defined by the IPO, in consultation with sensor contractors, by the time of the SRR. In the interim, contractors should keep in mind that relaxation from nominal allocations will only be possible if changes are consistent with the requirement to accommodate the full NPOESS payload suite of instruments on a spacecraft which can be placed into a nominal 833 Km orbit by an EELV class launch vehicle.
The following constraints are based on initial allocations from the NPOESS notional baseline. These constraints are expected to be further refined during the initial contract efforts. The following numbers include all margins assigned to the GPSOS sensor.
SRDG3.2.4-1
Mass (kilograms-kg) of the GPSOS sensor shall be less than or equal to 9 kg total: Receiver /Processor: 4 kg, (TBR) oscillator: 2 kg (TBR), Antenna(s): 3 kg (TBR)
SRDG3.2.4-2
Power (watts) of the GPSOS sensor shall be less than: 13 watts (TBR)
SRDG3.2.4-3
The GPSOS sensor shall conform the following size restrictions: Dimensions (cm) of the GPSOS sensor: Receiver/Processor: 26 cm X 24 cm X 13 cm (TBR); Oscillator: 18 cm X 11 cm X 8 cm (TBR); and antenna (s): 14 X 14 X 2 (TBR). Components mounted internal to the spacecraft bus (TBS).
SRDG3.2.4-4
The GPSOS shall have a nominal data rate of 20 Kbps (Min) to 80 Kbps (Max) to the spacecraft (TBR).
Continued in File GPSOS-B.DOC