Development of the Navigation Payload for the Galileo In-Orbit Validation (IOV) Phase

Transcription

1 International Global Navigation Satellite Systems Society IGNSS Symposium 2007 The University of New South Wales, Sydney, Australia 4 6 December, 2007 Development of the Navigation Payload for the Galileo In-Orbit Validation (IOV) Phase G.T.A. Burbidge EADS Astrium Limited, United Kingdom (tel), (fax), geoff.burbidge@astrium.eads.net ABSTRACT The development of the Navigation Payload for the Galileo In-Orbit Validation (IOV) phase is now well progressed. The Payload prime contract is the responsibility of EADS Astrium Limited, Portsmouth, United Kingdom. This scope of this paper is to provide an overview of the IOV Payload design and report on the status of the development that will deliver this element of the Galileo system infrastructure. By describing the Payload requirements and the ensuing architecture, the critical technologies, the key design issues and the programmatic environment, this paper demonstrates the factors that have influenced the IOV Payload development. The IOV Payload has a legacy from the Galileo In-Orbit Validation Element (GIOVE) Payloads, which provided a test bed for some of the key technologies. The areas where there has been an evolution in functionality and design from GIOVE are described. The specific Payload functional breakdown and architecture for the IOV phase is presented. The paper also summarises the physical implementation of the Payload, including the heritage on which the Payload design is built. The practical issues of Payload accommodation within the satellite are illustrated, together with the configuration in which the spacecraft are deployed as part of the overall space segment. The design, manufacture and verification of the IOV Payload follows a classical satellite subsystem development lifecycle, requiring a model-based development philosophy. There are also a number of technical and programmatic factors that have become important drivers on the Payload development, and these issues are discussed. The design of the IOV Navigation Payload is now fixed. An optimised

2 design for the IOV phase has been baselined, design reviews are progressively being completed, redesigned hardware is being qualified, and programme risks are being mitigated. The paper concludes with a discussion of factors that will influence the evolution of future Navigation Payload designs. KEYWORDS: Payload, IOV, Galileo, Navigation, Astrium 1. INTRODUCTION The deployment of the Galileo system requires the development of a navigation payload that will provide the specified Galileo signals and services. Over the last decade there has been a gradual evolution in Europe s capability to design and build the critical technologies that are required for the development of Global Navigation Satellite Systems (GNSS) infrastructure. There is also a considerable body of practical experience in the development and implementation of augmentation navigation payloads. However, the Galileo payload developments represent the first time that a generative navigation payload has been designed in a European context. The building blocks of the current IOV Payload development have been established through the framework of the European Space Agency (ESA) Galileosat programmes. A series of studies and technology pre-developments were initiated, which defined the technical requirements and design concepts that would ultimately evolve into the current system baseline. Throughout this period, and encouraged by programmes sponsored by ESA (and others), a significant industrial capability has developed. The process whereby the IOV navigation payload design has been consolidated is described within this paper. This is presented by reviewing: the background to the current IOV programme and the corresponding payload developments the critical technical requirements that have been specified on the payload the resulting payload architecture and implementation that has been baselined the key design issues and drivers that have influenced the payload development the design and development approach that has been adopted for the payload and its constituent equipments the evolutions that can be anticipated for future navigation payload designs The design of the IOV payload is currently mid-way though the phase C/D stage of the development lifecycle. At this point in the development a technical design baseline has been established, all technical specifications have been derived, budgets have been established, and supporting analyses have been completed which provide confirmation of predicted payload performance. The payload equipment hardware and software is under development and is gradually being flight qualified, progressively mitigating any remaining risks in each element of the Payload architecture. Detailed planning for the validation and testing of both equipments and the payload itself, is currently being defined. The objective of this paper is report on, and thereby demonstrate, the considerable undertaking which is being made to develop the Galileo IOV Payload describing both the architecture and the development issues that have been encountered and to highlight the design challenges that this programme presents.

