scope change traceability chapter 1 - proteus

PRO.LB.0.NT.003.ASC Issue. 06 rev. 03 Page: 1.1

All right reserved ALCATEL SPACE/CNESPassing and copying of this document , use and communication of its content is not permitted without prior written authorization

Chapter 1 : Scope

CHANGE TRACEABILITY Chapter 1

Here below are listed the changes between issue N-2 and issue N-1

N°§ PUID Change Status Reason of Change Change Reference

§1.3.3 Modified in useful TM data flow rate PUM.6.1.CG.06

§1.5 [SY - 1.5 - 1 a] Modified in STR cable introduction PUM.6.1.JC.1_1

§1.8.2 New in Introduced in J2 IISs PUM.6.1.EJ.32










§1.8.2 Modified in modified in J2 IISs PUM.6.1.EJ.32








Here below are listed the changes from the previous issue N-1N°§ PUID Change Status Reason of Change Change Reference

§1.4 [PL - 1.4 -3 ] New in Antenna boresight transfer matrix to beprovided

PUM.6.2.EJ.02



TABLE OF CONTENTS

CHANGE TRACEABILITY Chapter 1 1

1. Scope 51.1 PURPOSE OF PROTEUS USER’S MANUAL 51.2 SERVICES 8

1.2.1 PROTEUS STANDARD SERVICES 81.2.2 EXTENDED SERVICES 8

1.2.2.1 Specific adaptations 81.2.2.2 Payload Instrument Module 81.2.2.3 Payload 81.2.2.4 Launch vehicle procurements 81.2.2.5 Mission ground segment 81.2.2.6 In orbit operations 91.2.2.7 Full turnkey system 9

1.2.3 INDUSTRIAL SHARING 91.3 SYSTEM OVERVIEW 10

1.3.1 SYSTEM ARCHITECTURE 101.3.2 THE SATELLITE SYSTEM CHARACTERISTICS 111.3.3 GENERAL PLATFORM DESCRIPTION 131.3.4 PROTEUS MAIN CHARACTERISTICS 191.3.5 PROTEUS BASED SATELLITE MODES 19

1.3.5.1 Satellite OFF mode 211.3.5.2 Satellite Start-up 211.3.5.3 Satellite Test Mode 221.3.5.4 Satellite Safe Hold Mode (SHM) 221.3.5.5 Satellite Star Acquisition mode (STAM) 231.3.5.6 Satellite Normal Mode 231.3.5.7 Satellite OCM Modes (OCM2 and OCM4) 23

1.3.6 GROUND CONTROL SEGMENT CHARACTERISTICS 231.4 FRAMES AND SATELLITE AXIS DEFINITION 261.5 DEFINITIONS 321.6 UNITS, MODELS AND CONSTANTS 34

1.6.1 UNITS 341.6.2 MODELS 341.6.3 CONSTANTS 35

1.7 REFERENCE AND APPLICABLE DOCUMENTS 361.7.1 REFERENCE DOCUMENTS 361.7.2 APPLICABLE DOCUMENTS 371.7.3 STANDARDS 37

1.8 ACRONYMS 381.8.1 REQUIREMENTS ACRONYMS 381.8.2 OTHER ACRONYMS 38



LIST OF FIGURES

Figure 1.3-1: PROTEUS system architecture........................................................................................................... 11Figure 1.3-2 : Typical satellite based on PROTEUS ................................................................................................ 12Figure 1.3-3 : internal lay out of the PROTEUS platform........................................................................................ 13Figure 1.3-4 : PROTEUS platform overview ........................................................................................................... 14Figure 1.3-5 : PROTEUS functional block diagram ................................................................................................ 15Figure 1.3-6 : Payload data path.......................................................................................................................... 16Figure 1.3-7 : Telemetry flow................................................................................................................................ 17Figure 1.3-8: Satellite modes................................................................................................................................ 21Figure 1.4-1 : Local orbital reference frame.......................................................................................................... 27Figure 1.4-2 : Satellite Reference Frame (For information, JASON 1 Satellite: PROTEUS platform+JASON 1 specific

Payload) ....................................................................................................................................................... 28Figure 1.4-3: STA Reference Frame ...................................................................................................................... 30Figure 1.5-1 : Satellite architecture ....................................................................................................................... 33

LIST OF TABLES

Table 1.3-1 : Main data flows characteristics ........................................................................................................ 18Table 1.3-2: PROTEUS main characteristics .......................................................................................................... 19

LIST OF CHANGE TRACEABILITY

CHANGE TRACEABILITY Chapter 1 ........................................................................................................................ 1



LIST OF TBCs

.N° § Sentence Planned

Resolution

§1.3.2 The PROTEUS platform has been designed to be compatible with various orbits(phased, sun synchronous, frozen and inertial orbits) with altitudes ranging from500 km to 1500 km, for an orbital plane inclination contained between 20 (TBC)and 145 deg. Flight domain is detailed in chapter 2.2.1. Mission design support isprovided in paragraph 2.4.

§1.3.5.2 The satellite is powered, the receivers are ON (hot redundancy, not commandable,automatically ON at satellite powering) and the Reconfiguration Module (RM) iswaiting for separation strap disconnection. It is possible to send direct TCs (TCD) tocommand ON a Processor Module (PM) or modify the RM registers which define theon board configuration which shall be used after Umbilical Strap disconnection. If aPM is set ON, this PM will nominally detect the Umbilical presence and go to TestMode. Nominally, the payload is OFF. It is not powered or, in case of specialneeds, in a reduced way depending on launch phase (30 W maximum for 2 of the16 power lines which can be maintained ON (TBC) and which are not managedbut protected with a passive system (fuses) (see section 3.5.3)). Its thermal control isnot ensured by the platform and the satellite attitude is imposed by the launchvehicle.

§1.6.3 Orbit bulletin will be given in adapted parameters (a, ex, ey, i, Ω, α) in Veisreference frame (TBC) with

§1.8.2 TBC To Be Confirmed

LIST OF TBDs

.N° § Sentence Planned

Resolution

§1.8.2 TBD To Be Determined



1. SCOPE

1.1 PURPOSE OF PROTEUS USER’S MANUAL

The User

P roteus?

Chapter 1P roteus overviewP roteus servicesS atellite S ystem characteristicsP latform descriptionGround control segment

P roteusmissions panel?

Chapter 2.1,2.2,2.3,2.4orbit types,pointings,satellite orientations

launch vehicles possible with P roteus

missionparameters choice?

Chapter 2.5notions for mission analysis

P ayloadcompatible? Chapter 3

P ayload InterfacesR equirements

Chapter 4P ayload design and constructionrequirements

Chapter 7Ground segment functions,architecture,operations concepts, dataexchanges

For a first approach, thischapter could be skippedChapter 8Mission centre/Ground segmentinterfaces described in details

