avigation and ntegrity utonomous atellite avigation...

S T A T E M E N T

O F W O R K

document title/ titre du document

AVIGATION AND NTEGRITY UTONOMOUS ATELLITE AVIGATION YSTEM

prepared by/ reference/réference issue/édition 3 revision/révision 6 date of issue/date d’édition 23-01-2006 status/état Issue Document type/type de document Statement of Work Distribution/distribution

préparé par

a ESTEC

Keplerlaan 1 - 2201 AZ Noordwijk - The Netherlands Tel. (31) 71 5656565 - Fax (31) 71 5656040

GSP_SoW 3.6.doc

Navigation and Integrity Autonomous Satellite Navigation System issue 3 revision 6 -

page ii of iv

A P P R O V A L

Title Navigation and Integrity Autonomous Satellite Navigation System titre

issue issue

3 revision revision

6

author auteur

date date

23-01-2006

approved by Activity TEB approuvé by

date date

23-01-2006

C H A N G E L O G

reason for change /raison du changement issue/issue revision/revision date/date

C H A N G E R E C O R D

Issue: 3 Revision: 6

reason for change/raison du changement page(s)/page(s) paragraph(s)/paragraph(s)


page iii of iv

T A B L E O F C O N T E N T S

1 INTRODUCTION ......................................................................................................................1 1.1 Scope..................................................................................................................................................1 1.2 Applicable Documents .......................................................................................................................2 1.3 Reference Documents ........................................................................................................................2 1.4 Acronyms ...........................................................................................................................................3

2 BACKGROUND AND OBJECTIVES .......................................................................................5 2.1 Background ........................................................................................................................................5 2.2 Objectives...........................................................................................................................................5

3 TASKS AND DEVELOPMENT LOGIC.....................................................................................8 3.1 Scope of activities ..............................................................................................................................8 3.2 Definition Phase (General Tasks) ......................................................................................................9 3.3 Deliverables of the Definition Phase .................................................................................................9 3.4 Detailed Tasks of the Definition Phase............................................................................................10 3.5 SW Tool Implementation, Test Definition and Execution Phase, (General Tasks) ........................15 3.6 Deliverables of the SW Tool Implementation Phase .......................................................................16 3.7 Detailed Tasks of the SW Tool Implementation Phase ...................................................................17 3.8 Intermediate Experimentation Phase (General Tasks).....................................................................18 3.9 Deliverables of the Intermediate Experimentation Phase ................................................................18 3.10 Detailed Tasks of the Intermediate Experimentation Phase ............................................................19 3.11 Final Experimentation Phase (General Tasks).................................................................................21 3.12 Deliverables of the Final Experimentation Phase ............................................................................21 3.13 Detailed Tasks during the Final Experimentation Phase .................................................................22

4 MANAGEMENT......................................................................................................................23

TECHNICAL APPENDIX A (TECHNICAL REQUIREMENTS) ...................................................25

TECHNICAL APPENDIX B (ECSS-E-40 TAILORING) ..............................................................28

TECHNICAL APPENDIX C (TECHNICAL FEATURES AUTONOMY-RELATED EXISTING IN THE GPS SYSTEM AND FORESEEN FOR THE GALILEO SYSTEM)........................................34

TECHNICAL APPENDIX D (OBSERVABLES FOR THE ON-BOARD OD&TS PROCESS) ....41

TECHNICAL APPENDIX E (ON BOARD ORBIT DETERMINATION PROCESS) .....................67


page iv of iv

TECHNICAL APPENDIX F ON BOARD CLOCK DETERMINATION PROCESS......................76

TECHNICAL APPENDIX G (ISL LINKS PHYSICAL DEFINITION)............................................85

TECHNICAL APPENDIX H (GROUP DELAY CALIBRATION)..................................................91


page 1 of 101

1 INTRODUCTION

1.1 Scope The proposed study will assess the feasibility, preliminary system definition and performance for a Global Satellite Navigation System, targeting very stringent accuracy requirements as well as a significant level of satellite autonomy, beyond the specifications of the Galileo System, currently under development by the European Space Agency.

This document describes:

The activity development logic, in terms of activity phases, with their respective tasks and deliverables. Four different project phases are defined and described within the document, namely the:

Definition Phase. SW Tool Implementation, Test Definition and Execution Phase. Intermediate Experimentation Phase. Final Experimentation Phase.

The project specific management requirements, including schedule and reporting aspects

Finally the document contains:

One applicable appendix on technical requirements (appendix A)

One applicable appendix on general SW requirements (ECSS-E40 tailored) (appendix C)

One reference appendix describing the technical autonomy-related features existing in the GPS System and those foreseen for the Galileo System (appendix D)

Four reference appendixes (appendixes E, F, G and H) which should be considered by the

Bidder as concrete technical guidelines describing a certain orientation of the design. These appendixes aim merely to define a starting point for the development, and to prove its feasibility. The critical assessment and consolidation of these inputs during the activity development, could lead to deviations from the original guidelines, either enhancing system performances or reducing system complexity.


page 2 of 101

1.2 Applicable Documents

1. ECSS-E-40 Part1B " Space engineering - software" and Part2B " DRDs" as tailored in Appendix C

1.3 Reference Documents