3 2. IOV NAVIGATION PAYLOAD DESIGN 2.1 Background The Galileo programme and the development of its payload have a history which can be tracked over the last decade. The project was initiated in 1998 as a joint initiative between the European Union (EU) and ESA. The programme has followed the classical Phase A (feasibility), Phase B (preliminary definition), Phase C/D (detailed definition, production / ground qualification testing) development lifecycle that is typical of any newly conceived mission. The definition of the Galileo mission and system requirements was iterated during the initial system studies that were performed in the late 1990 s. This established the baseline concept and initial definition of the system, segment and payload-level elements, culminating in series of Phase B studies. It was within this overall programme framework that the requirement for the development of three infrastructure elements was established. The space segment infrastructure for Galileo would be deployed in 3 phases: Galileo System Test Bed (GSTB) the development of test bed satellites for frequency filing, assessment of in-orbit performance, and demonstration/validation of critical technologies Galileo In Orbit Validation (IOV) Phase the development and validation of the first four operational satellites in the constellation Galileo Full Operational Capability (FOC) Phase the build and validation of the remaining (26) satellites required for the full operating constellation Many of the required navigation payload technologies that were/are integral to each of these phases were conceived as part of space segment predevelopments that were sponsored by ESA. Elements of these technologies have featured in both the GSTB and IOV payloads. There were aspects of the payload-level design for each of these satellites that were oriented around the utilisation of these pre-development because of the risk mitigation they offered. Nevertheless, in parallel to the GIOVE development, the top-down system design work continued for IOV, with the specific technical requirements, performance analysis, budgets and design and development planning being consolidated during a phase C0 activity that was performed in 2004/5. ESA decided that the GSTB element would be contracted to two industrial primes Surrey Satellite Technologies Limited (SSTL) and Galileo Industries (GaIn) essentially as a risk mitigation measure at satellite level, but also to allow those equipment technologies that had been dual-sourced, to be flight proven. These two spacecraft would later be renamed Galileo In-Orbit Validation Element (GIOVE), resulting in GIOVE-A (SSTL) and GIOVE-B (GaIn). The current development status of the space segment elements of the programme (at October 2007) is as follows: GIOVE-A is operating in-orbit, having secured the frequency allocations required for Galileo after it was launched in December 2005 GIOVE-B is currently undergoing final spacecraft-level testing at ESA s ESTEC facility IOV spacecraft development is on-going with the next major milestones being payload and satellite Critical Design Review (CDR), and Engineering Model (EM) integration The Galileo IOV spacecraft comprises two main components: the payload and platform. The Payload comprises all of the navigation and search and rescue functionality required of the Galileo mission, whereas as the platform provides the satellite bus services (structural

4 support, power, thermal control, satellite control) required to sustain the payload in a Medium Earth Orbit (MEO). The design of the spacecraft is being undertaken such that the payload and platform are being developed, integrated and validated in parallel, under the control of a set of complementary technical specifications. These two components are first brought together at spacecraft-level. The overall spacecraft contract (which includes all platform subsystems) is responsibility of Astrium GmbH (Germany), where as the payload subsystem prime contract is the responsibility of Astrium Limited (UK) as shown in Figure 1. Galileo In-Orbit Validation Phase C/D/E1 Customer European Space Agency System Prime European Satellite Navigation Industries Ground Control Segment (GCS) Prime EADS Astrium UK Space Segment (SSEG) Prime EADS Astrium D Ground Mission Segment (GMS) Prime Thales Alenia Space F Test User Segment (TUS) Prime Thales Alenia Space F Payload Prime EADS Astrium UK Figure 1. Industrial Structure for IOV Phase C/D/E1 Activities 2.2 Requirements specified at Payload-level The technical requirements for the IOV Payload are conceived in response to the specified requirements that the overall Galileo system to provide the following services: Open Service (OS) providing open access signals with positioning/timing performance comparable with other GNSS systems Commercial Service (CS) enhancing the OS by providing supplementary integrity data to report on service quality, with a minimum level of service guaranteed Public Regulated Service (PRS) providing two additional encrypted signals which facilitate enhanced accuracy, also providing guarantees of a minimum level of service Safety of Life Service (SOL) providing positioning/timing signals with a high continuity of service and controlled access, utilising the PRS navigation signals with encrypted ranging codes Search and Rescue (SAR) Service providing forward link and return link signals that contribute to the Medium Earth Orbit Search and Rescue system (MEOSAR) Of course, the provision of these services by the system is entirely the product of the generation of the F/NAV, I/NAV, C/NAV and G/NAV signals and message types by the IOV payload. This highlights an important point: that it is the payload element that is at the heart of the Galileo system. Those technical requirements imposed at payload-level are derived through a specification hierarchy that has its source at mission-level with an overall Mission Requirements Document (MRD), which encompasses the service requirements described above. These requirements are analysed and flowed down through the various levels of the system, generating a corresponding Space Segment Requirements (SSREQ), Satellite Requirements Document (SRD), and Payload Requirements Document (PLREQ). It is these payload requirements that define the navigation performance/capability that Galileo offers.