P roteus Ground segment ?

Chapter 9On board/Ground interfaces

On board/Ground interfaces?

S chedule, deliveries,documentation?

Chapter 10S chedule, deliveries,documentation fortypical P roteus mission

P ayload designrules?

Chapter 5P ayload environment requirements

P ayloadenvironment ?

Chapter 6P ayload verification andtest requirements

P ayload tests?



PROTEUS is a generic name for a multimission platform designed for low Earth orbits: « Plate-formeReconfigurable pour l’Observation, les Télécommunications Et les Usages Scientifiques ». This platform and theassociated ground control segment have been developed together by ALCATEL SPACE and the CNES .

This document is intended to be a reference manual which presents the general capabilities offered by thePROTEUS system. Indeed, its purpose is to allow a User looking for an efficient way to access space in low Earthorbits, to assess different mission profiles and solutions to achieve his objectives, to design User payloadcompatible with PROTEUS bus and launch vehicles, to build and verify his payload within the constraints imposedby the satellite bus and launch vehicles.

In order to do so, Chapter 1 gives an overview of the PROTEUS system and its main characteristics, so that theUser can easily evaluate the efficiency of this kind of concept for the baselined mission.

Chapter 2 is entirely devoted to PROTEUS capabilities and indicates the main mission options, grouping thepotential launch vehicles, achievable orbits, possible pointing modes, and different orbit types. The User can thendetermine the required orbit kind, main orbital parameters, pointing mode, and launch vehicle which arecompatible with the mission objectives.

Chapter 3 describes the interfaces requirements for a payload based on PROTEUS platform. For mechanicalthermal, electrical and command & control domains, the requirements at payload level are listed. The User,responsible for the payload (considered as one element) must read this chapter to check the payload compatibilitywith the standard PROTEUS platform.

This chapter deals with other interesting points for the authority in charge of the payload :

• the satellite operational features implying some constraints for the payload,

• the star trackers assembly accommodation as star trackers are laid out on the payload,

• the interfaces between the Ground Support Equipment (GSE) and the payload for the satellite integrationand alignment phase.

Chapter 4 defines mechanical, thermal, electrical and command & control requirements for payload design andconstruction.

Chapter 5 presents payload requirements due to the flight environment imposed by the chosen launch vehicle,the mission environment parameters (mission objective, orbit kind, mission date and duration). The listedrequirements are estimated taking into account the envelope of the launch vehicles compatible with PROTEUS;that means the flight and qualification levels for the payload, (and the satellite) could be reduced as soon as theconsidered launch vehicle envelope is restrained. In this chapter, payload requirements for ground operations,storage, transportation and handling phases are detailed too.

Chapter 6 lists payload design verification tests before payload delivery and briefly presents tests and verificationat satellite level.

Chapters 3, 4, 5 and 6 are a suitable baseline to tailor the payload requirements to the satellite bus ones. Thetailoring of these chapters to the studied mission is an efficient tool to gather the payload requirements, to writethe Payload Design Interface Specification and to identify very early the points needing a specific analysis.

Chapter 7 presents the generic ground segment for PROTEUS based satellites. This chapter describes thefunctions, the operations concepts and operational organisation, the architecture, the performances for theground control segment.

Chapter 8 gives in detail the information necessary to understand and handle data exchanged between MissionCentre (MC) and PROTEUS Generic Ground System (PGGS). For a first approach with PROTEUS based mission,the User could skip this chapter.

Chapter 9 deals with the on board-ground interfaces, all characteristics of the communication links between theground control/command station(s) and the platform.

Chapter 10 presents the standard schedule, deliveries and documentation for a typical PROTEUS mission.



In any case, given the very wide range of possibilities offered by the PROTEUS system, ranging from the assemblyand delivery of the platform to a full turn key system, the User is strongly encouraged to contact ALCATEL SPACEor CNES to help him analyse the mission and design the most appropriate solution, according to his needs.



1.2 SERVICES

1.2.1 PROTEUS STANDARD SERVICES

The PROTEUS standard services ensured by ALCATEL SPACE and CNES consist in providing:

• the satellite platform,

• the satellite engineering, assembly, integration and test,

• the generic ground control segment procurement including a ground station and a control centre,

• the transportation, the satellite launch campaign activities and the first operations including orbitalcheckout,

• the control centre operations.

1.2.2 EXTENDED SERVICES

1.2.2.1 Specific adaptations

Any requirement at platform, payload interfaces, mission levels not described in this document can be studiedcase by case by ALCATEL SPACE and CNES; for instance PROTEUS based mission may present smaller payloador heavier one, need more power...

1.2.2.2 Payload Instrument Module

ALCATEL SPACE and CNES propose a Payload Instrument Module based on a standard design compared withPROTEUS platform and easily adaptable. It allows:

• either to integrate a payload composed of several boxes,

• or to be a module between the platform and the main payload instrument; its function consists incontaining various electronic boxes, harness to connect the payload instrument to the platform, and/or anoptional X band data communication subsystem.

1.2.2.3 Payload

The wide field of activities and the important experience of ALCATEL SPACE make possible the delivery of specificpayload instruments, according to the Customer’s needs.

Adopting this functional scheme also allows to optimise the system activities as ALCATEL SPACE is involved atsatellite platform level.

1.2.2.4 Launch vehicle procurements

ALCATEL SPACE or CNES can provide the launcher. This task covers all the interface management activities withthe launch vehicle provider from the choice of the launch vehicle (about 2.5 years before launch) to the launchcampaign itself. This activity includes all the necessary safety considerations.

1.2.2.5 Mission ground segment

The mission centre is usually specific to each mission. It can be developed by ALCATEL SPACE or the CNES uponrequest.



1.2.2.6 In orbit operations

CNES or ALCATEL SPACE can be in charge of operating PROTEUS command-control ground segment for somemissions. CNES is also responsible for Launch and Early Operation Phase. Once in orbit, the operations(including station keeping) can also be performed by the CNES. This is a good way to reduce operations costbecause the teams can work simultaneously on different missions.

1.2.2.7 Full turnkey system

As it is done for some geostationary telecommunications missions or in other domains, ALCATEL SPACE is able toprovide a full turn-key system if desired by the Customer.

1.2.3 INDUSTRIAL SHARING

The industrial sharing on a PROTEUS based mission depends on the Customer’s needs. It typically depends onthe origin of the contract: commercial bids versus governmental space agencies procurements. In the case of acommercial contract, ALCATEL SPACE can be the prime contractor, supplying the Customer with a completeoperational system, including operations and ground control for instance. For scientific missions which result froman international co-operation like for Jason (USA/French co-operation), or for a CNES mission like for Corotanother entity such as a national space agency is responsible or co-responsible for the mission and may want totake the responsibility for the command-control ground segment and operations. Then, ALCATEL SPACE isresponsible for the platform, integration and test of the payload on the platform and for the satellite levelengineering. Other tasks may depend on each mission.



