This chapter describes the approaches and the methods defined for the design, development and verification of the GG satellite. An outline of the programme logic, development and verification approach for the complete satellite is included. The approach described below is the baseline for the satellite programme cost estimate.

8.1.1  Programme Logic

The GG Design and Development will be implemented in a Definition phase and in a Development and Production phase, i.e. respectively at Phase B and at Phase C/D. Phase B includes the definition of the GG flight system and its relevant support equipment and the finalization of the System and Payload design. Phase C/D includes the detailed design, the development, production, verification and delivery of the GG flight Satellite with the Payload installed on it, the associated support equipment, and the launcher adapter.

The satellite-level programme (as opposed to the payload, which is unique and needs a dedicated, lower level programme) will be matched to that of the Prima bus, insofar as applicable; this exercise will be done as soon as guidelines for the Prima development are published. Within the two major phases, the GG project will be executed in distinct steps with clear milestones checking the successful execution of one step and thus authorizing commencement of the next step. Generally, phases B and C/D are divided in several sub-phases which have their own technical content and are closed with specific reviews. Typical project system sub-phases are:

• System Definition
• System Design
• Detailed Design
• Manufacturing
• Qualification
• Acceptance
• Pre-launch.

The System Technical Reviews are:

• System Requirement Review (SRR)
• System Design Review (SDR)
• Critical Design Review (CDR)
• Qualification Review (QR)
• Flight Acceptance Review (FAR)
• Launch Readiness Review (LRR)

8.1.2  Development Approach

The GG Satellite development and verification will be based on a simplified Protoflight approach in which only one complete satellite model is manufactured and assembled at flight standard. Furthermore, given the heritage from the PRIMA bus, functional tests at the subsystem level are not included in the programme, the subsystem verification being performed at system level in the frame of the integration and system tests.

On the other hand, at payload level (PGB with test masses and dedicated control computer driving the active damping and drag-free control) both a Structural-Thermal Model and Development Model are planned. The purpose of such models is to verify the mission specific functionalities separately, thus avoiding adverse impacts on the system level programme.

The STM, representative of the structural and thermal behaviour of the payload module, will be subjected to a test and validation campaign whose main purpose is to validate and refine the mechanical and thermal mathematical models. As a result, simulations of the P/L performance will provide more accurate predictions. Moreover it will be possible to perform experiments on critical mechanisms, such as the lock/unlock devices.

The Development Model will be a breadboard, functionally representative of the entire payload module, and will be subjected to a validation campaign consisting of functional and electrical tests. The main purpose of this model is to debug well in advance the design of critical items and verify the integration of the relevant software (active damping and drag-free control running in the payload computer). The basic building blocks of the DM are already being assembled as part of the GGG laboratory prototype (see Chap. 3). In this way the programme C/D phase can start with the most critical aspects of P/L design already verified.

At system level, the verification of the functional and software interfaces between the payload module and the system will be performed on the Protoflight Model, replacing the development models with the flight standard equipment and reusing the payload model EGSE.

Model Philosophy. Based on the above criteria, a GG model philosophy has been developed that (a) minimises the hardware (number of models) in the interest of cost and schedule effectiveness, (b) minimizes the development risk by decoupling the activities at the level of the Service Module and Payload Module. Hence, three verification levels are planned, at Equipment level, Payload level and System level, as shown in Fig. 8.1.

Hardware Matrix. Table 8.1 shows the hardware matrix of the spacecraft equipment. The equipment heritage from the Prima bus is shown in the last column. (Note that, as far as cost is concerned, FEEP thrusters and FEEP electronic unit are included in the payload cost).

Legenda: O = Off-the-shelf M = Modified Design N = New Design

Table 8.1 Hardware Matrix

8.1.3 Verification Approach

The methods which accomplish the verification of the applicable requirements are, in agreement with consolidated standards, Analysis (including similarity); Test; Inspection; Review Of Design. In general, test is the preferred one, but analysis and other methods can be used in lieu of it if test is not possible or the effort of it is unacceptable with respect to cost and/or schedule constraints.

In line with the verification approach and the model philosophy presented above, a coherent GG integration and test programme will be implemented. As anticipated, some of the verification activities will be performed at lower level, i.e. Experiment (PGB) and equipment, providing in this way a good decoupling of the activities.

The integration and test activities at Satellite level are described below. Table 8.2 shows a summary of the tests performed at Satellite level.