1- Robert Wolf: Satellite Navigation, GPS, GLONASS, Galileo, Orbit Determination, Orbit Estimation, Orbit Simulation, Inter-satellite Links, Onboard Ephemeris Determination, Integrity Monitoring. (http://137.193.200.177/ediss/wolf-robert/inhalt.pdf)

2- “J. Hammesfahr, A. Hornbostel, J. Hahn, H. L. Trautenberg, B. Eissfeller, R. Wolf, H.

Malthan, P. Souty, P.Tavella, W.Shafer: Inter-satellite Ranging and Autonomous Ephemeris Determination for Future Navigation Systems.

3- María Dolores Laínez Samper: Galileo Test Bed V1 Orbit Determination and Time

Synchronization Computation Performance Assessment - Detailed Processing Model Volume 1: Pre-Processing and Validation. GT-DS-GMV-TC-0123

4- María Dolores Laínez Samper: Galileo Test Bed V1 Orbit Determination and Time

Synchronization Computation Performance Assessment - Detailed Processing Model Volume 2: OD&TS. GT-DS-GMV-TC-0123

5- Kenneth R. Brown: The Theory of the GPS Composite Clock, proc. ION-GPS, 1991, pages

221-241

6- D.R. Cox, H.D.Miller, The theory of stochastic processes, Science Paperbacks Chapman and Hall, London 1965, Cap. 2,5

7- J. Hahn, S. Bedrich: Common view, Clock synchronization of remote atomic clocks using

GPS and PRARE onboard ERS2, proc 10th European Frequency and Time Forum, Brighton UK, 1996, pp. 393-398

8- Michael P. Scardera: The NAVSTAR GPS Master Control Station’s KAlman Filter

experience, Flight Mechanics / Estimation Theory Symposium 1990, NASA conference proceedings, CP 3102, 1991


page 3 of 101

1.4 Acronyms EDDN External Data Dissemination Network ERP Earth Rotation Parameters ESA European Space Agency G/S Ground Segment GACF Ground Assets Control Facility GCS Ground Control Segment GLONASS Global Navigation Satellite System (Russian) GMS Ground Mission Segment GNSS Global Navigation Satellite System (generic) GPS Global Positioning System GSP General Studies Programme GSS Galileo Sensor Station GST Galileo System Time ISL Inter Satellite Links ITRF International Terrestrial Reference Frame LEO Low Earth Orbit MCF Mission Control Facility MDDN Mission Data Dissemination Network MEO Medium Earth Orbit MGF Message Generation Facility MKMF Mission Key Management Facility MNE Monitoring Network Equipment MSF Mission Support Facility MUCF Mission Uplink Control Facility NASA National Aeronautics and Space Administration ODTS Orbit Determination and Time Synchronization OSPF Orbit and Synchronization Processing Facility PRSKMF Public Regulated Service Key Management Facility PTF Precise Timing Facility S/C Spacecraft S/S Space Segment SKMF Satellite Key Management Facility SPF Satellite Processing Facility SPR Software Problem Report SRP Solar Radiation Pressure SVN Space Vehicle Number SW Software TWTT Two Way Time Transfer


page 4 of 101

ULS Uplink Station UTC Universal Time Coordinated VSAT Very Small Aperture Terminal WAN Wide Area Network


page 5 of 101

2 BACKGROUND AND OBJECTIVES

2.1 Background This study is intended a valuable input for improving present Navigation Systems and future evolutions of GNSS Systems (e.g. Galileo II) The Galileo Satellite Navigation System currently under development by European Space Agency, is intended to provide a significantly improved performance level, in terms of accuracy, integrity and continuity when compared with existing Systems. Nevertheless current performance objectives are on one hand not sufficient for a certain number of highly demanding applications, e.g. absolute surveying (not differential technology based); and on the other hand have yielded to a considerable level of complexity and dependability on the deployment of Ground Segment infrastructure, mostly in terms of tracking network (Galileo Sensor Stations,(GSS)), mission uplink network (Uplink Stations (ULS)) and Mission Data Dissemination Network. Despite these current difficulties, performance targets for future Global Navigation Satellite System have to be more ambitious, while increasing or maintaining System availability, but reducing dramatically the dependability on Ground Segment assets. All these targeted improvements, are very challenging, for the existing and mature technology, as applied within the development of the Galileo Satellite Navigation System. Alternative and innovative technologies and methods, in the navigation area, could be the key to fulfil these more demanding requirements.

2.2 Objectives The objectives of this activity are to investigate alternative, innovative technologies and methods in the navigation area, with the view of bringing, as a minimum, the following benefits on current Systems:

Enhanced satellite autonomy. Reduced G/S infrastructure, in terms of tracking network and uplink stations Satisfy severe security constrains, in terms of geographical location of the G/S facilities. Enhanced accuracy for the orbit and clock navigation data Higher refresh rate of navigation data Reduced operational cost


page 6 of 101

In view of the above objectives, the Contractor shall investigate, as a minimum, the following technologies and methods:

Inter-satellite links ranging signals Inter-satellite ranging measurements processed in the Ground Segment (G/S) On board orbit and clock determination Inter-satellite communication links, to exchange between spacecrafts navigation, telemetry,

telecommand and ranging data In the above defined high level frame this Study targets two different scenarios, namely:

The first scenario, named as “Galileo-like constellation” analyzes the benefits of ISL, when navigation processing is either entirely or partially located on board each spacecraft, in a Galileo-like constellation.

The second scenario, named as “Galileo-like + LEO constellation” analyzes the benefits of

ISL, when navigation processing are either entirely or partially located on board each spacecraft, in a Galileo-like scenario in which a few LEO satellites are incorporated for calibration and monitoring purpose. In this Study the Galileo-like constellation is named as Principal Constellation, while the LEO satellites are named as Auxiliary satellites.

The Study shall explore and clarify the advantages and drawbacks of different techniques for the on-board processing considering ISL input observables, generating the satellite orbits and clocks. The Study shall analyze the technical feasibility of enhancing satellite accuracy and autonomy in the provision of navigation data, by means of on-board processing considering ISL input observables; with or without information exchanges between processors in different satellites. It shall clarify the:

Strategy for on-board satellite navigation data (orbit and clock) determination and prediction, including on-board satellite orbit and clock determination and prediction algorithms

The level of independence from ground based assets, in determining an adequate clock reference strategy (e.g. on-board clock ensemble).

Approach for the navigation data exchange between satellites of the Space Segment. Approach for the navigation data exchange between Space Segment and Ground Segment

(e.g. for linking the navigation data to UTC and ITRF).


page 7 of 101

Performance assessment in relevant scenarios, covering both nominal and degraded

constellation scenarios For this purpose the activities that are necessary have been identified and have been structured in four high level sets, which are listed hereafter:

Tasks regarding the on board orbit determination process

Tasks regarding the on board clock determination process

Tasks regarding ISL physical characterization

Tasks regarding group delay real time calibration


page 8 of 101

3 TASKS AND DEVELOPMENT LOGIC

3.1 Scope of activities [3.1.1] The contractor shall provide a justified design (architecture and technologies) for an

navigation system implementing ISL, that provides navigation observables orbit and clock prediction. A design and architectural definition is already provided with the ITT (please see appendixes), however the tenderer may challenge these suggestions and is invited to propose alternative solutions or modifications with adequate justification.

[3.1.2] Within the architectural design activities, the following activities shall be performed by

the contractor:

Selection of the technical solution for the ISL-based architecture, including a detailed definition of its components, the technologies and design drivers.

Confirmation and justification of the feasibility of the recommended solution. Identification of SW tool to be employed in the activity, and justification for the

definitive choice taken. Development of the SW tools to perform the activity (as far as possible by tailoring of

existing SW tools) Definition of the experimentation to be performed. Analysis of the results and conclusions.

[3.1.3] These activities shall be backed up by the assessment of techniques, technologies and

means to implement the ISL-based navigation system. [3.1.4] The selection, justification and confirmation of a solution for an ISL-based navigation

system, shall be supported by quantitative analysis [3.1.5] The activities shall be carried out in 4 sequential phases, identified as follows:

Definition Phase. SW Tool Implementation, Test Definition and Execution Phase. Intermediate Experimentation Phase. Final Experimentation Phase.

[3.1.6] Each one of these phases shall be subject of a review by the Agency who will declare the

objectives defined for this phase as achieved or failed.


page 9 of 101

3.2 Definition Phase (General Tasks) [3.2.1] The contractor shall analyze the reference material provided by the Agency (Appendixes

E, F, G, H and I). [3.2.2] The Definition Phase shall include at least the following activities:

Analyze the technical specification and applicable documents. Perform the functional decomposition and the architectural design of the system

including design trade offs and selection of the baseline concept. Quantitative engineering analyses to justify the architecture and design. Quantitative engineering analyses comparing different architectural solutions Identification of elements which would be new design. Assessment of feasibility for new design elements Identification of critical technologies and quantification of key parameters, .for new

design elements Preliminary definition of experimentation test cases and test scenarios. Selection and justification of ODTS SW tool to be used for the activity (e.g. Bernese). Definition of the modifications required on the SW tool in order to perform the foreseen

experimentation Autonomy capability versus G/S complexity G/S simplification in the enhanced System

[3.2.3] The Definition Phase shall end after successful completion of the Definition Review

(DR). Successful completion of this review will lead to authorization by the Agency to start the activities corresponding to the next phase.

3.3 Deliverables of the Definition Phase [3.3.1] The contractor shall deliver at the Definition Review a data package, with content

accordingly to the table below:

REVIEW

DELIVERABLE (BY DEFAULT DOCUMENT TITLE)

ISSUE

System Architecture Definition File (SADF) Issue 1.0

System Architecture Justification File (SAJF) (Including a detailed description of the traded off technologies)

Issue 1.0

DR

Experimentation Platform Definition File (EPDF)

Issue 1


page 10 of 101

Experimentation Platform Acceptance Test Procedures (EPAP)

Issue 1 (Final)

Test Case Experimentation Plan (TCEP) (Describing the Test Cases and Scenarios)

Issue 1.0

On-board Orbit Determination Detailed Processing Model

Issue 1.0

On-board Clock Determination Detailed Processing Model

Issue 1.0

Experimentation Platform User Manual Draft

[3.3.2] The contractor shall update the data package for Agency approval as a result of the

review discussion and agreements.

3.4 Detailed Tasks of the Definition Phase The Definition Phase shall cover, as a minimum, the following tasks by means of analysis: Regarding the constellation definition

[3.4.1] The Bidder shall optimize the auxiliary constellation definition. The constellation

parameters, described in the Appendix A (Technical Requirements), shall be optimized by the Contractor, including the number of auxiliary satellites, which are merely in charge of performing some system internal functions

[3.4.2] The contractor shall select an existing ODTS tool (e.g. Bernese) allowing the required

adaptations for the activity Regarding the orbit determination process shall be understood as both orbit restitution and orbit

prediction throughout the entire document.

The Study shall explore and clarify the advantages and drawbacks of the different alternatives for the on-board orbit determination and prediction process, analyzing in detail at least the following related areas:

[3.4.3] The sub-set of S/S to S/S observables to be processed on board each spacecraft for orbit

determination


page 11 of 101

[3.4.4] The sub-set of S/S to G/S observables to be processed on board each spacecraft for orbit

determination [3.4.5] The type of orbit estimation process (e.g. Batch, Kalman filter, etc) [3.4.6] The estimated parameters. The analysis shall include an assessment on the benefit of

estimating: Solar Radiation Pressure coefficients Earth Rotation Parameters delta coefficients

[3.4.7] The on-board CPU time consumption, indicating the minimum time span between

consecutive refreshments of the broadcast orbit [3.4.8] The power consumption of the on-board Orbit Determination board [3.4.9] The achievable performance in terms of broadcast orbit error in nominal scenarios (e.g.

availability of the full S/S and G/S) [3.4.10] The performance degradation in terms of broadcast orbit error, in nominal scenarios (e.g.

availability of the full S/S and G/S), when contact with the G/S is interrupted Regarding the clock determination process shall be understood as both clock restitution and

clock prediction throughout the entire document

The Study shall explore and clarify the advantages and drawbacks of different alternatives for the on-board clock determination and prediction process, analyzing in detail at least the following related areas:

[3.4.11] The sub-set of S/S to S/S observables to be processed on board each spacecraft for clock

determination [3.4.12] The definition of the navigation system time reference, independently from G/S clocks [3.4.13] The relativistic effects on the satellites on board clocks, when observed from either other

spacecrafts or from ground stations [3.4.14] The type of clock estimation process (e.g. Batch, Kalman filter, etc) [3.4.15] The estimated clock parameters [3.4.16] The on-board CPU time consumption, indicating the minimum time span between

consecutive refreshments of the broadcast clock [3.4.17] The power consumption of the on-board Clock Determination board


page 12 of 101

[3.4.18] The achievable performance in terms of clock error in nominal scenarios (e.g. availability

of the full S/S) [3.4.19] The performance degradation in terms of broadcast clock error, in nominal scenarios (e.g.

availability of the full S/S), when contact with the G/S is interrupted [3.4.20] The sub-set of S/S to G/S observables to be processed on board each spacecraft for the

estimation of the steering parameters necessary to refer the navigation system time to G/S based clocks or time external references

[3.4.21] The achievable performances in terms of steering parameters error in nominal scenarios

(e.g. availability of the full S/S) [3.4.22] The performance degradation in terms of steering parameters error, in nominal scenarios

(e.g. availability of the full S/S), when contact with the G/S is interrupted Regarding the ISL link physical definition the Study shall explore and clarify the advantages

and drawbacks of different alternatives. The Study shall clarify the: [3.4.23] Optimization of the ISL connectivity scheme between spacecrafts, or in other words with

what satellites is a given satellite supposed to establish a link [3.4.24] Optimization of the connectivity scheme between spacecrafts and ground [3.4.25] Number of “system internal” frequencies for ranging between principal satellites (see

Appendixes) [3.4.26] Frequency band for the “system internal” frequencies, as a compromise between key

parameters such as the antenna size or the propagation losses, and ITU allocated bands for ISLs. Selected band shall be compatible with an accurate control of the antenna group delay.

[3.4.27] Number of “system external” frequencies carrying ranging signals to the users (see

Appendixes) [3.4.28] Frequency sub-band for the “system external” frequencies. The frequency band for the

“system external” frequencies is the L band, including by default the Galileo frequencies Regarding the ranging signals they shall consist on pseudo-random sequences which are

generated in a synchronized way by both transmitter and receiver; and transmitted modulated on a radio-frequency carrier. The design is oriented to cross-link observables. The Study shall clarify the:


page 13 of 101

[3.4.29] Characteristics of the ranging signal, in terms of power density function [3.4.30] Characteristics of the ranging signal generation unit [3.4.31] Link budget [3.4.32] Characteristics of the ranging measurements quality [3.4.33] The ranging signals, leading to a ranging accuracy compatible with the Study’s objectives

in terms of orbit and clock determination accuracy. [3.4.34] The selection of the ranging signals shall target fast re-acquisition Regarding the cross-links antenna design the study shall analyze the:

[3.4.35] Feasibility and convenience of a phase array based antenna with its radiating elements

placed symmetrically on a spherical surface [3.4.36] Feasibility and convenience of alternative designs proposed by the Contractor, such as a

passive pattern [3.4.37] Group delay introduced by the antenna subsystem in the ranging signals, and its potential

dependency versus beam orientation Regarding the communication links.

[3.4.38] The Study shall analyze the possibility of re-using the ranging frequencies for

communication purposes either while ranging is being performed or during a different time slot exclusively dedicated for this purpose; or whether it is necessary to establish a different set of “system internal” frequencies for communication purposes.

The Study shall clarify the: [3.4.39] Exchanged information, including navigation, ranging data, telemetry and telecommand [3.4.40] Necessary bandwidth [3.4.41] Communication signal characteristics (including multiple access schemes) [3.4.42] Technology in terms of on-board transmitting and receiving chains [3.4.43] Performance assessment in relevant scenarios, in terms of BER and communication

delays


page 14 of 101

[3.4.44] Transmitting and receiving on board antennas [3.4.45] Compatibility with other RF links [3.4.46] Link budget Regarding the group delay calibration

[3.4.47] The Study shall explore and clarify the advantages and drawbacks of different methods

for the “system external” ranging signals group delay calibration, either based on the auxiliary satellites observations, or on satellite local means or on any other alternative method.

[3.4.48] The description of the on-board equipment required for performing this calibration Regarding the operational concept

[3.4.49] The Study shall identify the different operations modes, initialisation, switch between

ground-supported and autonomous modes [3.4.50] The Study shall propose a preliminary high level system operational concept [3.4.51] The Study shall identify the necessary adaptations to the navigation algorithms in order to

support the proposed mode transitions. All tasks shall consider the design guidelines described in the Appendixes E, F, G and H. These appendixes aim, either to define the starting point for the development, or merely to prove its feasibility. The study shall analyze the benefits from deviating from these guidelines if as result either performance improves or system complexity diminishes.


page 15 of 101

3.5 SW Tool Implementation, Test Definition and Execution Phase,

(General Tasks) [3.5.1] The contractor shall select an existing ODTS tool (e.g. Bernese) allowing the required

adaptations for the activity. [3.5.2] The SW tool shall be adapted, as necessary, in order to make possible the processing of

ISL measurements, in addition to the conventional space to ground measurements. [3.5.3] The contractor shall develop the auxiliary tools necessary to generate the input

measurements to the SW Tool, more precisely synthetic ISL measurements, and space to ground measurements..

[3.5.4] The SW tool user interface shall allow a flexible definition of the ISLs in terms of

number and in terms of type amongst the following:

Both S/Cs are part of the navigation constellation, One S/Cs is part of the navigation constellation and the other S/C is an auxiliary

LEO Both S/Cs are part of the auxiliary constellation,

Allowing simulations not only on the baseline architecture resulting from the Definition Phase but also with other combinations of ISLs.

[3.5.5] The SW tool output shall provide the accuracy of the orbit and clock determination and

prediction for each S/C. [3.5.6] The contractor shall perform a validation of the tool according to the needs of the study [3.5.7] The contractor shall define the test cases and scenarios for experimentation, covering

both the baseline architecture and other possible architectures derived from different combinations of ISLs and ground to space observables. The experimentation shall include, at least the following three scenarios:

ISLs between MEO navigation satellites ISLs between MEO navigation satellites, and between MEO and LEO

satellites, ISLs between MEO navigation satellites, between MEO and LEO satellites,

and between LEO satellites [3.5.8] The contractor shall update during this phase the documentation produced in previous

phases in order to input the modifications that arise as the study evolves.


page 16 of 101

[3.5.9] The SW Tool Implementation, Test Definition and Execution Phase shall end after

successful completion of the SW Implementation and Test Review/Experimentation Test Review (ERR).

3.6 Deliverables of the SW Tool Implementation Phase [3.6.1] The contractor shall deliver at the SW Implementation and Test Review/Experimentation

Test Review a data package, with content accordingly to the table below:

REVIEW


ISSUE

Experimentation Platform Acceptance Test Results (EPAR) (Including all implemented adaptations)

Issue 1 (Final)


System Architecture Justification File (SAJF) Issue 2.0

Test Case Experimentation Plan (TCEP)

Issue 2.0


Issue 2.0


Issue 2.0

ERR

Experimentation Platform User Manual Issue 1.0


page 17 of 101

[3.6.2] The contractor shall update during this phase the documentation produced in previous

phases in order to input the modifications that arise as the study evolves. [3.6.3] The contractor shall update the data package for Agency approval as a result of the


3.7 Detailed Tasks of the SW Tool Implementation Phase The SW Tool Implementation, Test Definition and Execution Phase shall cover, as a minimum, the following tasks, by means of analysis: [3.7.1] The review and refinement of the outputs of Tasks [3.4.9] up to [3.4.34] [3.7.2] The review and refinement of the outputs of Tasks [3.4.47] up to [3.4.48]


page 18 of 101

3.8 Intermediate Experimentation Phase (General Tasks) [3.8.1] This phase shall provide the first experimentation of the ISL based architecture for

navigation systems. The contractor shall perform during this phase the experimentation defined in previous phases.

[3.8.2] The experimentation plan shall be modified and adapted as required during the activity

according to the needs and evolution of the study. [3.8.3] The contractor shall perform simulations for different scenarios in order to assess the

performance achieved trade off with the complexity of the proposed architecture. [3.8.4] Software Problem Report (SPR) in the SW tool, cannot result in a reduction of the

experimentation scope. [3.8.5] The contractor shall update during this phase the documentation produced in previous

phases in order to input the modifications that arise as the study evolves. [3.8.6] The Intermediate Experimentation Phase shall end after successful completion of the

Intermediate Experimentation Phase Review (IER)

3.9 Deliverables of the Intermediate Experimentation Phase [3.9.1] The contractor shall deliver at the Intermediate Experimentation Phase Review a data

package, with content accordingly to the table below:

REVIEW


ISSUE

Test Case Experimentation Results (TCER) Issue 1



IER

Test Case Experimentation Plan (TCEP) Issue 2.1


page 19 of 101

On-board Orbit Determination Detailed Processing Model Issue 2.1

On-board Clock Determination Detailed Processing Model Issue 2.1





3.10 Detailed Tasks of the Intermediate Experimentation Phase The Intermediate Experimentation Phase shall cover, as a minimum, the following tasks mostly by means of experimentation: [3.10.1] The review and refinement of the outputs of Tasks [3.7.1] and [3.7.2] [3.10.2] The detailed and exhaustive experimentation of the design elaborated in the Definition

Phase and consolidated during the SW Tool Implementation Phase. For this purpose all analysis from [3.4.9] up to [3.4.22] and from [3.4.47] up ro [3.4.48] shall be replaced by experimentation results obtained with the help of the SW tool.

[3.10.3] The achievable performance in terms of broadcast orbit error in degraded scenarios (e.g.

availability of merely a reduced S/S or/and a reduced G/S) [3.10.4] The performance degradation in terms of broadcast orbit error in degraded scenarios (e.g.

availability of merely a reduced S/S or/and a reduced G/S), when contact with the G/S is interrupted

[3.10.5] The detail processing model of the orbit estimation algorithms at equation level [3.10.6] Robustness of the preferred alternative to external perturbations (e.g. contaminated

observables) [3.10.7] The achievable performance in terms of broadcast clock error in degraded scenarios (e.g.

availability of merely a reduced S/S)


page 20 of 101

[3.10.8] The performance degradation in terms of broadcast clock error in degraded scenarios

(e.g. availability of merely a reduced S/S), when contact with the G/S is interrupted [3.10.9] The achievable performances in terms of steering parameters error in degraded scenarios

(e.g. availability of merely a reduced S/S) [3.10.10] The performance degradation in terms of steering parameters error, in degraded scenarios

(e.g. availability of merely a reduced S/S), when contact with the G/S is interrupted [3.10.11] The detail processing model of the clock estimation algorithms, at equation level. Note

that clock estimates are relative to the Navigation System Reference Time [3.10.12] The detail processing model of the Navigation System Reference Time steering

algorithms, at equation level [3.10.13] Robustness of the preferred alternative to external perturbations e.g. contaminated

observables


page 21 of 101

3.11 Final Experimentation Phase (General Tasks) [3.11.1] During this phase the contractor shall carry out the activities as described in the previous

phase, endorsing and implementing the inputs provided by the Agency in the Intermediate Experimentation Results Analysis Phase.

[3.11.2] See requirement [4.4.2] [3.11.3] See requirement [4.4.3] [3.11.4] See requirement [4.4.4] [3.11.5] See requirement [4.4.5] [3.11.6] See requirement [4.4.6] [3.11.7] The Final Experimentation Phase shall end after successful completion of the Final

Experimentation Phase Review (FER). Successful completion of this review will lead to the completion and close out of the study.

3.12 Deliverables of the Final Experimentation Phase [3.12.1] The contractor shall deliver at the Intermediate Experimentation Phase Review a data

package, which content accordingly to the table below:

REVIEW


ISSUE

ODTS SW procured during activity, including all necessary licenses and libraries.

N/A

Experimentation Platform (HW) Final version

SW developed during activity, including all necessary licenses and libraries.

Final version

FER

Test data produced in the simulations and used for the analysis.

Final version


page 22 of 101

Final report (including a synthesis of the results and the conclusions)

Issue 1.0

System Architecture Definition File (SADF)

Issue 2.2



Issue 2.2


Issue 2.2





3.13 Detailed Tasks during the Final Experimentation Phase The Final Experimentation Phase shall cover, as a minimum, the following tasks, by means of experimentation: [3.13.1] The review and refinement of the outputs of Tasks [3.10.1] up to [3.10.13] by means of

additional experimentation


page 23 of 101

4 MANAGEMENT The standard requirements for management, reporting and meetings, which are described as an appendix to the contract, sections 1, 2 and 3 respectively, shall apply to this activity. Sections 4 and 5 of the mentioned appendix, on deliverables and commercial evaluation respectively, are not applicable to this study. The following additional requirements are incorporated to the mentioned appendix, section 1, on management: The contractor shall exercise an effective and transparent management of the work, providing

ESA at any time with all information necessary to undertake corrective measures if needed. The contractor shall organise the activity, propose a Work Breakdown Structure (WBS) and

provide an adequate allocation of tasks. The overall activity shall be completed in 12 months with the following intermediate milestone

dates:

Milestones Date (months) Kick –off (KO) KO Definition Phase Review (DR) KO + 04.0 m SW Tool Implementation, Test Definition and Execution Phase Review (ERR) KO + 09.0 m

Intermediate Experimentation Phase Review (IER) KO + 10.5 mFinal Experimentation Phase Review (FER) KO + 12.0 m

After successful completion of each of the intermediate reviews (Definition Phase Review, SW

Tool Implementation, Test Definition and Execution Phase Review, and Intermediate Experimentation Results Analysis Phase Review) the Agency will authorise the continuation of the activity and the initiation of the following phase.

The following additional requirements are incorporated to the mentioned appendix, section 2, on reporting: Minutes shall be distributed in Word or/and PDF format. Any presentations done at the

meeting shall be attached to the minutes in PPT format.


page 24 of 101

The following requirements replace entirely the mentioned appendix section 4, on deliverables: All items procured or developed under the contract shall be the property of the Agency at the

closure of the contract The Contractor shall submit to the Agency for information or approval (as applicable) all

technical notes, specifications, test and demonstration plans and other documents as they become available during the execution of the contract, at the latest by the agreed date of delivery

Any technical documentation to be discussed at a meeting with the Agency shall be submitted

at least 5 working days weeks prior to such a meeting The Contractor shall submit technical documents from subcontractors to the Agency normally

only after review and acceptance The Contractor shall give to the Agency prior notice without delay of any meetings with third

parties to be held in connection with the contract. The Agency reserves the right of participation in such meetings.

With due notice to the Contractor and with the Contractor's agreement, the Agency reserves the

right to invite third parties to meetings to facilitate information exchange. For all meetings the Contractor shall ensure that proper notice is given at least 2 weeks in

advance. The Contractor shall be responsible for ensuring the participation of his and of the sub-contractor(s)’ personnel as needed

For each meeting the Contractor shall provide an agenda and handouts of his presentation (if

any) If deemed necessary, the Agency or the Contractor may request ad hoc meetings.

Nominally, these documents and reports are to be provided in electronic form, in PDF

(including signatures) and in MS-WORD The list of contract output and deliverables given in previous chapter is neither exclusive nor

exhaustive and needs to be amended by the contractor as required.


page 25 of 101

TECHNICAL APPENDIX A (TECHNICAL REQUIREMENTS)

REQ-010: The Study shall be performed for two different constellations, associated to the Scenario I and Scenario II, which are described hereafter.

REQ-020: The Scenarios are defined in terms of Principal and Auxiliary satellites, being the Principal Satellites those which broadcast navigation signals to the GNSS user, and being the Auxiliary Satellites those merely in charge of some internal system functionalities, transparent to the GNSS user.

REQ-030: SCENARIO I

PRINCIPAL SATELLITES

Walker definition ppp fpt // 27/3/1 (GALILEO)

Number of satellites pt 27

Number of planes pp 3

Number of satellites per plane p

pp p

ts = 9

Pattern unit pp tu /360 o= 13.3°

Slot spacing

pp up * 40°

Node spacing

pp us * 120°

Satellite phasing

pp uf * 13.3°

Inclination 56° (GALILEO)

Orbit radius 29600 km (GALILEO)


page 26 of 101

Right ascension for the first plane node pα

AUXILIARY SATELLITES

Not applicable

The Scenario “I” considers exclusively Principal Satellites, and correspond exactly to the Galileo constellation. Tables above summarize all constellation parameters.

REQ-040: SCENARIO II

PRINCIPAL SATELLITES

As in Scenario I (GALILEO)

AUXILIARY SATELLITES

Walker definition aaa fpt // TBD (6/3/1)

Number of satellites at 6

Number of planes ap 3

Number of satellites per plane a

aa p

ts = 2

Pattern unit aa tu /360 o= 60°

Slot spacing

(spacing between spacecrafts in the same plane) aa up * 180°

Node spacing

(spacing between planes on the equator) aa us * 120°

Satellite phasing

(spacing between spacecrafts on consecutive planes) aa uf * 60°


page 27 of 101

Inclination TBD

Orbit radius TBD (LEO)

Right ascension for the first plane node 2* pp

p

us+α o60+pα

The Scenario “II” considers the same Principal Satellites as the Scenario I, this is the Galileo MEO constellation, plus a reduced LEO constellation of Auxiliary Satellites. Table above summarizes all auxiliary constellation parameters.

REQ-050: The number of auxiliary satellites shall be minimize as far as possible

REQ-060: The study shall target orbit prediction accuracies below 1 centimetre level

REQ-070: The study shall target clock prediction accuracies below 1 centimetre level

REQ-080: The group delay real time calibration shall target sub-centimetre level accuracy


page 28 of 101

TECHNICAL APPENDIX B (ECSS-E-40 TAILORING) Software process mapping to work packages

The software development processes introduced in ECSS-E40 part 1B are mapped on the work

packages and activities or tasks of the Statement of Work in the following way:

ECSS-E40 part 1B processes & activities Reference in the Statement of Work

System Engineering Processes related to software:

- System requirements, - System architecture, - System design &

Hardware/Software partitioning,

Definition phase (part of*)

*: Experiment Platform Definition File , On Board Orbit Determination Detailed Processing Model ,

On Board Clock Determination Detailed Processing Model

SRR Merged with PDR

Software Requirements & Architecture Engineering Process:

- Software requirements specification,

- Interface Control Document - Software architecture,

Definition phase (part of*)

*: On Board Orbit Determination Detailed Processing Model , On Board Clock Determination

Detailed Processing Model

PDR DR

Software Design & Implementation Engineering Process:

- Detailed design, - Code, - Unit tests, - Integration tests,

SW tool implementation, Test definition and Execution Phase (part of)


page 29 of 101

DDR N/A

Software Validation Process:

- Software validation wrt TS

N/A

CDR N/A

Software Validation Process:

-Software Validation wrt RB

SW tool implementation, Test definition and Execution Phase (part of)

QR ERR

Software Delivery & Acceptance Implicitly included in the Final Experiment Phase

AR FER

Software Operation N/A

Software maintenance During the whole life cycle for evolutive maintenance if ODTS software is a COTS to be modified

During the 6 months warranty period for corrective maintenance of the new developed items (e.g. utilities)

Software management process Not formally required since management factors are not the keys drivers ( COST is Firm Fixed Price , DELAY is also fixed) of this project but a SDP ( that can be part of a global system development plan) is asked in the proposal

Software verification process - Experiment Platform RB/TS – SVTS/SATS traceabilty

- Timing & Sizing Budget Report - Numerical Accuracy Report


page 30 of 101

List of ECSS-E40 applicable requirements

ECSS-E-40 part 1B from 28 November 2003 5.2 System Engineering Processes related to software 5.2.2.1 System requirements specification 5.2.3.1a System design 5.2.5.2 Control and data interfaces for system level integration 5.2.7.1 Software maintenance requirements 5.3 Software Management Process (only at proposal) 5.3.2.1 Definition of software life cycle 5.3.2.2 Software life cycle identification 5.3.2.3 Identification of inputs and outputs associated to each phases 5.3.2.4 Identification of documentation relevant to each 5.3.2.5 Identification of interface between the development and the maintenance processes 5.3.2.6 Requirements baseline at the SRR (at PDR in that case ) 5.3.2.7 Software technical specification phase 5.3.2.8 PDR (Preliminary Design Review) 5.3.2.11 software verification and validation process 5.3.2.12 QR (Qualification Review) 5.3.2.13 AR (Acceptance Review) 5.3.3.2 Support to software reviews 5.3.3.3 Technical reviews 5.3.4.1 Interface definition 5.3.5.1 Technical budget and margin philosophy 5.3.5.2 Technical budget and margin status at each milestone 5.4.2.1 Establishment and documentation of software requirements / software requirements specification: 5.4.2.1-a software requirements – functional and performance 5.4.2.1-e software requirements – data definition and DataBase requirements 5.4.2.1-f software requirements – Interfaces external to the software item 5.4.2.3 Identification of requirements unique identifier 5.4.3.1 Transformation of software requirements into a software architecture 5.4.3.2 Software design description 5.4.3.3 Software design documentation 5.4.3.4 Software architectural design contents 5.4.3.11 Evaluation of reuse of predeveloped software 5.4.3.12 Analysis of potential reusability 5.4.3.14 Conducting a preliminary Design Review (PDR) 5.5.2.1 Detailed design of each software components 5.5.2.2 Development and documentation of the software interface detailed design


page 31 of 101

ECSS-E-40 part 1B from 28 November 2003 5.5.2.8 Development and documentation of the software user manual 5.5.3.1 Development and documentation of the software units, test procedures and test data 5.6 Software validation process 5.6.4.1 Development and documentation of a software validation testing specification (SVTS) wrt RB 5.6.4.2 Conducting the validation wrt RB 5.6.4.3 Updating the software user manual 5.6.4.5 Conducting a Qualification Review (QR) 5.7 Software delivery and acceptance 5.7.2 Software delivery and installation 5.7.2.1 Preparation of the software product 5.7.3 Software acceptance 5.7.3.1 Acceptance test planning 5.7.3.2 Acceptance test execution 5.7.3.3 Executable code generation and installation 5.7.3.4a Supplier’s support to customer’s acceptance 5.7.3.4c Acceptance testing documentation 5.7.3.5 Evaluation of acceptance testing 5.7.3.6 Conducting an Acceptance Review (AR) 5.8 Software verification process 5.8.3 Verification activities 5.8.3.7 Verification of test specifications 5.8.3.12a / as support for verification of software requirements & architectural design / sizing (memory) and timing (CPU load) estimation 5.8.3.12c/ as support for verification of software coding and testing / sizing (memory) and timing (CPU utilization in WCET) calculation 5.8.3.13 Behaviour modelling verification 5.10.2.3 problem reporting and handling 5.10.2.4 Implementation of configuration management process 5.10.3.1 Problem analysis 5.10.3.2 Problem verification 5.10.3.3 Development of options for modifications 5.10.3.4 Documentation of problem, analysis and implementation 5.10.3.5 Customer approval of selected modifications options 5.10.4.1 Analysis and documentation of product modification 5.10.4.2 Documentation of software product changes 5.10.4.3 Invoking of software engineering process for modification implementation


page 32 of 101

Document Requirement List [as specified in ECSS-E-40 part 2B (15 November 2004)]

The ECSS software standards are completed with some DRDs, describing the most important software documents. The DRD list is a subset of the exhaustive list of documents to be produced in order to cover all the work output required by the ECSS standards.

The expected output of the requirements resulting of this tailoring shall be placed in the documents identified in the right column of the table below “GSP Study deliverable”.

It is highlighted that the left column of the table below, “ECSS Documentation” does not refer to the actual deliverables of the GSP activity, but should be understood as a list of outputs, which should appear within the real activity deliverables (found in the right column).

Note that most of the requirements outputs should imply merely a brief section within one of the identified GSP deliverables, result of a limited effort, which should not jeopardize the experimentation activities which are the core and objective of the GSP activity.

Note as well that this section refers exclusively to any new SW developed within the activity, and necessary for the experimentation.

ECSS Document ECSS Acronym in DRD

GSP Study Deliverable

SW System Specification SSS SW Interface Requirements Document

-

System partition with definition of items

System Configuration Item List

Software Requirements Specification

SRS

Software Interface Control Document

-

Software Design Document: Software static and/or dynamic architecture

SDD

System Architecture Definition File Experimentation Platform Definition File On-Board Orbit Determination Detailed Processing Model On board Clock Determination Detailed Processing Model

Software Release Document SRD ODTS & utilities software release notes

Software Delivery - ODTS software executable, licenses, libraries, documentation , input and output data

Software User Manual SUM Experimentation Platform User Manual

Software Validation Testing SVTS Experimentation Platform


page 33 of 101

Specification wrt RB Acceptance Test Plan - Software Validation Test Report wrt RB

-

Acceptance Testing Documentation

-

Acceptance Test Report -

Acceptance Test Procedures Experimentation Platform Acceptances Test Report

(Analyses, Inspection & RoD) verification report wrt RB

-

Software Traceability Matrices -

Experimentation Platform Acceptance Test Procedures

Software Reuse File (if any) SRF ODTS Software Reuse

File Software Budget Report - Numerical Accuracy Analysis Report

-

Validation Evaluation Report wrt RB

-

Experimentation Platform Acceptance Test Procedures (special test) Experimentation Platform Acceptances Test Report

Software Acceptance Data Package - SW delivery notice Procured Software Component Lists

- System Architecture Definition File Experimentation Platform Definition File

PR & NCR - Modification analysis report -Problem analysis report

- SPR and CR

Software Development Plan (at proposal only)

SDP As part of the Proposal


page 34 of 101

TECHNICAL APPENDIX C (TECHNICAL FEATURES AUTONOMY-RELATED EXISTING IN THE GPS SYSTEM AND FORESEEN FOR THE GALILEO SYSTEM) GALILEO Galileo will be an independent, global European-controlled satellite-based navigation system. It will have a constellation of satellites monitored and controlled by a Ground Control Segment.

The overall Galileo System is illustrated in the figure above. The Galileo Space Segment will comprise a constellation of thirty satellites in medium-Earth orbit (as defined in the table below). Each satellite will broadcast four ranging signals carrying clock synchronisation, ephemeris, integrity and other data, depending on the particular signal.


page 35 of 101

GALILEO SPACE SEGMENT

Walker definition ppp fpt // 27/3/1 (GALILEO)




pp p

ts = 9

Pattern unit pp tu /360 o= 13.3°

Slot spacing

(spacing between spacecrafts in the same plane) pp up * 40°

Node spacing

(spacing between planes on the equator) pp us * 120°

Satellite phasing

(spacing between spacecrafts on consecutive planes) pp uf * 13.3°

Inclination 56° (GALILEO)

Orbit radius 29600 km (GALILEO)

Right ascension for the first plane node ( )tGALα

The Galileo Ground Segment will control the whole Galileo constellation; monitor the satellite health and up-load data for subsequent broadcast to users. The key elements of this data such as clock synchronisation, ephemeris, will be calculated from measurements made by a network of approximately 40 Galileo receiving stations. The Ground Segment is split into: The Ground Control Segment (GCS) in charge of monitoring and & control of the Galileo

constellation, The Ground Mission Segment (GMS) in charge of the determination and dissemination of the

navigation and integrity data


page 36 of 101

The Ground Mission Segment (please see next figure) is composed of:

GSS: Galileo Sensor Stations: GSS are in charge of Galileo satellites navigation signals monitoring, associated arrival time measurements relative to their reference and results routing to the Ground Segment Processing Facilities. MDDN: Communications network

OSPF Orbitography and Synchronization Processing Facility in charge of Orbit determination

and time Synchronisation Processing (OD&TS) i.e. Galileo satellites ephemeris and clock correction parameters estimation and prediction as well as Signal In Space Accuracy (SISA) determination for Galileo satellites. MGF: Message Generation Facility is in charge of multiplexing and routing navigation/integrity

data to be sent for mission uplink. MUCF: Mission Uplink Control Facility in charge of determining the contact plan for each

satellite and for each up-link station antenna, etc. ULS: Up-link stations in charge of navigation, data transmission up to Galileo satellites

PTF: Precise Timing Facility in charge of Precision Time processing, including Two Way Time

Transfer (TWTT) with UTC (k), and Galileo System Time (GST) establishment and a number of additional facilities such as the MCF, MSF, SPF, GACF, MKMF, SKMF and PRSKMF, etc

The Galileo System does not consider ISL technology and has no demanding specification in terms of satellite autonomy in the Galileo System Requirements document. Concrete specifications can be found in the table below

GAL

SATELLITE

RELEVANT SPECIFICATIONS

Satellite Working Without Guarantee: The Galileo satellite shall automatically set the Satellite Navigation Service level status flag in each Navigation Data Message to “working without guarantee” if the satellite receives no valid up-link signals for a period which it shall be possible to pre-set to any value from 100 minutes to 10 orbits

.


page 37 of 101


page 38 of 101

GPS The NAVSTAR Global Positioning System is managed by the NAVSTAR GPS Joint Program Office at the Space and Missile Systems Centre, Los Angeles Air Force Base, California. The GPS space segment consists of into six orbital planes, requiring a minimum of four satellites in each, to operate. The Global Positioning Service Space Segment comprises a nominal constellation of twenty four satellites in medium-Earth orbit (as defined in the Table below), plus 6 in orbit spares. Each satellite broadcasts one open ranging signal carrying clock synchronisation, and ephemeris.

GPS SPACE SEGMENT




pp p

ts = 4

Pattern unit pptu /360 o=

15°

Node spacing

(spacing between planes on the equator) pp us * 60°

Inclination 55°

Orbit radius 20200 km

Right ascension for the first plane node ( )tGPSα

The GPS constellation currently contains four different types of GPS satellites called Block II, Block IIA, Block IIR and Block IIRM (first satellite launched in September 26, 2005). The allocation of satellites to planes, labelled from A to F, and plane slots numbered from 1 up to 5, is detailed below:


page 39 of 101

CURRENT BLOCK II/IIA/IIR/IIR-M SATELLITES =========================================

LAUNCH LAUNCH FREQ US SPACE ORDER PRN SVN DATE STD PLANE COMMAND ** ----------------------------------------------------------------- *II-1 14 14 FEB 1989 19802 *II-2 13 10 JUN 1989 20061 *II-3 16 18 AUG 1989 20185 *II-4 19 21 OCT 1989 20302 *II-5 17 11 DEC 1989 20361 *II-6 18 24 JAN 1990 20452 *II-7 20 26 MAR 1990 20533 *II-8 21 02 AUG 1990 20724 II-9 15 15 01 OCT 1990 Cs D5 20830 *IIA-10 23 26 NOV 1990 20959 IIA-11 24 24 04 JUL 1991 Cs D6 21552 IIA-12 25 25 23 FEB 1992 Cs A2 21890 *IIA-13 28 10 APR 1992 21930 IIA-14 26 26 07 JUL 1992 Rb F2 22014 IIA-15 27 27 09 SEP 1992 Cs A4 22108 IIA-16 01 32 22 NOV 1992 Cs F6 22231 *IIA-17 29 29 18 DEC 1992 Rb F5 22275 *IIA-18 22 03 FEB 1993 22446 IIA-19 31 31 30 MAR 1993 Cs C5 22581 IIA-20 07 37 13 MAY 1993 Rb C4 22657 IIA-21 09 39 26 JUN 1993 Cs A1 22700 IIA-22 05 35 30 AUG 1993 Rb B4 22779 IIA-23 04 34 26 OCT 1993 Rb D4 22877 IIA-24 06 36 10 MAR 1994 Rb C1 23027 IIA-25 03 33 28 MAR 1996 Cs C2 23833 IIA-26 10 40 16 JUL 1996 Cs E3 23953 IIA-27 30 30 12 SEP 1996 Rb B2 24320 IIA-28 08 38 06 NOV 1997 Cs A3 25030 ***IIR-1 42 17 JAN 1997 IIR-2 13 43 23 JUL 1997 Rb F3 24876 IIR-3 11 46 07 OCT 1999 Rb D2 25933 IIR-4 20 51 11 MAY 2000 Rb E1 26360 IIR-5 28 44 16 JUL 2000 Rb B3 26407 IIR-6 14 41 10 NOV 2000 Rb F1 26605 IIR-7 18 54 30 JAN 2001 Rb E4 26690 IIR-8 16 56 29 JAN 2003 Rb B1 27663 IIR-9 21 45 31 MAR 2003 Rb D3 27704 IIR-10 22 47 21 DEC 2003 Rb E2 28129 IIR-11 19 59 20 MAR 2004 Rb C3 28190 IIR-12 23 60 23 JUN 2004 Rb F4 28361 IIR-13 02 61 06 NOV 2004 Rb D1 28474 IIR-M1 17 53 26 SEP 2005 C4 * Satellite is no longer in service. ** US SPACE COMMAND, previously known as the NORAD object number; also referred to as the NASA Catalog number. Assigned at successful launch. *** Unsuccessful launch.


page 40 of 101

The GPS Ground Segment consists of five monitoring stations (Hawaii, Kwajalein, Ascension Island, Diego Garcia, Colorado Springs), three ground antennas, (Ascension Island, Diego Garcia, Kwajalein), and a Master Control station located at Schriever AFB in Colorado. The GPS System considers ISL technology and has direct specifications in terms of satellite autonomy. Relevant information can be found in the table below:

GPS

SATELLITE

RELEVANT SPECIFICATIONS

Block II

Corresponds to the space vehicle numbers SVN 13 through 21. Block II satellites were designed to provide 14 days of operation without contact from the Ground Segment.

Note: The Block IIs were launched from February 1989 through October 1990.

Block IIA

Corresponds to the space vehicle numbers SVN 22 through 40. Block IIA satellites were designed to provide 180 days of operation without contact with the Ground Segment. During the 180 day autonomy, degraded accuracy will be evident in the navigation message

Note: The Block IIAs were launched from November 1990 through November 1997.

Block IIR

Corresponds to the space vehicle numbers SVN 41 through 62. Block IIR satellites are designed to provide at least 14 days of operation without contact from the CS and up to 180 days of operation when operating in the autonomous navigation (AUTONAV) mode. Full accuracy will be maintained using a technique of ranging and communication between the Block IIR satellites. The cross-link ranging will be used to estimate and update the parameters in the navigation message of each Block IIR satellite without contact from the Ground Segment Note: The Block IIRs launching started in January 1997

Block IIR-M

Corresponds to the space vehicle number SVN 53. Block IIR-M satellites incorporate respect Block IIR two new military signals and a second civil signal Note: The Block IIR-Ms launching started in September 2005


page 41 of 101

TECHNICAL APPENDIX D (OBSERVABLES FOR THE ON-BOARD OD&TS PROCESS) Principal satellite to principal satellite observable: Two types of observables are used for orbit determination, namely:

• Halved “Two way range cross-links” • Halved “Range rate cross-links”

which are obtained by linear combinations of other more elemental observables; concretely from conventional pseudorange and Doppler observables. The process yielding to the orbit determination input observables is explained hereafter, with the help of the figure below:

Where:

• iSV refers to the space vehicle “i” • zwp refers to a one way range observable (pseudorange), being the transmitter “z” and the

receiver “w”


page 42 of 101

The study considers that the one-way observables are derived from the correlation between a PRN code generated by one spacecraft, in transmission mode, and an identical PRN code replicated by other spacecraft, in reception mode. Concretely the study might consider by default the following measurement scheme amongst Principal Satellite’s pairs (e.g. aSV and bSV ):

1. aSV starts the transmission of the PRN “A” code (first bit) towards bSV at time pt , modulated on system carrier 1sf

2. bSV starts the transmission of the PRN “A” code (first bit) towards aSV at time pt ,

modulated on system carrier 1sf

3. aSV ends the transmission of the PRN “A” code A (last bit) towards bSV at time maxtt p ∆+ , modulated on system carrier 1sf

4. bSV end the transmission of the PRN “A” code (last bit) towards aSV at time

maxtt p ∆+ , modulated on system carrier 1sf

5. aSV receives the transmission of the PRN “A” code (first bit) from bSV at time app tt ,∆+ , modulated on system carrier 1sf


page 43 of 101

6. bSV receives the transmission of the PRN “A” code (first bit) from aSV at time bpp tt ,∆+ , modulated on system carrier 1sf

7. aSV ends the reception of the PRN “A” code (last bit) from bSV at

time max, ttt app ∆+∆+ , modulated on system carrier 1sf

8. bSV ends the reception of the PRN code (last bit) from aSV at time max, ttt bpp ∆+∆+ , modulated on system carrier 1sf

In this scheme:

• PRN “A” is common to all satellites

• aptt ,max ∆


page 44 of 101

In the above described scheme the correlation of the PRN “A” code, received between

app tt ,∆+ and max, ttt app ∆+∆+ , by the aSV , with a replica of the PRN “A” code generated

internally in aSV is possible. The same statement can be done for the PRN “A” code, received between bpp tt ,∆+ and max, ttt bpp ∆+∆+ , by the

bSV . The following two one way observables are obtained in the above scheme:

( )max, tttp appba ∆+∆+ and ( )max, tttp bppab ∆+∆+ which are given by the following equations:

( ) ( ) ( ) ( )( ) ( ) ( )max,max,max

max,maxmax,max,

ttttttHttH

tttCttCtttdtttp

appbaapp

RXap

bTX

appapb

appbaapp

ba

∆+∆++∆+∆+−∆++

∆+∆+−∆++∆+∆+=∆+∆+

ε

( ) ( ) ( ) ( )( ) ( ) ( )max,max,max

max,maxmax,max,

ttttttHttH

tttCttCtttdtttp

bppabbpp

RXbp

aTX

bppbpa

bppabbpp

ab

∆+∆++∆+∆+−∆++

∆+∆+−∆++∆+∆+=∆+∆+

ε

Where

• ( )max, tttd appba ∆+∆+ refers to the distance traveled by the signal transmitted from satellite bSV , at maxtt p ∆+ , till it reaches

aSV , at max, ttt bpp ∆+∆+ .

• ( )max, tttd bppab ∆+∆+ refers to the distance traveled by the signal transmitted from

satellite aSV , at maxtt p ∆+ , till it reaches bSV , at max, ttt app ∆+∆+ .

• ( ) ≠∆+∆+ max, tttd appba ( )max, tttd bppab ∆+∆+


page 45 of 101

• ( )maxttC pb ∆+ refers to the on board clock of bSV at maxtt p ∆+

• ( )max, tttC bppb ∆+∆+ refers to the on board clock of bSV at max, ttt app ∆+∆+

• ( ) ≅∆+ maxttC pb ( )max, tttC bppb ∆+∆+ for the maximum bpt ,∆ which for dimensioning

purposes can be set in 300 ms (equivalent to 90000 Km), assuming a conventional AFS on board bSV

• ( )maxttC pa ∆+ refers to the on board clock of aSV at maxtt p ∆+

• ( )max, tttC appa ∆+∆+ refers to the on board clock of aSV at max, ttt bpp ∆+∆+

• ( ) ≅pa tC ( )max, tttC appa ∆+∆+ for the maximum apt ,∆ which for dimensioning

purposes can be set in 300 ms (equivalent to 90000 Km), assuming a conventional AFS on board aSV

• ( )maxttH pbTX ∆+ refers to the on board PRN “A” code signal group delay, within the

bSV payload, from its generation, coherent with the on board clock, till it reaches the transmitting antenna phase center for the system frequency 1sf at maxtt p ∆+

• ( )max, tttH appRXa ∆+∆+ refers to the on board PRN “A” code signal group delay, within

the aSV payload, from its reception at the receiving antenna phase center for the system frequency 1sf , till it reaches the PRN “A” code correlator on board, at

max, ttt app ∆+∆+

• ( )maxttH paTX ∆+ refers to the on board PRN “A” code signal group delay, within the

aSV payload, from its generation, coherent with the on board clock, till it reaches the transmitting antenna phase center for the system frequency 1sf at maxtt p ∆+

• ( )max, tttH bppRXb ∆+∆+ refers to the on board PRN “A” code signal group delay, within

the bSV payload, from its reception at the receiving antenna phase center for the system frequency 1sf , till it reaches the PRN “A” code correlator on board, at


page 46 of 101

max, ttt bpp ∆+∆+

• ( ) ( )max, tttHtH appbTXpbTX ∆+∆+≅ assuming conventional group delay stabilities for the

on board bSV transmitting chain.

• ( ) ( )max, tttHtH appaTXpaTX ∆+∆+≅ assuming conventional group delay stabilities for the on board aSV reception chain.

• ( ) ( )max, tttHtH bppRXbpRXb ∆+∆+≅ assuming conventional group delay stabilities for

the on board bSV transmitting chain.

• ( ) ( )max, tttHtH appRXapRXa ∆+∆+≅ assuming conventional group delay stabilities for the on board aSV transmitting chain.

• ( ) ≠pbTX tH ( )pRXb tH as one the first is a group delay associated to the bSV transmitting

chain of the PRN “A” code, modulated on the system frequency 1sf , while the second

is a group delay associated to the bSV reception chain.

• ( ) =paTX tH ( )pRXa tH as one the first is a group delay associated to the bSV transmitting chain of the PRN “A” code, modulated on the system frequency 1sf , while the second

is a group delay associated to the bSV reception chain.

• ( )max, ttt appba ∆+∆+ε refers to the one way observable error at max, ttt app ∆+∆+ , which is labeled as ( )pba tε , as it does not introduce any confusion

• ( )max, ttt bppab ∆+∆+ε refers to the one way observable error at max, ttt bpp ∆+∆+ , which

is labeled as ( )pab tε , as it does not introduce any confusion Therefore the basic one way observables, under the above mentioned conditions can be expressed in the following simplified form:


page 47 of 101

( ) ( ) ( ) ( ) ( ) ( ) ( )pbapRXapbTXpapbappbaappba ttHtHtCtCtttdtttp ε+−+−+∆+∆+=∆+∆+ max,max,

( ) ( ) ( ) ( ) ( ) ( ) ( )pabpRXbpaTXpbpabppabbppab ttHtHtCtCtttdtttp ε+−+−+∆+∆+=∆+∆+ max,max,

The distances ( )max, tttd appba ∆+∆+ and ( )max, tttd bppab ∆+∆+ can be converted to the

( ) ( )pbapba tdtd = observable, which corresponds with the geometrical distance between aSV and bSV at time pt . For this purpose, it can be used, the a priori knowledge of:

• ( )( )

dttttdd app

ba max, ∆+∆+ , which can observed from Doppler observables or computed

• The satellite positions and clocks at time pt Assuming all the above corrections are applied, and adapting the terminology for ( )tp ab , so that it refers to the common transmission time pt , it finally results in:

( ) ( ) ( ) ( ) ( ) ( ) ( )pbapRXapbTXpapbpbapba ttHtHtCtCtdtp ε+−+−+=

( ) ( ) ( ) ( ) ( ) ( ) ( )pabpRXbpaTXpbpapabpab ttHtHtCtCtdtp ε+−+−+=


page 48 of 101

In terms of simultaneity between different observations:

• zwp and wzp are simultaneous, ( )wz,∀

• zwp and '

'wzp are not simultaneous, unless

⎩⎨⎧

==

wwzz

''

Consistently, the one way observables are:

• ( ) ( )[ ]pabpba tptp ,

• ( ) ( )[ ]racrca tptp , Each pair ( ) ( )[ ]pabpba tptp , can be transformed in a pair ( ) ( )[ ]pabpba tCtd ˆ,ˆ in the following way:

( ) ( )[ ]( ) ( ) ( )( )

( ) ( ) ( )( )⎪⎪

⎩

⎪⎪

⎨

⎧

−=

+=

=

2ˆ

2ˆ

ˆ,ˆ

pabp

ba

pab

pabp

ba

pba

pabp

ba

tptptC

tptptd

tCtd

( ) ( ) ( ) ( )( ) ( ) ( )( ) ( )

( ) ( ) ( ) ( ) ( )( ) ( ) ( )( ) ( )⎪⎪

⎩

⎪⎪

⎨

⎧

+−−−

+−=

+−+−

+=

=

−

+

pbap

RXbp

aTXp

RXap

bTX

papbpba

pbap

RXbp

aTXp

RXap

bTX

pabpab

ttHtHtHtH

tCtCtC

ttHtHtHtH

tdtd

ε

ε

2ˆ

2ˆ

( ) ( ) ( ) ( )( ) ( ) ( )( ) ( )

( ) ( ) ( ) ( ) ( )( ) ( ) ( )( ) ( )⎪⎪

⎩

⎪⎪

⎨

⎧

++

++

−−=

+−

+−

+=

=

−

+

pbap

RXbp

bTXp

RXap

aTX

papbpba

pbap

RXbp

bTXp

RXap

aTX

pabpab

ttHtHtHtH

tCtCtC

ttHtHtHtH

tdtd

ε

ε

22ˆ

22ˆ


page 49 of 101

Where:

• ( ) =pab td ( ) ( )pabpba tdtd = is the distance between satellites ""a and ""b at pt • ( )pba t+ε refers to average between ( )pa tε and ( )pb tε • ( )pba t−ε refers to the semi-difference between ( )pa tε and ( )pb tε

The observable ( )pab td̂ is used for orbit determination, after a number of manipulations described afterwards. This observable has the following characteristics:

• It is a purely ionosphere-free observable. • It is a purely troposphere free observable • It is a purely on board clocks free observable • It is not affected by any ambiguity • It is biased by the amount (slowly varying along time)

( ) ( )( ) ( ) ( )( )2

pRXbp

aTXp

RXap

bTX tHtHtHtH −+−

• It is affected by the local multipath caused by the satellite structure nearby the antenna

receiving the one way signal • It is affected by the local on-board receiver noise

The observable ( )pba tĈ is an on board clock observable, which nevertheless is considered just an auxiliary measurement for the clock estimation process. This observable has the following characteristics:

• It is a purely ionosphere-free observable. • It is a purely troposphere free observable • It is a purely orbit/geometry free observable • It is not affected by any ambiguity • It is biased by the amount (slowly varying along time)

( ) ( )( ) ( ) ( )( )22

pRXbp

bTXp

RXap

aTX tHtHtHtH ++

+

• It is affected by the local multipath caused by the satellite structure nearby the antenna

receiving the one way signal


page 50 of 101

• It is affected by the local on-board receiver noise

The errors ( )pba t+ε and ( )pba t−ε affecting the observables ( )pab td̂ and ( )pba tĈ are uncorrelated as demonstrated below, at least as far as the errors ( )pba tε and ( )pab tε affecting the one way observables ( )pba tp and ( )pab tp are:

• Uncorrelated • Identical from a statistical perspective

( ) ( )bapba Nt σε ,0≈

( ) ( )abpab Nt σε ,0≈

( ) ( )pabpba tt σσ =

This is demonstrated below:

( )

( )( )( )

( )( ) ⎟⎟

⎠

⎞

⎜⎜

⎝

⎛=

⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛

2

2

00

pab

pba

pba

pba

tt

t

tCov

σ

σ

ε

ε

( )

( )

( )

( )⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛

⎟⎟

⎠

⎞

⎜⎜

⎝

⎛

−=⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛

−

+

pba

pba

pba

pba

t

t

t

t

ε

ε

ε

ε

21

21

21

21

What yields to the following covariance matrix:

( )

( )( )( )

( )( ) ⎟⎟

⎠

⎞

⎜⎜

⎝

⎛

−⎟⎟

⎠

⎞

⎜⎜

⎝

⎛

⎟⎟

⎠

⎞

⎜⎜

⎝

⎛

−=⎟⎟⎟

⎠

⎞

⎜⎜⎜

⎝

⎛

−

+

21

21

21

21

00

21

21

21

21

2

2

pab

pba

pba

pba

tt

t

tCov

σ

σ

ε

ε


page 51 of 101

( )( )

( )( ) ( )( ) ( )( ) ( )( )

( )( ) ( )( ) ( )( ) ( )( )⎟⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜⎜

⎝

⎛

+−

−+

=⎟⎟⎠

⎞⎜⎜⎝

⎛

−

+

44

44

2222

2222

pbap

bap

bap

ba

pbap

bap

bap

ba

pba

pba

tttt

tttt

tt

Cov

σσσσ

σσσσ

εε

Under the mentioned assumption that ( ) ( )pabpba tt σσ = it follows:

( )( )

( )( )

( )( )⎟⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜⎜

⎝

⎛

=⎟⎟⎠

⎞⎜⎜⎝

⎛

−

+

20

02

2

2

p

p

pba

pba

t

t

tt

Covσ

σ

εε

The standard deviation of the errors ( )pba t+ε and ( )pba t−ε is smaller than that of the originals errors ( )pba tε and ( )pab tε .


page 52 of 101

The observable ( )pab td̂ requires, as mentioned before, some further manipulations before it can be entered in the orbit determination process, in order to remove the bias due to group delays, both in the satellites transmission and reception chains. Concretely the following differencing scheme is proposed: Given the following observables:

( ) ( ) ( ) ( )( ) ( ) ( )( ) ( )1111111 22ˆ

pbap

RXbp

bTXp

RXap

aTX

pabpab ttHtHtHtH

tdtd ++−

+−

+= ε

( ) ( ) ( ) ( )( ) ( ) ( )( ) ( )2222222 22ˆ

pcap

RXcp

cTXp

RXap

aTX

pacpac ttHtHtHtH

tdtd ++−

+−

+= ε

( ) ( ) ( ) ( )( ) ( ) ( )( ) ( )3333333 22ˆ

pbdp

RXbp

bTXp

RXdp

dTX

pdbpdb ttHtHtHtH

tdtd ++−

+−

+= ε

( ) ( ) ( ) ( )( ) ( ) ( )( ) ( )4444444 22ˆ

pcdp

RXcp

cTXp

RXdp

dTX

pdcpdc ttHtHtHtH

tdtd ++−

+−

+= ε

Where 1pt , 2pt , 3pt and 4pt are close enough to consider that the all the terms referring to biases stay constant. The following new observable can be derived:

( ) ( ) ( )( ) ( ) ( )( )( ) ( )( ) ( ) ( )( )4321

43214321 ,,,ˆ

pcdpbdpcapba

pdcpdbpacpabppppbcad

tttt

tdtdtdtdttttd

++++ −−−

−−−=∇∆

εεεε

This observable has the following characteristics:

• It is a purely ionosphere-free observable. • It is a purely troposphere free observable • It is a purely on board clocks free observable • It is not affected by any ambiguity • It is affected by the local multipath caused by the satellite structure nearby the antenna

receiving the one way signal


page 53 of 101

• It is affected by the local on-board receiver noise

The above observable is very similar to a double difference, except in the fact that the four observations are not simultaneous except from the perspective of the terms it intends to cancel. The observable ( )pbcad td̂∇∆ yields to the follow