1.3 SYSTEM OVERVIEW

PROTEUS offers a standard multimission platform for a very attractive cost and within a delivery time of 24months (from end of phase B (PDR) to launch for a standard mission). Technically, the platform architecture isgeneric. Adaptations are limited to relatively minor changes in a few electrical interfaces and software modules.The robustness and low cost properties of this recurring design concept have been demonstrated, and verydifferent missions such as Jason 1 for radar altimetry, Picasso-Cena for earth environment, Corot for astronomy,and commercial for optical Earth and radar observation plan to use the PROTEUS system.

1.3.1 SYSTEM ARCHITECTURE

The architecture of a space system based on PROTEUS is shown on Figure 1.3-1.

The central column gives the main components of a standard PROTEUS system:

• the standard platform,

• the standard control command ground system (SSGP) with the station (TTC-ET), the satellite control centre(CCC) and the ground network,

• all documentation, hardware and software needed to produce and to test a satellite including payloadinstruments,

• launch pad and first in-orbit operations.

The left column describes the mission specific contribution to the system:

• the payload instruments,

• the mission control centre where the payload operations are commanded and the payload data isprocessed,

• an optional TM station used to increase the visibility duration or the ground segment availability.

The right column presents the launch vehicle chosen by the mission system manager and not included in thestandard PROTEUS service, and one CNES 2 GHz station used to help the first acquisition after launchseparation.



Figure 1.3-1: PROTEUS system architecture

1.3.2 THE SATELLITE SYSTEM CHARACTERISTICS

The PROTEUS platform has been designed to be compatible with various orbits (phased, sun synchronous, frozenand inertial orbits) with altitudes ranging from 500 km to 1500 km, for an orbital plane inclination containedbetween 20 (TBC) and 145 deg. Flight domain is detailed in chapter 2.2.1. Mission design support is provided inparagraph 2.4.

The platform with its folded solar arrays is compatible with small launch vehicle fairing internal diameters from1.9 m.

The platform provides a wide range of payload pointing capabilities (Earth and anti-Earth pointing, inertialpointing); typical pointing performance is 0.05 deg (3σ).

Satellite based on PROTEUS belong to the 500 kg class with a payload mass between 100 kg and 275 kg,consuming up to 300 W power. Typical satellite based on this platform is shown on Figure 1.3-2.



Jason mission 475 kg/400Waltitude = 1336 km/ inclination = 66 deg/Earth pointing

Figure 1.3-2 : Typical satellite based on PROTEUS



1.3.3 GENERAL PLATFORM DESCRIPTION

Figure 1.3-3 and Figure 1.3-4 show the general lay out of a PROTEUS platform.

Figure 1.3-3 : internal lay out of the PROTEUS platform..



Figure 1.3-4 : PROTEUS platform overviewThe platform structure has a 1 m sided cubic shape. All the equipment units are accommodated on four lateralpanels; hydrazine mono-propellant units with a 40 litre tank and four 1 N thrusters are laid out on and under thelower plate. The interface with the launch vehicle is through an adapter (specific to each launch vehicle) bolted tothe bottom of the structure. The mechanical interface with the payload is provided through four points at thecorners of the upper panel. The platform features a structure with frame permitting panel removal and easyintegration. When payload topology allows for it, the platform structure concept is reused for the payload modulestructure.

The PROTEUS functional block diagram is shown on Figure 1.3-5. The functional redundancies are fully ensuredat satellite level; as far as the hardware is concerned, the equipment units are either one-to-one, or n out-of mredundant (for example : 2 gyros out of 3, 3 reaction wheels out of 4...)



9s3p 78A.hLi Ion Battery

Figure 1.3-5 : PROTEUS functional block diagramThe thermal control subsystem is dimensioned to withstand the maximum thermal loads defined by PROTEUScandidate mission. The concept relies on passive radiators and active regulation with heaters, monitored by thecentral computer. Mission adaptation is limited to MLI windows dimensioning and thermal control parametersadjustments. To ensure the safety and health of the satellite payload, PROTEUS provides thermal control andheater power to the payload in all satellite modes.

Electrical power is generated by two symmetric wing arrays attached near to the satellite centre of mass with twosingle-axis stepping motordrives. Each wing is comprised of four 1.5*0.8 m panels covered with classical siliconcells. The power is distributed through a single non-regulated primary electrical bus (23/36V with an average 28Vvoltage), using a Li Ion battery (9s 3 p technology) developed by SAFT.

The electrical, on-board command and data handling architecture is centralised on one single computer, theData Handling Unit (DHU). Functionally, one half of the satellite is under the control of one processor within theDHU, and the other half of the satellite is under the control of the other processor.

The primary functions devoted to the Data Handling Unit are:

• Satellite modes management consisting of automatic mode transitions and routines.

• Failure detection, isolation and recovery (FDIR), consisting of monitoring of satellite health and switching tosafe hold mode if necessary.

• On-board observability, consisting of generation, maintenance, and downlink of housekeeping telemetrydata.

• Satellite commandability, consisting of telecommands sent by ground either to hardware or software.

The DHU performs most of its tasks through the central MA 31750 processor which runs the satellite software. It isresponsible for the power distribution to all satellite units.



It also supports the management of the communication links to each satellite unit either through discrete point topoint lines or via MIL-STD-1553 B bus. The processor generates a clock reference, manages satellite datastorage, and ensures telemetry frame decoding. A maximum of 1000 time-executable commands may beuplinked and stored in any given pass, although additional immediate commands can be sent during satelliteground visibility.

The DHU command buffer can hold a maximum of 20 kwords (16-bit words) and is the constraining element inthe uplink commanding capability. Payload commands are relayed to the payload at a maximum rate of 8 Hz.

The DHU manages the payload throughout the commands, offers standard thermal control, and standardizedelectrical interfaces (23/36V power supply, 1553 bus, specific point to point lines). A payload specific softwareapplication can be implemented in the DHU to control complex payload.

The Data Handling Unit has an internal mass memory organised in two main areas :

• a housekeeping area (HKTM-R) to record payload and platform housekeeping data out of visibility periods.

• a data payload area of 2 Gbits, split in two size programmable areas (PLTM1 / PLTM2) to store andtransmit independently payload data to ground during visibility periods.

The data is transmitted from payload to mass memory through a1553 link with a maximum rate of 100 kbits/s orthrough a specific high speed line with a data rate up to 10 Mbits/s (optional).

A 722.116 kbit/s S band QPSK downlink (without encoding -reedsolomon nor Viterbi- nor frame packetting) isavailable for telemetry. A ground control capacity is provided by a 4 kbit/s S band up-link. The CCSDS packetstandard protocol is used for TM encoding and TC decoding.