5 In terms of responsibility for the Payload requirements, the PLREQ is defined by the space segment prime (Astrium GmbH) and defines all the technical requirements functional, performance and interface with which the Payload design and implementation must comply. As such, there are many system-level design issues have been considered and addressed at a higher layer of the project/industrial team, and at Payload-level the parameters specified are the derived requirements that pertain only to the Payload component in isolation from the rest of the system. This is consistent with the need to initially validate the performance of the Payload element during assembly, integration and test (AIT), prior to further on-ground verification at segment level. Therefore, at the highest-level, the IOV Payload is required to support a European GNSS, and a SAR Service, which is to be achieved by delivering the following functions: Providing a navigation service based on generative architecture Generating the reference frequency using high precision atomic clocks for which stability is continuously monitored Generating an on-board timing signal and navigation message, and modulating, upconverting, amplifying, and transmitting the L-band signal Providing the uplink of navigation data, integrity data and SAR return data via a dedicated C-band mission data uplink Providing an alternative facility for the uplink of mission data via the Platform Telemetry Tracking & Control (TT&C) S-band uplink Providing a transparent transponder which enables a SAR forward link which relays messages from UHF distress beacons to L-band Medium Earth Orbit Local User Terminal (MEOLUT) terminals Ensuring that the mission data uplink and PRS signal are protected to a classified level and separating these functions from the non-secure functions Providing appropriate Payload operations, control and telemetry in order to provide the required commandability and observability of Payload functions Providing sufficient redundant elements and associated switching to meet the required reliability and availability requirements specified for the Payload The IOV Payload is required to deliver transmitted navigation signals with characteristics that are compliant with the signal structure defined in Table 1. At payload-level the concept of services is not applicable and it is the generated signal parameters and message type that is critical, these signals then mapping to the respective Galileo services. Centre Frequency (MHz) Nominal Bandwidth (MHz) Multiplexing scheme E5 E6 L Alt-BOC (15,10) Interplex (CASM) Interplex (CASM) Service Type OS SOL PRS CS PRS SOL Sub-signal E5a-I E5a-Q E5b-I E5b-Q A B C A B C Sub-modulation Signal/Message Type BOCc (10, 5) BPSK (5) BPSK (5) BOCc (m,n) BOCs (1,1) F/NAV I/NAV G/NAV C/NAV G/NAV I/NAV BOCs (1,1) Table 1. Requirements for Signal Structure on IOV Payload

6 The specific technical requirements on the IOV Payload (embodied in the PLREQ) include many important parameters, which cannot be summarised herein. Amongst these are critical signal generation performance requirements that include: requirements on Effective Isotropic Radiated Power (EIRP) which scale the required level of amplification, gain (and losses) in the payload RF output section requirements that EIRP to be adjustable in specified steps during system operation requiring that payload includes a selectable level of attenuation within the RF output section stringent Galileo requirements for satellite onboard time to be kept closely synchronised with the absolute Galileo System Time (GST) resulting in requirements for high precision onboard atomic clocks specific requirements on the frequency stability of the reference clocks which is at the core of the overall performance of this timing payload demanding requirements on those parameters which contribute to overall payload signal distortion and thereby also navigation performance Group Delay Stability, S-Curve Bias and Correlation Loss There are many other important aspects of functionality and performance that characterise the IOV element, and hence which distinguish it from the GIOVE payloads that preceded it, which include requirements such as: the requirements to operate with a hydrogen maser as a primary clock with a rubidium clock in warm-redundancy the specification of the modulation requirements the requirements for a flexible signal modulation scheme the encryption requirements that control access to the CS the latency requirements for dissemination of global/regional time-critical integrity messages the availability requirements on the payload, specified in terms of output feared events the reliability requirements on the navigation payload the operational requirements for performance over the mission lifetime These are a selection of requirements which provide examples of where there were some notable technical differences between the IOV and GIOVE payloads, but the list is not exhaustive. Where these requirements have implications for the payload architecture, or they invoke changes to the detail of the payload design, this has clearly resulted in additional development, qualification and testing. Of course, each of these requirements also creates additional systems design, analysis and validation effort at payload-level in order to ensure compliant performance. Hence, is it readily apparent that comparisons between the IOV and GIOVE payloads must not be made unless it is clear that they are being compared against a common set of requirements.