Table 8.2 System PFM Tests

Protoflight Model (PFM). The system PFM is the satellite flight unit. The PGB will be integrated on the GG service module and then the avionic units and the payload electronic units will be integrated to reach the flight configuration and to perform the system protoflight test campaign before shipping to the launch site.

During the integration of the equipment onto the service module, interface checks, mechanical and electrical, and bonding measurements will be made to verify the adequacy of the assembling. Having completed the integration, subsystems and PGB functional tests will be performed to verify the related functionality, operative modes and the communication between them. At the end an Integrated System Test (IST) will be accomplished to verify the functions and performance of the system.

The IST will be re-executed at the end of the environmental test campaign to detect any degradation of the system. Furthermore, to detect system degradation, if any, during the environmental test and to perform a trend analysis of the main system parameters, a reduced system functional test (Integrated System Check) will be performed after the EMC and Acoustic test.

The tests will be performed using the system EGSE which allows to acquire the telemetry, generate telecommands, simulate and test the EPS, simulate and stimulate the Attitude sensors and actuators, to simulate the satellite dynamics, kinematic and external environment to perform AMCS closed loop tests, simulation and test of PGB, on board SW up/down loading and testing, test of TT&C and archiving of test data.

After the functional/performance (limited) tests the environmental test campaign will be executed. It will consist of:

• Mass Properties Measurement, in order to verify the mass, inertia, centre of gravity and balancing of the satellite (Spin Balance Test). If necessary, suitable balancing masses will be mounted on selected locations to recover any possible centre of gravity deviation and unbalance. If the spin balance test is done with an empty tank, a correlation with the analytical model (tank full) shall be done.
• Acoustic Test, in order to verify that the satellite can withstand the acoustically induced vibration environment encountered during all mission phases. All spacecraft subsystems which will operate during the launch shall also be operated and monitored during the test.
• Separation Shock Test, to demonstrate the capability of the satellite to withstand the shock levels and frequency spectra due to the launcher separation, i.e. firing of the pyrotechnic devices. Before performing the test, the Launcher I/F fit check will be performed.
• Antenna Deployment Test, in order to check the mechanical deployment of the bottom antenna. The test will be performed after each environmental test.
• Thermal Vacuum/Cycling Test, in order to demonstrate the ability of the satellite to meet the operational requirements under space environment and at temperature extremes which simulate those predicted plus acceptance margins. Moreover this test will detect, if any, materials, process and workmanship defects that could occur under thermal vacuum and thermal stress conditions.

• Electromagnetic Compatibility Test . The EMC test will be performed to verify both the external compatibility with the launcher and the launch site and the internal compatibility, and to asses the EMC safety threshold (6 dB). During the test the satellite will operate in the modes of operation used during flight. Both conducted and radiated emission and susceptibility tests will be performed. DC magnetic emission test and the magnetic cleanliness will be accomplished in order to verify the compliance with the applicable magnetic requirements

All the environmental tests will be performed with the PGB in locked condition. Hence, a strong effort must be done to correlate by analysis the tested configuration, i.e. PGB locked, with the flight configuration, PGB unlocked, both in terms of satellite balancing and thermal behaviour. At the beginning and at the end of the environmental tests, alignment and leakage tests will be performed in order to trace any degradation of the system.

The compatibility between the Satellite and the Operational Control Centre (OCC) will be demonstrated by performing a System Validation Test (SVT) which will consist in the demonstration of the RF and data compatibility with the Ground Station and the OCC. A preliminary compatibility check with the Ground Station (RF compatibility) will be performed using a Satellite Suitcase which is a simulator able to receive/ transmit commands/ telemetry via RF.

The GG Ground Support Equipment (GSE) is the set of all hardware and software tools needed to support the satellite Assembly, Integration, Verification and Test (AIV&T) programme, in order to demonstrate that all requirements are met and all functions and performances are in accordance with the specifications. According to the different integration stages, the GSE comprises unit Test Equipment, Subsystem GSE and System GSE. Both Mechanical and Electrical GSE are necessary for the GG programme.

Mechanical Ground Support Equipment. The following MGSE items are preliminarily identified.

1. Transport containers for the units, the integrated payload (PGB) and the satellite. Special containers with shock absorbers and shock gauges are to be used for the integrated PGB and satellite, to minimize the risk of damage.
2. Lifting and support devices to move the satellite within the integration and test facilities and to simplify unit installation and de-installation.
3. Protective covers for the contamination-sensitive and safety-critical parts such as solar panels, antennas, thrusters.
4. Special facilities for mechanical measurements: physical dimensions, mass, moments of inertia, centre of gravity, balancing, alignment.