Figure 1.3-6 shows the general payload data path and Figure1.3-7 shows more particularly the telemetry flowfrom the payload to the ground system.

Figure 1.3-6 : Payload data path..



Figure 1.3-7 : Telemetry flowTable 1.3-1 gives the useful TM information flows (except for transport overhead) produced on board andtransmitted to ground, the on-board rate characteristics used as basis to size the information transport andstorage functions. The rate is the average over one day to allow easy calculation of the quantities of informationto be stored and sent to the ground.



Flow function Data rate characteristics(average over one day)

Observations Transmissionto the ground

HKTM-P knowledge of thesatellite status and

configuration

N/A received duringvisibility if

emitter is ON

HKTM-R detailed satellitesurveillance

-300 bps when useful TM datarate is 85.966 kbit/s

- 500 bps when data rate is722.116 kbit/s

rate very variabledepending on themission phase and

the groundprogrammation

-recorded onboard

-transmittedupon request

from the ground

ScientificPLTM

informationproduced by the

payload to be sentto mission center

mission dependent the control centredoes not know thepackets contents

-recorded onboard

-sent uponrequest from the

ground

Table 1.3-1 : Main data flows characteristics

For more information, the chapter 9 deals with the on board / ground interfaces in details.

Accurate attitude determination is based on two star trackers (nominal and redundant) measurements. Both startrackers are accommodated on the payload in a Star Tracker Assembly (STA) equipped with an autonomousthermal control.

The normal in-orbit platform attitude control is based on a gyro-stellar concept. Three accurate 2-axis gyrometersare used for stability requirements and attitude propagation. Attitude acquisition is obtained using magnetic andsolar measurements (two 3-axis magnetometers and eight coarse sun sensors). Platform attitude control canprovide a rotation around the axis perpendicular to the solar array driving mechanisms (yaw steering), allowing a90 % recovery of sunlight in the case of a non sun synchronous orbit.

Four small reactions wheels will generate torque for attitude command, and are de-saturated using magnetictorquers.

A Global Positioning System (GPS) receiver will provide satellite position information for accurate orbit ephemerisdetermination and on board time delivery.

The unavailability for a PROTEUS based satellite is estimated to 0.82 % with 0.25% due to reconfigurable failures(example : switch froman equipment unit to a redundant one), 0.50% due to the radiation effects, 0.07% due tothe orbit correction manoeuvres. This last mission interruption case is calculated assuming manoeuvres of 15minutes/month (mission dependent). The Star Tracker occultation could imply a damaged pointing performanceand so a mission unavailability, but nominally the star tracker lay out on the payload is optimised to avoid it.



1.3.4 PROTEUS MAIN CHARACTERISTICS

Table 1.3-2 summarises the main characteristics and related performances of the PROTEUS platform.

Orbit any orbit altitude in 500-1500 kmorbit inclination higher than 20 deg (TBC)

Launch vehicles compatible with all launch vehiclewith fairing diameter >1.9m

Mass dry platform mass w/o STA = 262 kg28 kg hydrazine capacity

Payload mass = 100 to 286 kg

Reliability 0.892 over 3 years0.759 over 5 years

Lifetime 3 to 5 years depending on the orbit

Power bus maximum consumption = 300 WPayload consumption class = 200 W

up to 300 W on some orbits

PointingAttitude restitution

0.05 deg (3 σ) on each axis

Data storage 2 Gbits for payload

Down link 722.116 kbits/s

Up link 4 kbits/s

Unavailability 0.81 %

Table 1.3-2: PROTEUS main characteristics

1.3.5 PROTEUS BASED SATELLITE MODES

Various satellite « modes » are used to define the behaviour of the satellite, together with the associatedconfiguration of the equipment units, and their monitoring.

The main in-flight modes are driven by the Attitude and Orbit Control System (AOCS) :

• Start up mode

• Safe Hold Mode (SHM)

• Star Acquisition Mode (STAM)

• Normal mode (Nom)



• Orbit Correction Mode with 2 thrusters (OCM2)

• Orbit Correction Mode with 4 thrusters.(OCM4)

Two other modes are used on ground :

• Off mode

• Test mode.

All these modes, shown on Figure 1.3-8 are described in more details hereafter.

Notice : During transition phases (for instance manoeuvres for orbit correction depending on the mission andduring Safe Hold Mode), the payload could be dazzled.

An automatic transition to Safe Hold Mode (on redundant equipment) is automatically engaged after critical onboard failure detection. If there is an instrument in failure, this instrument will be put in passive state and poweredOFF; but it does not imply a satellite transition to Safe Hold Mode.



Figure 1.3-8: Satellite modesNotice: In flight, the Safe Hold mode-Start Up mode transition duration is less than around 1.5 minutes.

1.3.5.1 Satellite OFF mode

The satellite is not powered (battery not connected), the satellite is not operable. This mode is used for storage ortransportation.

1.3.5.2 Satellite Start-up

This mode is used during the launch and on ground.



The satellite is powered, the receivers are ON (hot redundancy, not commandable, automatically ON at satellitepowering) and the Reconfiguration Module (RM) is waiting for separation strap disconnection. It is possible tosend direct TCs (TCD) to command ON a Processor Module (PM) or modify the RM registers which define the onboard configuration which shall be used after Umbilical Strap disconnection. If a PM is set ON, this PM willnominally detect the Umbilical presence and go to Test Mode. Nominally, the payload is OFF. It is not poweredor, in case of special needs, in a reduced way depending on launch phase (30 W maximum for 2 of the 16power lines which can be maintained ON (TBC) and which are not managed but protected with a passive system(fuses) (see section 3.5.3)). Its thermal control is not ensured by the platform and the satellite attitude is imposedby the launch vehicle.

This mode is normally engaged in two ways :

• either with the connection of the battery to the Power and Conditioning Equipment unit (PCE) ; in that case,it lasts from ground operations on the launch pad till separation from the launcher.

• or on an alarm triggering ; in that case, the switch to start up mode is only a transient.

Safe Hold Mode transition is automatically engaged after umbilical strap disconnection detection.

The exit from this mode is performed in two ways:

• either the automatic way when the satellite is separated from the launch vehicle,

• or by a high priority ground command to enter the test mode; this transition is used on the launch pad,under ground control, when the satellite is connected via an umbilical cord, or during AIT.

1.3.5.3 Satellite Test Mode

This mode is used during AIT or on the launch pad for final verifications. On the launch pad, the allowed TCs arelimited to the ones necessary for health checks.

This mode is typically engaged with a high priority ground command (TCD) on the launch pad.

The exit of this mode is performed by using a TCD on the launch pad: switch OFF Processor Module A or B.

On the launch pad, it is possible from this mode to return to Start up Mode by a telecommand.

1.3.5.4 Satellite Safe Hold Mode (SHM)