7 2.3 Payload architecture and implementation The section of the paper describes the baseline functionality, architecture, design and implementation of the IOV payload. The payload-level architecture is introduced by providing description of the environment in which the payload operates. Then, the different functional areas of the payload are detailed in turn. Any critical technologies and design issues in each area are described, and the physical accommodation and layout of the payload hardware is presented. The IOV payload operational environment comprises the external interfaces shown in Figure 2. These comprise: the SAR distress signals on the UHF uplink from SAR beacons the navigation mission data and integrity data C-band uplink from the Ground Mission Segment (GMS) providing periodic navigation messages, integrity updates and SAR Return Link Messages (RLM) to the payload the integrity data C-band uplink from the External Regional Integrity System (ERIS) providing periodic integrity updates to the payload transmitted on up to 5 ERIS signals the relaying of SAR distress signal by transmission on the L-band downlink which is received by one or more MEOLUTs the transmission of the navigation signals (E5, E6, L1) comprising navigation and SAR message packets on the L-band downlink which is received by either user receivers or beacons capable of receiving SAR RLMs the on-board interface to the Platform Integrated Control and Data Unit enabling the receipt of telecommands (TC) from, and transmission of telemetry (TM) to, the ground Figure 2. IOV Payload Operational Environment In order to provide these external interfaces the IOV Payload is conceived around a functional breakdown as illustrated in Figure 3. This functional architecture is a logical consequence of the services, signals and interfaces that have been described earlier key points being that: it constitutes a navigation payload and a SAR payload that are essentially separate the clocks provide a common reference signal for the C-band Mission Receive, the Navigation Signal Generation and Search and Rescue functions a payload-level security unit exists to provide decryption of classified commands and data

8 This results in some notable variations from the GIOVE payloads which did not feature either a C-band mission uplink (navigation data provided via the platform S-band TT&C interface), any security functions, or a SAR capability on account that they were not conceived as elements of an operational system. Figure 3. IOV Payload Functional Breakdown These functions map directly to the physical hardware of the payload, with each functional area implemented by one or more item of equipment/unit hardware. To represent this, the Payload functional block diagram can be elaborated to show the specific equipments within each functional area as shown in Figure 4. As can be seen in this diagram the payload comprises the following manifest of equipments (all single units unless stated otherwise): Passive Hydrogen Maser (PHM) 2 off Rubidium Atomic Frequency Standard (RAFS) 2 off Clock Monitoring and Control Unit (CMCU) Mission Antenna (MISANT) C-band Mission Receiver (MISREC) Payload Security Unit (PLSU) Navigation Signal Generator Unit (PLSU) Frequency Generator and Upconverter Unit (FGUU) Navigation High Power Amplifiers (NAVHPA) 3 off for L1, 2 off for E5, 2 off for E6 Output Filter/Multiplexer (OPF/OMUX) 2 off OPF for L1, 1 off for E5/E6 L-band Navigation Antenna (NAVANT) Search & Rescue Transponder (SART) Search & Rescue Antenna (SARANT) Remote Terminal Unit (RTU) In addition to the additional equipments associated with the C-band Receive and Security sections, and the SAR payload, the IOV payload digressed from those for GIOVE-A and GIOVE-B in regards to: a) the NSGU-FGUU implementation driven by the more stringent signal performance requirements b) the NAVHPA architecture and implementation driven by the higher power requirements c) the NAVANT design driven by the more exhaustive coverage and gain requirements