Reuse of payload MGSE items 1-3 in the system programme is envisaged. Use of standard PRIMA MGSE for the measurements listed under item 4 will be pursued as far as possible.

Electrical Ground Support Equipment. At least the following EGSE items are necessary for the electrical AIV&T:

1. Satellite check-out equipment (system EGSE)
2. Payload EGSE (Pico-Gravity Box and payload electronics)
3. On board data handling, power and TT&C EGSE
4. Unit Testers for attitude sensors, PCDU, battery, transponder, gas thrusters and FEEP.

The System EGSE will be used to support the integration and verification of the satellite up to its final flight configuration, and also to support the integration and test of the satellite with the launcher and the launch campaign. The following functions will be implemented:

• Acquisition and monitoring of telemetry data
• Generation of telecommands
• Simulation and test of the power subsystem and its equipment
• Simulation and test of the attitude sensors and actuators
• Test of the Integrated Control System
• Simulation of spacecraft dynamics and environment for AOCS closed loop test
• Simulation and test of the payload
• On board software up/down loading and testing
• Test of the TT&C subsystem
• Archiving of test data for post processing
• Development and execution of test software (test sequences) and a test data base
• Presentation of test data to the test engineers via suitable man-machine interface.

All of the above functions are standard and therefore assumed to be implemented in the PRIMA EGSE (supplemented with the necessary mission-specific software). The same applies to subsystem EGSE (item 3 above) and unit testers (item 4), with the exception of the FEEP.

Payload EGSE is used to test the integrated Pico Gravity Box and its electronic equipment in a stand-alone configuration. A complete functional and performance verification not being possible on the ground, the PGB verification will be performed by analysis and simulations, based on the results of the GGG laboratory experiment. The PGB testing on the ground is therefore limited to the functionality of the electronics and the interfaces with the satellite Integrated Control System. The payload test equipment will perform the following functions:

• Simulation of primary power
• Generation of commands to electrostatic dampers, FEEP and inch-worms
• Acquisition of data from the sensors and the EP measurement chain.

A Unit Tester will be developed to test the FEEP when integrated with their control electronics and high voltage supply. It will include Unit Tester Controller, power supply, and input/output front end to generate commands and monitor the internal parameters (voltage and current monitors being used to compute the applied power and hence the thrust). The I/O front end will also be used at payload and system level to monitor the commands sent to the FEEP and permit closed loop tests.

8.3 Technological Requirements

The GG proposed design presented herein does not rely on any completely new technologies. Although many requirements of the GG payload are very stringent, they can be met by technologies and processes already existing in the commercial market, which will have to be refined for use in a space application.

The only exception is the Field Emission Electric Propulsion (FEEP); however, even in this case prototypes have already been manufactured and tested and complete qualification is ongoing under ESA contract. An orbital test of FEEP and their electronics is planned during a Shuttle flight within 1999/early 2000, hence compatible with the time schedule of GG. On the other hand, GG is likely to be the first satellite using FEEP for drag free control, a development that will be of great interest for future fundamental physics missions, such as LISA, thanks to the exceptional performance of these thrusters, in terms of linearity, throttling capability and propellant consumption.

A number of critical aspects of the project will be verified in the laboratory in the near future as part of the GGG programme (Galileo Galilei on the Ground, see Chap. 3), that can be regarded (besides having scientific objectives of its own) as a "technological" model of the P/L. However the complete flight experiment cannot be completely tested on the ground due to the earth’s gravity, which prevents the P/L from being suspended through very thin springs; therefore, some additional activities have to be carried out, prior to the construction of the GG flight model.

The proposed approach to such activities is based on a model philosophy including Structural & Thermal Model, Development Model and Protoflight Model, as described in Sec. 8.1.2.

A survey of the payload elements that may need advanced breaboarding activities, to avoid any risk in the satellite development programme, is presented below.

• The structural and thermal aspects will be tested on the Payload STM together with some critical aspects such as the lock/unlock mechanism. The main purpose of the structural test will be to validate the design with respect to the launch vibration environment. Relevant STMs will be developed for the new design items that need a qualification campaign with respect to the vibration environment, such as the PGB rods.