This mode consists in 3 main phases : RDP (Rate Damping Phase), SPP (Sun Pointing Phase), BBQ (Barbecue).

The aim of this mode consists in reaching autonomously a safe attitude with the -X satellite axis pointed to the Sunand with the mean roll angular rate equal to -0.25 deg/s. In this mode, thrusters and sophisticated equipment(for instance gyros) are not used.

For Safe Hold mode transfer, in the first phase, the satellite changes its attitude in order to place its solar array incanonical position (40 min) and then is oriented until its -Xs axis points to the Sun. To achieve this attitude, thesatellite can be briefly oriented such as the payload is dazzled by the Sun.

Then, the satellite may stay as long as necessary in Safe Hold Mode. In this mode, PROTEUS provides theminimum amount of satellite management required to support vital functions for diagnosis or anomaly handling.These include ground to satellite communication, thermal control, battery management, failure management,reduced (30W) payload power (see section 3.5.3), and coarse sun pointing. Coarse sun sensors andmagnetometers provide attitude measurement, and magnetic torquers generate torque. In addition, two of thefour reaction wheels are used to provide gyroscopic stiffness.

This mode is always engaged after the initialisation transition defined by the Start up Mode. This mode beginsafter the first initialisation, or on an alarm triggering, or on a software reset.

The satellite leaves the Safe Hold Mode:

• normally, when the OBSW identifies the TC which commands the Transition mode



• if an alarm occurs, implying an automatic transition to Start up Mode.

1.3.5.5 Satellite Star Acquisition mode (STAM)

Star Acquisition Mode is used to reacquire fine attitude, position, and time information during the transition fromSafe Hold Mode to Nominal Mode. These data are given by the Global Positioning System and Star Tracker. Itstarts when the satellite can be considered « safe ».

In this mode, the payload operations are restricted to the ones strictly necessary to verify the instrumentsbehaviour. Priority is given to housekeeping operations. Nominally payload is OFF. In case of special needs, 2 ofthe 16 power lines can be maintained ON which insure reduced (30W) payload power. Nominal payloadthermal control is performed by the OBSW.

The only way this mode is engaged is when receiving a ground command while on Safe Hold Mode.

The mode exit is performed on ground request, with the TC mode change to Nominal Mode.

1.3.5.6 Satellite Normal Mode

The normal mode, in addition to the vital satellite management functions, provides generic or specific services asrequired by the payload, including power, commanding and status via 1553B bus, precise datation and finepointing.

The Normal mode is engaged in three different ways:

• from the Star Acquisition Mode, upon ground request,

• automatically when leaving the Orbital Correction Mode,

• in a Normal Mode reset process, upon ground request; this method is used to change the attitude andorbit control system equipment configuration.

Usually, the satellite stays in Normal Mode. An alarm or a ground request could involve a mode exit towards theSafe Hold Mode via the Start-up Mode.

1.3.5.7 Satellite OCM Modes (OCM2 and OCM4)

Orbit Manoeuvres are commanded in these modes. The performances and services are the same as in Nominalmode, but attitude pointing can be damaged and payload functioning can be restricted during largemanoeuvres. The Satellite is under the OBSW control. The thrusters are used to control the orbit: 4 thrusters areneeded when an important delta V is to be performed; only 2 thrusters are required when small manoeuvres arenecessary. As the thrust direction is aligned with the +Xs satellite axis, the satellite shall be oriented such as the+Xs axis is aligned with the velocity vector during these manoeuvres.

The periodicity and the choice of these modes depend on specific mission analysis and control. During thesemanoeuvres, payload units may be either operating or not, according to the mission.

Those modes are always engaged upon ground request. The transition is always performed from the NominalMode.

Exit from these modes is performed automatically :

• when the orbit manoeuvre is over, to nominal mode

• on alarm, to start up mode.

1.3.6 GROUND CONTROL SEGMENT CHARACTERISTICS

The ground segment called « PROTEUS Generic Ground Segment » (PGGS) consists of one or moreTelecommand and Telemetry Earth Terminal (TTCET), a Command and Control Center (CCC) and a Data



Communication Network (DCN). The mission centers (MC) are connected to the CCC and the TTCETs via theDCN.

The TTCET consists in three subsystems :

• the « radio frequency » subsystem sets up the on board/ground link on order from the CCC. It ensures thereception of the signals delivered by the satellite and the transmittal of signals to the satellite. Reception ismade in circular polarization diversity mode and transmission according to a polarization selected by theCCC.

• the « base band » subsystem receives the telecommands from the CCC and transfers them to the radiofrequency subsystem. It transmits satellite telemetry to the CCC and to the MCs. Completely automated, itdoes not require the operators presence.

• the « time frequency » subsystem distributes a time reference and a frequency reference to the radiofrequency and base band subsystems.

The CCC ensures the telemetry processing, satellite orbit and attitude control functions, the generation andtransmission of platform telecommands, the reception and transmission of mission telecommands from the MC.The operating modes of the CCC depend on the needs of the User mission and range from partially automaticoperation during working hours and on working days to all manual operations 24 hours-a-day.

The consultation function for the archived data (TM parameters, raw TM packets, the satellite status, the logbookand the operational documentation) and distribution of results is performed by a WWW data server. TheCustomer uses either a standard workstation equipped with a navigator, or a specific station (DRPPC) equippedwith a navigator and packages supplied by the CCC.

The protocols used for PGGS data transfer are the following :

• TCP-IP (Internal Protocol) for real time exchanges between the Command and Control Center (CCC) andthe Telecommand and Telemetry Earth Terminal (TTCET) (housekeeping, telecommand, RC, RM) and fortransmitting TTCET RMs to the Mission Center(s).

• FTP (File Transfer Protocol) for files transfer (housekeeping, payload telemetry, pointing data, missiongeneration help data)

• HTTP and e-mail for data exchanged between the CCC and the expert DRPPCs.

For a given mission, the PROTEUS Generic Ground Segment (PGGS) is a part of the mission ground segment. Itdoes not ensure all the mission functions but all those required for final orbit acquisition and control of thesatellite. Its main functions are the following ones:

• Satellite surveillance and technical control

these functions consist in checking, thanks to housekeeping telemetry processing, that the status of the satellite issatisfactory for mission needs and for transmitting telecommands to maintain normal satellite operation.

• Orbit and attitude control

Satellite orbit determination is performed by the PGGS from the Global Positioning System (GPS) data received inhousekeeping telemetry. If an orbit correction is required, the PGGS generates the control commands which are sentby telecommands and executed by the satellite. Attitude control is performed automatically on board from the GPSdata and the sensor information. The PGGS periodically updates the attitude control on board model parameters.

• Payload service

This consists in transmitting the received payload telemetry to the Mission Center, checking the status of the payloadthanks to housekeeping telemetry processing and in performing the programming operations at the frequencydependent on mission requirements and satellite storage capacity.