9 Figure 4. IOV Payload Block Diagram The Reference Clock Section of the IOV Payload is equipped with highly stable Hydrogen maser and Rubidium clocks that provide a reference (characterised by an extremely small drift over time) that is used by all onboard units that either need to be synchronised or which need a precise timing reference. Each PHM or RAFS provides a 10MHz signal to the CMCU. One PHM and one RAFS are active during nominal in-orbit operations. Due to its better longterm stability, the PHM is used as the prime frequency source feeding the CMCU. The RAFS acts as a warm back-up frequency source. The other 2 clocks act as cold redundant units, as a contingency for any clock failure during mission life. Both clocks require a significant warmup period, as much as several days to reach the full frequency stability. This, and the significantly higher power consumption of the PHM relative to the RAFS, is the reason for the warm redundant architecture between PHM1 and RAFS1. The CMCU synthesises two 10.23MHz frequency references, using an oven-controlled crystal oscillator (OCXO) slaved to the 10MHz signal from the respective atomic frequency standard. The CMCU also provides a measurement of the phase difference between the two 10.23MHz reference signals so as to the enable the RAFS frequency stability performance to be continuously monitored against the PHM. Thus, the Reference Clock facilitates generation of a reference signal for which both the short and long-term frequency stability is maintained the CMCU internal OCXO providing short term frequency stability and the atomic frequencies standards providing long term frequency stability. The function of the C-band Receive Section is to receive navigation message data via the C- band Mission Data uplink from either the GMS or any of the ERIS ground stations. The Payload must be able to simultaneously receive up to 6 spread-spectrum CDMA uplink channels (GMS + 5 ERIS stations). The input stage of the C-band Receive Section is the MISANT, which provides a global fixed Earth-coverage beam for the reception of uplinked right-hand circularly polarised (RHCP) signals in the 5000 to 5010 MHz frequency range. The active element is the MISREC which accepts a single RF input from the antenna,

10 generates mission uplink PRN codes (to despread and demultiplex the received CDMA signals into 6 channels), recovers and track each carrier and demodulates each channel. The MISREC also decodes the convolutional encoded symbol stream and resolves the nodesymbol ambiguity, synchronises and de-scramble the frames, in order to separates the integrity messages from mission data sub-frames, and ensuring priority management of respective frames. The final function of the MISREC is to process the packets of all 6 channels to provide one output data stream comprising integrity and navigation message data on a single serial interface to the PLSU. The Payload Security section comprises the PLSU, which applies an authentication check to the data received from the MISREC prior to further dissemination to the Payload s Navigation Signal Generation section. As such the PLSU acts as a firewall for the C-band mission uplink during nominal operations. The PLSU features a compatible serial RS-422 interface at both input and output, and outputs the authenticated mission data via a serial RS- 422 interface to the NSGU. The PLSU also provides PRS code generation so that during nominal operations, navigation Pseudo Random Noise (PRN) codes are generated within the PLSU for the PRS service on the E6-A and L1-A sub-signals. This code generation process uses a cryptographic algorithm stored in the PLSU together with the relevant PRS PRN keys, with the PLSU output interfaces driven by clock signals provided by the NSGU. All aspects of the PLSU operations are controlled by secure telecommand. The core of the IOV payload, is the Navigation Signal Generation section, which is responsible for taking the 10.23MHz reference signal from the Reference Clock Section and the mission data signals from the C-band Receive Section as inputs, to generate the L-band downlink navigation broadcast signals. Two hardware units provide the Navigation Signal Generation function: the NSGU and the FGUU. The NSGU provides baseband processing to generate the required navigation signals for E5, E6 and L1, which are output at intermediate frequencies (IF) to the FGUU. The signals each contain up to four separate signal components that are allocated either as data or pilot channels and are multiplexed together in accordance with the modulation schemes specified in the Galileo Signal-In-Space Interface Control Document (SISICD). The NSGU provides for flexible modulation implementation, allowing for different multiplexing and modulation schemes to be used and selectable in-orbit. The FGUU receives the highly-stable MHz reference clock directly from the Reference Clock Section, synthesises a MHz local oscillator (LO) frequencies which is supplied to the NSGU, which in turn uses this signal to generate and send clock signals to the PLSU, to clock out PRS spreading codes, and to give the PLSU a pulse-per-second (PPS) signal and timestamps. The NSGU also uses the same MHz clock to provide the main digital sampling frequency for the synthesised output signals and derive other clocks internally at various frequencies, as required for the navigation signal modulation schemes. The FGUU uses these LO signals to upconvert the NSGU output IF signals to the required L-band frequencies for E5, E6 and L1 downlink transmissions. These RF outputs are then passed on to the L-band Output Section to be further amplified and transmitted. The L-band Output Section of the Payload takes the 3 L-band signal channels output by the FGUU and provides high-power amplification, filtering and transmission of those navigation signals over full-earth coverage. To provide the transmitted signals at the required power levels, dedicated output chains are used for each of E5, E6 and L1 channels. Each output chain consists of Solid State Power Amplifiers (SSPAs), followed by filters/multiplexers (OPF/OMUX) and finally feeds into transmitting elements in the NAVANT, which radiates the amplified signals over the required coverage area. One of the main drivers on front end