• Satellite expert appraisal



It consists in leading investigations in case of satellite misfunctioning or reports on its behaviour. These operationsare led by the operators of the Control Center or by external experts.



1.4 FRAMES AND SATELLITE AXIS DEFINITION

Inertial Reference Frame J2000.0

SY - 1.4 - 1

This reference frame shall be used at system level

J2000 means the date 01/01/2000 at 12h00 (barycentric dynamic time)

The X axis is the mean equinox of the J2000 date, the intersection between the mean equator of the J2000 dateand the mean ecliptic of the J2000 date.

The Z axis is colinear to the poles axis with the South-North direction. The poles axis is perpendicular to the meanequator of the J2000 date.

The Y axis completes the right-handed orthogonal reference frame.

Earth Reference Frame WGS 84

SY - 1.4 - 2


WGS 84 means World Geodesic System.

For PROTEUS ground/on board calculations requirements, the WGS 84 Earth Reference Frame is considered as thesame as the IERS (International Earth Rotation Service) reference frame: IRTF90, IERS terrestrial reference system forthe year 90.



Local Orbital Reference Frame (G, XLo, YLo, ZLo) FLo

SY - 1.4 - 3

This reference frame shall be used at system level.

It is known as the conventional pitch, roll and yaw system.

G is the satellite center of mass in operational conditions.

YLo (Pitch axis) is perpendicular to the orbital plane and oriented in the opposite direction of the orbital kineticmomentum.

ZLo (Yaw axis) is parallel to the orbital plane and oriented toward the geocentric direction.

XLo (Roll axis) completes the right-handed orthogonal reference frame (this axis is parallel to the velocity vector andoriented in the same direction if the orbit is perfectly circular).

+YLo

+XLo

+ZLo

Figure 1.4-1 : Local orbital reference frame



Satellite Reference Frame (P, Xs, Ys, Zs) Fs

SY - 1.4 - 4


It is used to define hardware location within the satellite.

P is located at the center of the launch vehicle interface circle: at the bottom of the standard PROTEUS interfaceframe and the top of the specific launch vehicle adapter.

+Zs is parallel to the launch vehicle interface plane and pointed towards H01 electrical bracket (towards Earth innormal flight configuration). This axis defines the normal to the « Earth panel ».

+Xs is perpendicular to the launch vehicle interface plane and oriented from launch vehicle towards satellite.

+Ys completes this right-handed orthogonal reference frame (this axis is parallel to the launch vehicle interfaceplane and parallel to the solar array rotation axis).

This frame is materialized by a reference mirror cube located on the platform bottom frame.

The frame axis is shown with Jason payload as example on Figure 1.4-2.

Figure 1.4-2 : Satellite Reference Frame (For information, JASON 1 Satellite: PROTEUS platform+JASON 1 specific Payload)



Satellite Center of Gravity Reference Frame (G, XG, YG, ZG) FG

SY - 1.4 - 5


It is obtained by a simple translation of the Satellite Reference Frame (Fs) to the satellite center of gravity (G).

It is the reference for the satellite mass, centering and moments of inertia configuration.

Star Tracker n°2 Frame (OSTR2, XSTR2, YSTR2, ZSTR2) FSTR2

SY - 1.4 - 6

This reference frame shall be used at system level and is defined by

OSTR2 is the geometric centre of the reference mirror cube of Star Tracker 2

XSTR2 is parallel to the Star Tracker 2 CCD length and is pointed towards Star Tracker 1

ZSTR2 is parallel to the Star Tracker 2 optical axis toward space

YSTR2 completes this right-handed orthogonal reference frame ( it is parallel to the CCD width)

Star Tracker n°1 Frame (OSTR1, XSTR1, YSTR1, ZSTR1) FSTR1

SY - 1.4 - 7


OSTR1 is the geometric centre of the reference mirror cube of Star Tracker 1

XSTR1 is parallel to the Star Tracker 1 CCD length and is pointed in the same direction as XSTR2

ZSTR1 is parallel to the Star Tracker n°1 optical axis toward space

YSTR1 completes this right-handed orthogonal reference frame ( it is parallel to the CCD width)

The reference for satellite attitude determination is reference mirror cube of Star Tracker 1.

Star Trackers Assembly Frame (OSTA, XSTA, YSTA, ZSTA) FSTA

SY - 1.4 - 8


OSTA is geometric centre of the interface points of the STA

XSTA is parallel to the STA interface plane and is in the same direction of XSTR1

ZSTA is perpendicular to the interface plane and is pointed toward the payload

YSTA completes this right-handed orthogonal reference frame ( it is parallel to the STA interface plane)

The reference frame is shown on Figure 1.4-3.



Figure 1.4-3: STA Reference FramePayload Reference Frame (OP, XP, YP, ZP) FP

PL - 1.4 - 1

This reference frame shall be used at payload level.

It is obtained by a translation of the Satellite Reference Frame (Fs) to the Payload Interface Plane.

OP is the geometric centre of the four platform/payload interface points in this interface plane.

This frame is materialized by a reference mirror cube located on the Payload Instrument Module, on or close tothe Star Tracker bracket.

Instrument Unit Reference Frames

PL - 1.4 - 2

This reference frame shall be defined for each Instrument Unit and shall be documented in the corresponding IDS.

This frame shall have preferably Z axis perpendicular to the unit mounting plane.

For Instrument Units with accurate pointing constraints, this Instrument Unit reference frame will be materializedby a reference mirror cube.



PL - 1.4 -3

The transfer matrix from the instrument antenna boresight (if any) to its reference frame shall be provided in itsmechanical IDS.

Satellite Attitude

SY - 1.4 - 9

The satellite attitude is defined by the orientation of the Satellite Center of Gravity Reference Frame (G, XG, YG,ZG) or the Satellite Reference Frame (P, Xs, Ys, Zs), versus the Local Orbital Reference Frame (G, XLo, YLo, Zlo).

In case of nominal configuration (see section 2.3.1.1.1.2 a), the Satellite attitude is defined by the Euler Angles,defined in the following order:

Ψ: Yaw angle = positive rotation around ZLo (from XLo toward YLo)

θ: Pitch angle = positive rotation around the image of YLo after the Ψ rotation.

φ: Roll angle = positive rotation around Xs (image of XLo after Ψ and θ rotations).

For any other configuration, these definitions will be mission dependent (vertical flight, inertial pointing,...).

An equivalent representation of the attitude is given by the quaternion representation [q0, q1, q2, q3] with theconvention q0>0 (real part) .



1.5 DEFINITIONS

These definitions are used to distinguish standard PROTEUS elements and mission specific elements making asatellite.

SY - 1.5 - 1 a

These definitions shall be used at system level

Unit or Instrument Unit: A unit is a single box defined by an equipment/assembly name, an identification partnumber and a serial number.

Instrument or Payload Instrument: An instrument or a payload instrument is defined by one unit or a set ofunits with associated harness necessary to perform a type of measurement or a payload function.

Payload Instrument Module (PIM): The payload instrument module supports the payload instruments, andprovides a thermally controlled environment and the necessary harness to connect the Payload instrument to theplatform.

Payload: The payload is the assembly of the Payload Instrument Module and the Payload Instruments.

Equipped Payload: Payload + STA + H02 & H03 connectors brackets + STR cables

STA : The Star Trackers Assembly is a part of the platform but shall be mounted on the payload. The assemblypayload + STA + connectors brackets + STR cables is the equipped payload.

Platform or PROTEUS Platform: The PROTEUS platform provides all the necessary housekeeping functions toperform the mission: Payload support, electrical power, command, data handling and storage, attitude and orbitcontrol,...

Launcher adapter: mechanical ring bolted on PROTEUS standard platform at one end and specific to thelauncher clamp band at the other end, equipped with thermal protections and actuator interface pads.

Bus or Satellite Bus: The Bus is the assembly of the PROTEUS Platform, the Payload Instrument Module (missionspecific) and the launcher adapter (launcher specific) which stays attached to the platform after launch vehicle/satellite separation.

Satellite: The satellite is the assembly of the Bus and the Payload Instrument or (equivalent) the assembly of thePlatform, the Payload and the Launcher adapter.

To allow an easy adaptation to missions, the interfaces between the platform and the payload are standardisedand clearly defined.

This architecture is illustrated in Figure 1.5-1.

For missions with a single instrument, the Platform Instrument Module can be suppressed if the instrument fits withthese standard interfaces.



Figure 1.5-1 : Satellite architecture



1.6 UNITS, MODELS AND CONSTANTS

1.6.1 UNITS

For PROTEUS studies, the physical parameters are expressed in metric system.

SY - 1.6 - 1

These units shall be used at system level.

• Length in millimetre (mm), Metre (m) or kilometre (km),

• Mass in kilogram (kg),

• Inertia in kg x m2,

• Pressure in Bars (b) or millibars (mb) or in Pascal (Pa) for very low pressure,

• Temperatures in degrees Kelvin (K) or Celsius ( °C),

• Thermal inertia in J/K,

• Angles in degree (deg), arc minute and arc second, or in microradian (µrad) for small angles,

• Specific impulse in Seconds (s),

• Power in Watt (W).

1.6.2 MODELS

A PROTEUS based satellite is designed with the following models :

CAD model:

CAD model is developed on CATIA version 4.21.

Structural model:

Structural analysis will be performed on NASTRAN version or 70.

Thermal model:

Thermal analysis is performed on CORATHERM release 99.

Radiations:

The models used for the calculation of

trapped electrons and protons are AE8 and AP8 models, NASA environment models,

heavy ions ; LET curve is established with the Cosmic Ray Effects on Micro Electronics (CREME) programme. The M« Weather index » of CREME is usually equal to 3 which corresponds to « Galactic Cosmics Rays + Adams 90 %worst case Solar activity ».

Earth magnetic field model:

Reference: IGRF95 International Geomagnetic Reference Field 1995. Order: 10.

Model IGRF is used.

Atmospheric model:

a) BARLIER : A thermospheric model based on satellite drag data. A-N°185-1997.



b) monoatomic oxygen : In ESABASE, the software which permits to calculate the monoatomic oxygen effect is calledATOMOX.

1.6.3 CONSTANTS

Orbitography:

Orbit bulletin will be given in adapted parameters (a, ex, ey, i, Ω, α) in Veis reference frame (TBC) with

a = semi major axis in km

ex = e x COS (perigee argument) = X component of eccentricity vector

ey = e x SIN (perigee argument) = Y component of eccentricity vector

i = inclination in deg

Ω = inertial ascending node longitude in deg

α = perigee argument + true anomaly = position on orbit (pso) in deg

Earth potential field:

The model GEM10 will be used:

Rt = Earth ellipsoid equatorial radius = 6378.140 km

G = Universal gravitational constant = 6672 x 10-14 kg-1.m3/s2

µ = Earth gravitational constant = 398600.64 km3/s2

a = Earth ellipsoid flatness = 0.003352836

J2 = second zonal harmonic = -1.0826268 x 10-3

T = Earth sidereal period = 86163.9796 sec

q1 = Earth sidereal rotation rate = 0.00417808 deg/sec

Other main constant:

c = light speed = 299792.458 km/s

Ps = Solar pressure coefficient = 4.56 10-6

Mt = Earth magnetic dipole moment = 8.06 x 1022 SI

Definition of mean (or centred) orbital parameters:

The centred elements represent the osculating elements for which the short periodic effects from all perturbationsare removed. They are obtained by filtering the short-period effects of osculating elements which are issued froma numerical integration with all the forces (Earth gravity field (a full 70x70 field), Moon and Sun effects,atmospheric drag, solar radiation pressure).

The filtering method uses low-pass filters and the cut-off frequency can be chosen in order to keep the longperiod effects and the secular effects. The filtering method can be applied on keplerian elements as semi-majoraxis, inclination, eccentricity or operational elements of station keeping as altitude, local hour, cross ground tracks....

Propulsion:

The constant g0 is used for hydrazine consumption (∆V = g0 x Isp x ln(mi/mf)) with g0 = 9,80665 m/s-2.



1.7 REFERENCE AND APPLICABLE DOCUMENTS

1.7.1 REFERENCE DOCUMENTS

Reference Document reference Document titleRD1 LDP.SB.LBP.12.CNES Specification technique de besoin partie 1 plate-forme

RD2 Issue 5 rev 1 16/06/1999

LDP-SB-LB/LS-12-CNES

PROTEUS Technical Requirements specification

Part 2 : satellite to ground interface

RD3 LDP-SB-LS-12-CNES PROTEUS specification Technique de Besoin

Partie 3 : segment sol générique

RD4 PRO.LB.0.MU.0651.ASC

issue 1 rev 0

PROTEUS launch vehicle compatibility guide

RD5 Deleted

RD6 PRO.LBP.0.DJ.0640.ASC PROTEUS platform budgets and margins

RD7 Cours de technologie spatiale CNES -Cépaduès éditions

Techniques et technologies des véhicules spatiaux (tome 1)

RD8 Scientific Satellites Achievements andProspects in Europe 20/22/11/96 Paris

A new European small platform : PROTEUS, and prospected scientificapplications

RD9 DGA/T/TI/MS/AM/98022 11/03/98

RD10 PTU/TNT/0034/SE PROTEUS DHU – Interface Data Sheets

RD11 P-PTU-NOT-0048-SE PROTEUS DHU Analogue Measurement accuracy