11 architecture is the transmitted EIRP requirements for the navigation signals, which results in an L1 channel HPA architecture where two SSPAs are arranged in parallel. The L1 output chain then employs two separate OPFs to filter the outputs of the two active SSPAs, with the filtered signals routed to dual L1 input ports at the NAVANT. The L1 signals entering the two NAVANT inputs are eventually combined in free-space, in the NAVANT radiation pattern. For the E5 and E6 channels the EIRP budgets permit the use of a single active amplifier for each chain, the outputs of which at are subsequently combined in a single OMUX, and a combined E5+E6 interface is presented to the NAVANT. Note that the EIRP requirements specify both a minimum and a maximum power flux density on the ground, and this results in the need for a highly optimised beam pattern to be generated by the NAVANT. The Search & Rescue Payload provides the SAR forward link function acting as a transparent transponder receiving of UHF distress signals (406.05MHz) from SAR beacons, and conversion of the signal to L-band (1544.1MHz) for forward transmission to the MEOLUTs. The SAR Payload is implemented in an active and a passive element the SART and the SARANT. The SART performs the necessary low-noise amplification of the received low power UHF signal, frequency up-conversion, RF power amplification and filtering of the L-band signal. The SART uses the 10.23MHz frequency reference from the CMCU to synthesise the required LO frequencies for the frequency conversion. The SARANT consists of both the UHF receive antenna and the L-band transmit antenna elements which both provide the required gain to be compatible with the required Rx/Tx signal levels, again with full-earth coverage. The Payload Command & Control (C&C) section provides the primary C&C interface between the payload and platform. There is a single dual redundant MIL-STD-1553 bus interface from the Platform ICDU to the PLSU and NSGU (with which there is direct interface) and also the RTU. The RTU acts as a bridge/router for between the ICDU and payload equipments Telemetry/Telecommand (TM/TC) interfaces. The combination of the 1553 bus interface and the RTU provides equipment ON/OFF control, discrete status monitoring and control of the RTU, discrete command and control of payload equipment, and direct command and control of the PLSU and NSGU via the 1553 bus. Most of the payload equipments are designed with the integral redundancy to fulfil reliability requirements and to ensure compliance with demands for operational availability and performance. Hence all those equipments shown in Figure 4 incorporate nominal and redundant sides internally, with the exception of: the clocks, where a PHM acts as the primary clock, with a RAFS available as a warm redundant back-up, with additional cold redundancy at unit level of both clock types all payload antennas, which, as large, passive equipments provide neither scope or justification to implement any redundancy the NAVHPAs, where the SSPAs are arranged in a 1 active + 1 redundant configuration (for E5 and E6 channels), and 2 active + 1 redundant (for L1) the SART, for which a non-redundant architecture is defined

12 The Payload architecture and implementation described above is accommodated within a structure that is the responsibility of the spacecraft prime contractor. The physical configuration of the spacecraft is a rectangular box shape subdivided internally into three bays by two internal stiffening panels. This arrangement is formed from two separate but interlocking panel sets, which serve as the platform and payload modules. For logistic and accessibility reasons these two modules are first assembled and functionally tested independently, during initial integration. Payload and platform equipments are separated onto their respective panel sets. The payload module itself comprises four of the spacecraft panels in an open box configuration, as shown in Figure 5. Payload equipments are located on the internal surfaces of all these panels, and the Payload antennas are mounted on the external face of the +Z panel. In orbit, the +Z panel will be the Earth-facing panel, whilst the +X panel will be permanently shaded. The +Y and Y panels are well suited for radiating internal heat, as they experience negligible solar input and are subject only to radiated heat inputs from the solar arrays. +Xs +Xs +Ys +Ys +Zs +Zs Figure 5. IOV Payload Configuration and Layout The IOV spacecraft, incorporating the Payload element, is deployed into its operational orbit on a Soyuz launch vehicle. The four spacecraft in the IOV complement will be launched in pairs into different orbit planes. For this dual launch configuration (and all other deployment concepts) the spacecraft is structurally connected to the launcher via an interface on the Z plane to a launch adaptor.

13 2.4 Payload design drivers There are many technical and programmatic drivers on the payload design that are too numerous describe herein. One of the most significant constraints is a consequence of the dual launch configuration (see Figure 6), which creates some demanding mass requirements and dimensional constraints, factors which were not major drivers on the design of the two GIOVE spacecraft, which both benefited from dedicated launch. The spacecraft level design for IOV apportions a mass budget allocation to the payload of 148kg, and this together with the accommodation envelop in the Soyuz fairing also imposes some direct limits on the physical size of equipments such as the NAVANT and SARANT. The overall mass limitations also indirectly impacts on the payload, through the constraints that this imposes on the design platform power subsystem, and in turn, the maximum power consumption budget (900W) available to the payload. Coupled together, these factors are a major driver on the L- band Output Section, providing constraints on how the specified EIRP can be achieved, dictating the level of RF power generation and losses in the output chain. Figure 6. IOV Spacecraft Launch and In-Orbit Configuration Stringent requirements on the critical parameters of the navigation signal such as group delay, S-curve bias and correlation loss, introduce drivers on signal distortion and stability in both the Navigation Signal Generation and L-band Output sections. This requires that the designs of the key equipments be either insensitive to, or compensate for, the temperature variations to which the Payload will be exposed on-board. Of course, this inherently requires a high degree of thermal stability to be provided by the platform (which is responsible for overall thermal control), as is illustrated by the requirement that the PHM and RAFS must be kept to within ±1 C over the orbit. The navigation signal bandwidths and the strict spurious requirements that are specified also create some demanding filtering requirements, which are a feature in various elements of the design. Other important parameters for the Payload design include the very low signal level of the UHF signals from SAR beacons, which becomes a significant driver on the overall EMC design. Also, the radiation environment for the Galileo orbit is more severe than for low Earth orbit or geostationary orbits, and this had resulted in design changes for some equipments to ensure confidence that the payload will meet the reliability requirements over the specified lifetime, which at 12 years is a significant increase over the 2 year period that was required of GIOVE.