RD12 Guidelines and Assessment Procedures for Limiting Orbital Debris,NASA Safety Standard NSS 1740.14

RD13 JPL D-18663 Rev A, May 20, 2000 Jason 1 Orbital Debris Assessment



1.7.2 APPLICABLE DOCUMENTS

None

1.7.3 STANDARDS

Reference Document reference Document title

ST01 MIL-STD-1553 B notice 2 Aircraft Internal Time Division Data Bus

ST02 MIL-STD-462 Measurement of EMF characteristics

ST03 ESA PSS-04-106 issue 1 Packet Telemetry Standard

ST04 ESA PSS-04-107 issue 2 Packet Telecommand Standard



1.8 ACRONYMS

1.8.1 REQUIREMENTS ACRONYMS

The requirements given in the PROTEUS User’s Manual use the following convention

GR : GRoundSY : SystemPL : Payload Section number

Requirements number

xx - yyy - z

GR requirements are applicable to the Ground SystemSY are applicable to all the system that is to say : satellite, payload ...PL are applicable to the payload.

1.8.2 OTHER ACRONYMS

AD Applicable DocumentAIT Assembly Integration and TestAIV Assembly , Integration and ValidationAN AnalogAOCS Attitude and Orbit Control SystemAOS Acquisition Of SignalAPID Application Process IdentifierAS16 16-bit Serial AcquisitionBB BroadbandBBQ BarbecueBC Bus ControllerBIT Built-in-testBDR Baseline Design ReviewBOL Beginning of LifeBVLE Banc de Validation Logiciel et Electrique (Software and Electrical Validation Bench)CCC Command Control CentreCCSDS Central Committee for Space Data SystemCDR Critical Design ReviewCLCW Command Link Command WordCLTU Command Link Transmission UnitCNES Centre National d'Etudes SpatialesCoG Centre of GravityCON CNES Operational NetworkCOROT COnvection and ROTationCS Conducted SusceptibilityCSS Coarse Sun SensorCST Centre Spatial ToulouseCVCM Collected Volatile Condensable MaterialDB Digital BilevelDC Direct CurrentDCN Data Communications NetworkDDV Development Design and VerificationDHU Data Handling UnitDoD Depth of Discharge



DR Digital RelayDS Digital SerialEED ElectroExplosive DeviceEEE Electrical, Electronic and ElectromechanicalEGSE Electrical Ground Support EquipmentEM Engineering ModelEMC ElectroMagnetic CompatibilityEMI ElectroMagnetic InterferenceEOL End Of LifeESA European Space AgencyESD ElectroStatic DischargeFDIR Failure Detection Isolation and RecoveryFDTM Failure Detection TMFEM Finite Element ModelFM Flight ModelFOV Field of ViewFTP File Transfer ProtocolGDIS General Design and Interface SpecificationGNSS Global Navigation Satellite SystemGPS Global Positioning SystemGSE Ground Support EquipmentGYR GyrometerHKTM House Keeping TelemetryHKTM-P House Keeping Telemetry PassHKTM-R House Keeping Telemetry RecordHLC High Level CommandHW HardwareIAT Instrument Aliveness TestICD Interface Control DocumentIDS Interface Data SheetIERS International Earth Rotation ServiceI/F InterfaceIGRF International Geomagnetic Reference FieldIHCT Instrument Health Check TestIIS Instrument Interface SpecificationI/O Input/OutputIP Internal ProtocolIPVT Instrument Performance Verification TestISDN Integrated Services Digital NetworkLEO Low Earth OrbitLET Linear Energy TransferLGP Local Ground PointLISN Line Impedance Stabilised NumberLISN Line Impedance Stabilised NetworkLNI Local Network Interconnection (CNES Intranet)LogB LogbookLOS Loss Of SignalLTTM Long Term TelemetryMAG MagnetometerMC Mission CentreMCI Mass, Centring & InertiaMCR Main Control RoomMGSE Mechanical Ground Support EquipmentMIL-STD Military - Standard



MLI Multi Layer InsulationMMIC Microwave Monolithic Integrated CircuitMOI Moment Of InertiaMSB Most Significant BitMTB Magnetotorquer BarNA Not ApplicableNB NarrowBandNR No requirementNOM Normal Operation ModeOBSW On Board SoftwareOBT On Board TimeOCM2 Orbit Control Mode 2 ThrustersOCM4 Orbit Control Mode 4 ThrustersOMP Operations and Manoeuvres ProceduresOOC Operational Orbit CentreOQ Operational QualificationOS Operating SystemOVB Operational Validation BenchPCE Power Conditioning EquipmentPDIS Payload Design & Interface SpecificationPDR Preliminary Design ReviewPF PlatformPFM ProtoFlight ModelPGGS PROTEUS Generic Ground SegmentPGR Panel Ground ReferencePIM Payload Instrument ModulePL PayloadPLTM Payload TelemetryPM Processor ModulePPS Pulse Per SecondPROTEUS Platforme Réutilisable pour l' Observation, les Télécommunications

et Usages Scientifiques (multimission platform for low Earth orbits)PSD Power Spectral DensityPVT Position / Velocity / TimeQA Quality AssuranceQFS Qualification and Flight SparesQM Qualification ModelRAM Random Access MemoryRD Reference DocumentRDP Rate Damping PhaseRF Radio FrequencyRM Reconfiguration ModuleRT Remote TerminalRWA Reaction Wheel AssemblyRX ReceiverSA Solar ArraySADM Solar Array Drive MechanismSBDL Standard Balanced Digital LinkSCC Satellite Control CentreSC16 16 bits Serial CommandSD Satellite Dynamics simulatorSDB Satellite Data BaseSGP Single Ground PointSHM Safe Hold Mode



SL SatelliteSOP Specialised Operations PlanSPL Sound Pressure LevelSPP Sun Pointing PhaseSR Service RequestSSGP Standard Control Command Ground SystemSTA Star Tracker AssemblySTAM Star Acquisition ModeSTR Star TrackerSW SoftwareTBC To Be ConfirmedTBD To Be DeterminedTC Telecommand (Ground command)TCD Direct Telecommand (hardware TC)TCUI Telecommand charge Utile Immédiat (Telecommand Payload Immediat)TCUH Telecommand Charge Utile Chargement (Telecommand Payload Software loading)TCUT Telecommand Charge Utile « time Tagged » (Telecommand Payload Time Tagged )TQ Technical QualificationTHR ThrustersTM TelemetryTMD Direct TelemetryTML Total Mass LossTTC Telemetry Tracking and CommandTTC-ET Telemetry Telecommand Earth TerminalTX TransmitterUTC Universal Time CoordinatedVCA Virtual Channel AccessVCM Virtual Channel Multiplexerw/o withoutZVS Zero Volt Secondaire



END OF CHAPTER

scope change traceability chapter 1 - proteus

Documents