14 There are also many programmatic factors that have influenced the chosen architecture for the IOV payload. Whereas the payload design for GIOVE was largely fixed as a consequence of the equipments being customer furnished items (CFI) from ESA, for the IOV programme industry is responsible for most of the procurements (the main exception being the SART from China). Nevertheless, the legacy that already existed from the design of previous equipments first as technology developments and then as flight equipments for the GIOVE missions meant that some architectural decisions were strongly favoured. For example, use of the existing hydrogen maser and rubidium clock technologies, and the utilisation of the SAR antenna pre-development, as well as taking benefit from many elements of the existing signal generator and navigation antenna designs that were already in place. In addition, as with many European space programmes that are collectively financed by subscribing member states, there was also the criterion of geographic return to be considered and balanced across participating nations. This also created some constraints when potential alternative architectures were first conceived. Similarly, the compelling factors of cost, risk and schedule were a significant influence on the design options at both payload and equipment-level and which exerted strong pressure against a radical design optimisation for IOV. However, despite all the programmatic drivers, the technical specification for IOV has continued to be paramount, and a design has been derived which endeavours to provide a fully compliant response to the payload requirements. As such, the IOV payload architecture and implementation still represents a significant evolution from the earlier designs. 2.5 Payload development approach It has been explained that the IOV payload contains a mixture of equipments with varying degrees of development heritage some which have been proven through their use on the GIOVE payloads, and others which have been subject to pre-development under other programmes, and for which there is no previous flight history. There are also a number of equipments that have been adapted from other designs for which there is a significant legacy. The core issue for the IOV payload development however, is the identification of the major oustanding areas of technical risk, and the definition of an appropriate development and qualification programme that adequately mitigates that risk. A standard categorisation for the design maturity of flight hardware is defined in ESA space systems engineering standards [1]. This specifies four categories (A through D) with regards to the required development approach and model philosophy, ranging from off-the-shelf equipment requiring no modification (A), through to newly designed and developed equipment or existing equipment requiring major re-design (D). As has been described herein, the nature of the IOV payload requirements and the resulting payload design baseline and equipment implementation is such that many of the major payload equipments fall into a category for which either minor or major re-designs are required. Therefore most equipments are subject to either delta or full qualification test programmes. The payload development lifecycle therefore features Engineering Qualification Models (EQM) of most equipments and an Engineering Model (EM) payload, followed by Protoflight-models (PFM) of the equipments, which are integrated into a PFM payload. The PFM build will become the first Flight Model (FM1), and will be followed by FM2, FM3 and FM4 builds of equipments and payloads. Equipment and payload Preliminary Design Reviews (PDR) and Critical Design Reviews (CDR) are phased through the development.

15 2.6 Evolutions for future Navigation Payloads The main influence on future navigation payload designs in Europe will be the deployment and maintenance of the Galileo constellation. However, for the initial tranche of FOC infrastructure, it will be programmatic factors that dominate the design options. With the Galileo programme under heavy political pressure due to schedule delays and cost overruns during the initial phases, the focus for the first batch of FOC payloads will achieving be increased efficiencies in manufacture, integration, test and validation. Significant benefits are anticipated from the experience gained on the IOV programme, and it is lessons learned during this period that will be used to explore alternative payload solutions for FOC. Over the longer term, FOC may follow a similar model to that adopted in the U.S. for the procurement of GPS that as the space segment infrastructure matures and begins to require replenishment, new blocks will be deployed which will feature step-wise enhancements in performance and functionality. Some of these potential evolutions are currently being studied within the frame of ESA s European GNSS Evolution programme, which is examining future navigation system and payload architectures that could feature in subsequent upgrades to the initial Galileo system. Amongst the ideas being considered are the development of alternative atomic clock technologies, payloads capable of on-board self-equalisation for signal distortions, and the potential utilisation of active downlink antenna arrays. However, it is anticipated that one of the general areas of future development in this area will be for an increased level of physical integration of the existing functionality to enable more a compact and performant navigation payload capability. Astrium Limited will continue to support and partner with ESA in the development and implementation of the next and future phases. 3. CONCLUSIONS The development of the Galileo IOV payload development is advancing and progressing well. As an operational element of the Galileo system, a payload design has been derived which is optimised to the specified technical requirements, but with due consideration of programmatic constraints. As such, there are many critical requirements that scale and drive the payload design and make it substantially more complex that the GIOVE payloads. Nevertheless, the payload implementation does takes significant benefit from existing hardware developments that were already available, although this has required a significant payload-level systems engineering effort to reorient these designs to ensure full compliance with IOV requirements. Hence, additional development and qualification has been required, and a variety of EQM, EM and PFM builds are necessary in order to mitigate the resulting risks and ensure a high level of confidence for the FM integration. Despite this, the IOV phase of Galileo is only the beginning, and the development and deployment of the overall constellation through the FOC phase will present more challenges for the development of future navigation payloads. ACKNOWLEDGEMENTS ESA and the EU must be acknowledged in their role as the customers who have financed the IOV programme and as the owners of the intellectual property for this development. REFERENCES [1] ECSS-E-10-02A, Space Engineering Verification, 17 November 1998