GPS-based relative navigation during the separation sequence of

Document Sample
GPS-based relative navigation during the separation sequence of Powered By Docstoc
                   Simone D’Amico(1), Sergio De Florio(1), Jean-Sebastien Ardaens(1), Toru Yamamoto(2)
             German Aerospace Center (DLR),Münchner Str. 20, 82234 Wessling, Germany,
           Japan Aerospace Exploration Agency, Institute of Aerospace Technology, Tsukuba, Ibaraki, 305-8505, Japan

ABSTRACT                                                         tude and 98.2° inclination. A dusk-dawn orbit with a 6
                                                                 or 18 h nominal local time at the ascending node
The German Aerospace Center (DLR) provides various
                                                                 (LTAN) is targeted. Maximum eclipse times of 23 min-
key contributions to the Swedish led PRISMA forma-
                                                                 utes may occur for injections within ±1 h off the nomi-
tion flying mission. These comprise a redundant GPS
                                                                 nal LTAN, depending on the sun’s declination. Follow-
hardware architecture for the two spacecraft, a real-time
                                                                 ing a separation from the launcher, the two spacecraft
navigation software to support formation flying during
                                                                 will stay in a clamped configuration for initial system
all phases, and dedicated experiments for absolute and
                                                                 checkout and preliminary verification (cf. Fig. 1). Once
relative orbit control. This paper addresses the testing
                                                                 the spacecraft are separated from each other, various
and validation of the GPS-based flight software as a
                                                                 experiments for formation flying and in-orbit servicing
standalone unit prior to its full integration into the
                                                                 will be conducted within a minimum targeted mission
spacecraft onboard computer. Thank to the model based
                                                                 lifetime of eight months. Spacecraft operations will be
PRISMA onboard software design, the navigation soft-
                                                                 performed remotely from Solna, near Stockholm, mak-
ware can be executed on different platforms in a fully
                                                                 ing use of the European Space and Sounding Rocket
consistent manner. As illustrated in the paper, this al-
                                                                 Range (Esrange) ground station in northern Sweden.
lows a seamless transition between offline simulations
                                                                 The S-band ground-space link to MAIN supports com-
using GPS flight data from the Gravity Recovery and
                                                                 manding with a bit rate of 4 kbps and telemetry with up
Climate Experiment (GRACE) and real-time hardware-
                                                                 to 1 Mbps. In contrast, communication with the TAR-
in-loop tests comprising real Phoenix GPS receivers and
                                                                 GET spacecraft is only provided through MAIN acting
a 2x12 channels Spirent GSS7700 GPS signal simulator.
                                                                 as a relay and making use of a MAIN-TARGET inter-
Furthermore the complete application is ported to a Real
                                                                 satellite link (ISL) in the ultrahigh-frequency (UHF)
Time Executive for Multiprocessor Systems (RTEMS)
                                                                 band with a data rate of 19.2 kbps. The MAIN space-
environment in a LEON-3 board, representative of the
                                                                 craft has a wet mass of 150 kg and a size of 80 × 83 ×
PRISMA onboard computer. Overall the test campaign
                                                                 130 cm in launch configuration. In contrast to the highly
shows the compliance of the navigation software to the
                                                                 maneuverable MAIN spacecraft, TARGET is a passive
challenging requirements of the PRISMA mission and
                                                                 and much simpler spacecraft, with a mass of 40 kg at a
paves the way for the PRISMA system level tests with
                                                                 size of 80 × 80 × 31 cm (cf. Fig. 1). Electrical power for
                                                                 the operation of the MAIN spacecraft bus and payload
                                                                 is provided by two deployable solar panels delivering a
                                                                 maximum of 300 W, whereas TARGET relies on one
The mission objectives of PRISMA may be divided into             body-mounted solar panel providing a maximum of 90
the validation of sensor and actuator technologies re-           W.
lated to formation flying and the demonstration of ex-
periments for formation flying and rendezvous. Key
sensor and actuator components [1] comprise a GPS
receiver system, two Vision Based Sensors (VBS), two
Formation Flying Radio Frequency Sensors (FFRF),
and a hydrazine mono-propellant thruster system. These
will support and enable the demonstration of autono-
mous spacecraft formation flying, homing, and rendez-
vous scenarios, as well as close-range proximity opera-
tions. The mission is led by the Swedish Space Corpora-
tion (SSC) and foresees a launch of the two spacecraft           Figure 1 Artist’s impression of the PRISMA clamped
in the first half of 2009. The spacecraft are named              configuration after launch (left), with the MAIN solar
MAIN and TARGET and will be injected by a DNEPR-                 panels deployed (center), and the individual MAIN
1 launcher into a sun-synchronous orbit at 700-km alti-          (right-top) and TARGET (right-bottom) spacecraft.

3rd International Symposium on Formation Flying, Missions and Technology, 23-25 April 2008, ESA/ESTEC, Noordwijk
The TARGET spacecraft applies a coarse three-axis             Multiprocessor Systems (RTEMS) environment in a
attitude control based on magnetometers, sun sensors,         LEON3 board [8], representative of the PRISMA on-
and GPS receivers only. The MAIN spacecraft imple-            board computer, by means of Matlab/Simulink Real-
ments instead a three-axis, reaction-wheel based attitude     Time-Workshop. Overall the test campaign shows the
control with independent three-axis delta-v capability.       compliance of the navigation software to the challeng-
                                                              ing requirements of the PRISMA mission [9] in terms of
       FOV                                                    functionality, data interface, navigation accuracy, on-
                                               Phoenix        board memory and CPU load and paves the way for the
                                               GPS Receiver
             GPS Antenna         LNA
                                                              full integrated PRISMA system level tests with hard-
                                       5V DC                  ware-in-the-loop.
                    R/F Switch

                                                              2.    GPS-BASED NAVIGATION SOFTWARE
                                                              2.1    Navigation Software Architecture
                                       5V DC
                                                              One of the main challenges of the PRISMA formation
             GPS Antenna
                                 LNA                          flying is the realization of an on-board navigation sys-
                                               GPS Receiver
                                                              tem for all mission phases which is robust and accurate
       FOV                                                    even for various spacecraft orientations and frequent
                                                              thruster firing for orbit control. The goal of the absolute
Figure 2 Redundant Phoenix GPS receiver system of             and relative orbit determination is to achieve an accu-
MAIN and TARGET spacecraft. Two Phoenix GPS re-               racy of 2 m and 0.1 m, respectively (1D, r.m.s.) and to
ceivers are available (right), which are connected to         provide continuous position and velocity data of the
two GPS antennas (left) with opposite field of view via a     participating spacecraft at a 1 Hz rate for guidance and
coaxial switch (middle).                                      control purposes as well as for the PRISMA payload
The German Aerospace Center (DLR) provides various            The PRISMA onboard software (OBS) architecture con-
key contributions to the PRISMA mission [2]. These            sists of a layered structure with a Basic Software (BSW)
comprise a redundant set of Phoenix GPS receiver and          level and an Application Software (ASW) level com-
antenna systems for both spacecraft [3] (cf. Fig. 2), a       municating with each other through dedicated message
GPS-based navigation software to support formation            queues. While the BSW includes basic applications,
flying during all phases [4], dedicated experiments for       device drivers and I/O-utilities, the ASW encapsulates
relative [5] and absolute orbit control [6] as well as an     all top-level applications like spacecraft navigation,
on-ground automated Precise Orbit Determination               control, telecommand and telemetry. As shown in Fig. 3
(POD) for off-line verification purposes. This paper          the GPS-based navigation system is split into three
addresses the testing and validation of the GPS-based         modules located in different OBS levels and running at
flight software at DLR as a standalone unit prior to its      different sample rates.
full integration into the spacecraft onboard computer.
Thank to the model based PRISMA onboard software              The GPS interface (GIF) is part of the BSW, runs at 1 s
design, the navigation software can be implemented and        sample time and is directly fed with GPS messages is-
executed on different platforms in a fully consistent         sued by the Phoenix GPS receivers on-board MAIN and
manner. As illustrated in the paper, this allows a seam-      TARGET. GIF handles GPS raw data formats and
less transition between offline, real-time and hardware-      ephemerides, and performs data sampling as well as
in-the-loop tests during the validation phase. In particu-    coarse editing prior to the GPS-based orbit determina-
lar offline simulations are first conducted in a Mat-         tion. The GPS-based Orbit Determination (GOD) and
lab/Simulink environment on a standard host PC. Here,         GPS-based Orbit Prediction (GOP) are embedded in the
the flight software is stimulated through different           ASW layer as part of the ORB core (30 s sample time)
sources of GPS data with an increasing level of realism.      and the GNC core (1 s sample time), respectively.
Apart from the classical pure software simulations            GOD implements an extended Kalman filter to process
which make use of emulated GPS measurements, the              GRAPHIC observables as well as single difference car-
paper presents numerical results obtained from the us-        rier phase measurements from MAIN and TARGET.
age of real GPS flight data from the Gravity Recovery         Attitude data from both spacecraft are applied to correct
and Climate Experiment (GRACE) during the closest             for the GPS receivers antenna offset with respect to the
encounter of the twin satellites. As a next step a real-      spacecraft center of mass. Furthermore, a history of ma-
time hardware-in-loop test is conducted comprising two        neuver data is provided to GOD and taken into account
real Phoenix GPS receivers and a 2x12 channels Spirent        in the orbit determination task. GOD performs a nu-
GSS7700 GPS signal simulator [7]. Finally the com-            merical orbit propagation which is invoked after the
plete application is ported to a Real Time Executive for
measurement update and provides orbit coefficients for                                                    GNC, etc.) implementing guidance, navigation and con-
interpolation to GOP for both spacecraft.                                                                 trol, thermal control, power control, payload control
                                                                                                          functionalities etc.. All these application-cores are exe-
       BSW (1 s)                          ORB (30 s)                      GNC (1 s)                       cuted through a real-time monotonic scheduler, i.e. they
                                                                                                          all have a specified sample time and their priority de-
GPS MAIN GPS GIF               GPS Data         GOD          Orbit Data                GOP         User
                                                                                                          pends on the sample time: the smaller the sample time,
                   MAIN Attitude
SCA                                                                                          AFC          the higher the priority.
                   MAIN Man.

                                                                           Man. Cmd.

          TARGET Attitude
SS                                   TARGET

Figure 3 Simplified architecture and data interface of
the GPS-based software for PRISMA. The navigation
modules (GIF, GOP and GOD) as well as the control
modules (AOK, AFC) are incorporated in three onboard
software cores (BSW, ORB, GNC) executing at 1 s and
30 s sample times on the MAIN spacecraft.
The GOP module interpolates the orbit coefficients pro-
vided by GOD and finally supplies the various GNC
core functions as well as the PRISMA payload with
continuous position and velocity data of MAIN and
TARGET. Due to the different data rates of the GPS-
based navigation modules, orbit maneuver data have to
be taken into account in both GOD and GOP (cf. Fig.
3). In particular at each GNC step, the GOP task ac-
counts for maneuvers which have not been considered
by GOD in the last orbit determination/prediction proc-
ess. Among the users of the GPS-based navigation data
the Autonomous Formation Control (AFC) and
Autonomous Orbit Keeping (AOK) modules are located
in the GNC and ORB cores respectively.
2.2     Overall Development and Validation Concept

The PRISMA Onboard Software (OBSW) development
at the Swedish Space Corporation (SSC) makes use of
the Model Based Design (MBD) approach and is com-
pletely based on Matlab/Simulink [10]. The MBD
method raises the abstraction level for the system devel-
opment and is especially suited to efficiently handle
complex systems like e.g. the ones required to imple-
ment formation flying missions. The adoption of this
development strategy can be compared to previous steps
                                                                                                          Figure 4 Illustration of software development (top) and
which have been taken in the history of software pro-
                                                                                                          software validation (middle) environments at DLR and
gramming languages, like for example from assembler
                                                                                                          consequent integrated system level tests (bottom) at
to C/C++, switching from a lower abstraction level lan-
                                                                                                          SSC. The functionalities of the Orbit Propagator, GPS
guage to a higher one. MBD can be seen as a natural
                                                                                                          Emulator and Flight Software are located in different
step in this evolution chain, where emphasis is given to
                                                                                                          hardware units during the development and validation
system engineering instead of focusing on software en-
                                                                                                          phase and are indicated between quotes.
                                                                                                          The application cores are implemented as input/output
As stated earlier, the PRISMA OBSW consists of two
                                                                                                          functions. When the desired inputs and outputs of the
main layers, BSW and ASW respectively. The ASW
                                                                                                          application-cores have been specified, parallel software
consists of a number of application-cores (e.g., ORB,
development is made easy. A dummy-core can always              clocked at 24 Mhz, and is complemented by a GRFPU
replace the real application core and the necessary ser-       Floating Point Unit. All RAM blocks (cache and regis-
vices, as specified by the core-interface, and is prepared     ter-file memory) are Single Event Upset (SEU) pro-
at the same time as the core-algorithms are being devel-       tected. Real-Time-Workshop is used to automatically
oped.                                                          generate C-code out of the Matlab/Simulink tests previ-
                                                               ously executed on the host PC. The generated code is
The DLR software contribution to the PRISMA OBSW
                                                               compiled and linked with the handwritten C++ flight
has to be pictured in this frame and consists of specific
                                                               software libraries (i.e., the S-function wrappers) using
application-cores within the ASW. The real-time navi-
                                                               the RTEMS cross-compilation system (RCC).
gation system development follows the same overall
approach but makes extensive use of C/C++ modules to           The next sections will present a more detailed descrip-
implement the computationally intensive core naviga-           tion of the tests specification, goals and results for each
tion functions. Use of Simulink is thus restricted to          of the aforementioned validation phases:
wrappers providing the abstract top level software and
                                                                     1.    Pure software simulations using Phoenix re-
interface description. This enables a fully consistent
                                                                           ceivers emulated data (PEM).
validation of the flight software as a standalone unit at
DLR prior to the system integration. As illustrated in               2.    Pure software simulations using GRACE GPS
Fig. 4, a step-wise approach is adopted for the valida-                    flight data before, during and after the closest
tion of the navigation system.                                             encounter.
In a first phase the flight software, wrapped through                3.    Hardware-in-the-loop simulations in open-loop
dedicated Simulink S-functions, is executed on a stan-                     including the Spirent GSS7700 signal simula-
dard laptop PC (cf. Fig. 4, top) and stimulated by differ-                 tor and Phoenix receivers units.
ent sources of raw GPS data. The simplest simulations
make use of emulated GPS measurements generated by                   4.    Memory load and max-path unit tests executed
                                                                           on a LEON-3 board with a FPGA configura-
the Phoenix EMulator (PEM) software. PEM allows a
realistic modeling of measurements issued by a GPS                         tion matching the MAIN onboard computer.
receiver in LEO. More specifically, PEM emulates the
output messages for raw measurements, navigation so-           3.    FLIGHT SOFTWARE VALIDATION
lutions and broadcast ephemerides generated by the
Phoenix GPS receiver. As a next step raw single fre-           3.1        Simulation Scenario
quency GPS data (from JPL’s BlackJack receivers) col-
                                                               A unique simulation scenario is adopted for the test
lected during the swap phase of the GRACE satellites
                                                               campaign documented in this paper. The general speci-
are used (December 9-10, 2005). During this period,
                                                               fication and the detailed GPS signal simulator scenario
both satellites are flying in close formation (baseline
                                                               can be found in [11] and [12]. Exception is made of
<10 km, minimum separation around 400 m) on two
                                                               course for the test using real GRACE data, where the
slightly different orbits. This constitutes the to-date only
                                                               scenario is forced to match the real conditions of the
available set of real GPS data for satellites flying in
                                                               formation. The initial orbital elements of the TARGET
close formation.
                                                               satellite have been chosen to provide a representative
In a second phase the flight software is validated in real-    reference for PRISMA.
time through the inclusion of hardware in the loop. The
offline software blocks in charge of numerical orbit           Table 1 Initial formation configuration.
propagation and Phoenix receiver emulation (cf. Fig. 4,
                                                                Epoch 2. July 2006, 00:00:00.0 GPS time
top) are replaced by a 2x12 channels Spirent GSS7700
                                                                Mean TARGET Keplerian Elements                       Value
GPS signal simulator and two Phoenix GPS receivers              Semi-major axis (a) [m]                            7078135
(cf. Fig. 4, middle) fully representative of PRISMA             Eccentricity (e) [ ]                                 0.001
flight units. The flight software is still integrated in a      Inclination (i) [°]                                  98.19
pure Matlab/Simulink environment with the introduc-             Long. of ascend. node (Ω)[°]                         10.76
tion of dedicated S-functions for data reading/writing          Arg. of perigee (ω) [°]                                0.0
from/to serial ports of the host PC. This paper presents        Mean anomaly (M) [°]                                   0.0
results from open-loop hardware-in-the-loop simula-             Relative Orbital Elements (as defined in [5])        Value
tions only without the inclusion of orbit maneuvers.            Semi-major axis difference (Δa) [m]                    0.0
                                                                Lenght of relative eccentricity vector (aΔe) [m]     200.0
The preliminary evaluation of the memory usage and              Lenght of relative inclination vector (aΔi) [m]      100.0
computational load of the DLR’s flight software is per-         Relative argument of perigee (ϕ)[°]                  100.0
formed on a LEON-3 microprocessor FPGA board                    Relative argument of latitude (ϑ) [°]                 40.0
which is representative of the MAIN spacecraft onboard          Relative mean argument of latitude (aΔu) [m]           9.3
computer. The CPU is based on a SPARC V8 processor,
A dusk-down sun-synchronous orbit with about 98.2°               A YUMA almanac for 2 July 2006 (GPS week 1381) is
inclination, 18h nominal local time at the ascending             used to define a constellation of 29 active GPS satel-
node (LTAN) and 0.001 eccentricity is considered. The            lites. Broadcast ephemerides were simulated with a
initial conditions for the MAIN spacecraft are derived           SISRE of 2 m (i.e., slightly higher than the presently
from TARGET by adding the desired set of relative                achieved performance of 1-1.5 m) and a VTEC of 10
orbital elements [5]. The nominal configuration corre-           TECU was assumed in the modeling of ionospheric path
sponds to a bounded, centered geometry. For complete-            delays.
ness the initial TARGET orbital elements and the initial
                                                                 A realistic antenna gain profile for the PRISMA GPS
relative orbital elements are listed in Tab. 1. The nomi-
                                                                 antennas (Sensor Systems S67-1575-20) is adopted and
nal spacecraft attitude is aligned with the orbital frame,
                                                                 measurements were generated for all visible GPS satel-
with the active GPS antennas pointing in zenith direc-
                                                                 lites within less than 85° about the boresight direction.
                                                                 Bandwidths of 0.08 Hz and 9 Hz are assumed for the
                                                                 delay locked loop and phase locked loop to replicate the
3.2    Spacecraft Parameters and Dynamic Model                   variation of code and carrier phase noise with signal-to-
                                                                 noise ratio in the Phoenix receiver.
Spacecraft parameters are affecting the simulation                       10
through the numerical propagation of the orbit with                         5

time. Furthermore, the drag coefficient is estimated as

                                                              R [m]

part of the orbit determination process. The spacecraft                   -5

parameters for the simulation scenario are collated in                -10
                                                                         0                        5        10           15   20   25

Tab. 2.                                                                     5

Table 2 Relevant PRISMA spacecraft parameters.                              0
                                                              T [m]

 Parameter                             MAIN     TARGET
 Spacecraft area [m2]
                                        0.67       0.23                  0                        5        10           15   20   25

 Spacecraft mass [kg]                    150         50                     4

 Aerodynamic drag coeff. [-]              2.3       2.1
 Solar radiation pressure coeff. [-]      1.3       1.4
                                                                 N [m]


Here, it is assumed that the solar arrays of MAIN and                     -2
                                                                            0                     5        10           15   20   25
TARGET are pointing in Sun direction which is close to                                                          [h]

normal to the orbital plane. Thus, the surface area can
be approximated from the body dimensions of the                  Figure 4 Absolute navigation error computed by sub-
spacecraft bus structure as 0.8x0.8 m2 and 0.3x0.8 m2            tracting the exact reference trajectory position from the
for MAIN and TARGET, respectively. Drag and solar                MAIN absolute GOP position each second.
radiation pressure coefficients are assumed to differ by                  0.01

about 10% for the two spacecraft. As can be seen from                 0.005
                                                             R [m]

Tab. 2, the ballistic coefficients of MAIN and TARGET                            0

differ by about 6%. The force model for the numerical
orbit propagation considers the aspherical Earth gravity                                      5       10               15    20    25

field through an expansion in spherical harmonics up to                   0.01

degree and order 20 based upon coefficients from the                  0.005
                                                             T [m]

GGM01S gravity model. Furthermore, the Sun and                                   0

Moon third body forces are computed based on analyti-
cal models for the Sun and Moon position. Non-                                                5       10               15    20    25

gravitational accelerations of drag are based on a modi-                         2
                                                                                      x 10

fied Harris-Priester model and solar radiation pressure                          0
                                                                         N [m]

which considers a fractional illumination of a spacecraft                        -2

assuming a cylindrical shadow model.
                                                                                              5       10               15    20    25

3.3    Offline Validation using PEM                              Figure 5 Relative navigation error computed by sub-
                                                                 tracting the exact reference relative position from the
Simulated raw measurements (and navigation solutions)
                                                                 GOP relative position each second.
for both spacecraft are generated by the PEM software
based on the orbit and attitude profiles described above         Typical results from a 24 hours long simulation are il-
and taking into account the known antenna offsets in the         lustrated in Fig. 4 and Fig. 5. For a matter of concise-
spacecraft body frame.                                           ness only the absolute and relative position errors are
             depicted. These are the most important indicators of the                             GPS seconds and are consequently not synchronized
             nominal software execution and performance. In this                                  with raw GPS measurements. The accuracy of the navi-
             paper the relative position error is always mapped into                              gation process is evaluated by comparing the output of
             the orbital frame centered on TARGET and projected                                   GOP in the WGS84 reference frame with the aforemen-
             along the radial (R), along-track (T) and cross-track (N)                            tioned precise reference trajectory. Absolute and rela-
             directions. The achieved absolute navigation accuracy is                             tive navigation accuracy results are shown in Fig. 6-7.
             below 2.1 m (1D, r.m.s), while the achieved relative
                                                                                                  The achieved absolute navigation accuracy is below
             navigation accuracy is below 0.005 m (1D, r.m.s).
                                                                                                  2.0m (1D, r.m.s), while the achieved relative navigation
                                                                                                  accuracy is below 0.04 m (1D, r.m.s).
             3.4             Offline Validation using GRACE flight data                                0.50


                                                                                     Radial [m]
             The offline validation of the flight software using                                       0.00

             GRACE flight data is mainly intended to verify the                                        -0.25

             navigation software functionality, the absolute and rela-                                 -0.50
                                                                                                            0   2   4       6       8    10        12         14        16        18        20        22        24

             tive navigation accuracy using real GPS data, to verify                                   0.50

             real GPS data editing and rejection and to confirm the

                                                                                     Along-track [m]

             realism of the adopted simulation environment for soft-                                   0.00

             ware evaluation purposes.                                                                 -0.25

                                                                                                            0   2   4       6       8    10        12         14        16        18        20        22        24
             The test is performed in a pure Matlab/Simulink envi-
             ronment on a standard laptop PC. Raw single frequency                   Cross-track [m]
             GPS data (from JPL’s BlackJack receivers) are col-                                        0.00

             lected during the swap phase of the GRACE satellites                                      -0.25

             (December 9-10, 2005 or doy 243-244). During this                                         -0.50
                                                                                                            0   2   4       6       8    10        12         14        16        18        20        22        24

             period, both satellites are flying in close formation with                                                                            [h]

             inter-satellite separations between 10 km and 400 m.                                 Figure 7 Relative navigation error computed by sub-
             PEM is simply replaced by a unique S-function which                                  tracting the Precise Orbit Determination (POD) refer-
             reads the raw GPS data of GRACE-A & B provided in                                    ence trajectory relative position from the MAIN relative
             RINEX format and feeds the navigation software with                                  GOP position each second.
             Mitel F40 and F62 messages (i.e., Phoenix receiver out-
             put data format) every 10 s. The handling of F14 mes-                                During the first test runs using GRACE data, a jump of
             sages is also performed by the S-function using the real                             1.5 m in the relative navigation error has been observed
             broadcast ephemeris tables for the doy 243-244.                                      at the junction between doy 243 and 244. This anomaly
                                                                                                  was due to the fact that the RINEX data are post-

                                                                                                  processed to compensate for the GPS receiver clock
Radial [m]

                                                                                                  offset on a daily base.
                   -5                                                                                    20
                                                                                     clock offset [m]

                  -10                                                                                    15

                     0   2      4   6   8   10   12    14   16   18   20   22   24
Along-track [m]

                                                                                                           0    2   4   6       8       10    12         14        16        18        20        22        24

                   -5                                                                                    20
                                                                                     clock offset [m]

                  -10                                                                                    15

                     0   2      4   6   8   10   12    14   16   18   20   22   24
Cross-track [m]

                                                                                                           0    2   4       6       8    10        12         14        16        18        20        22        24


                     0   2      4   6   8   10   12    14   16   18   20   22   24
                                                                                                  Figure 8 Estimated BlackJack GPS receiver’s clock
                                                                                                  offset for GRACE-A (top) and GRACE-B (bottom) in
             Figure 6 Absolute navigation error computed by sub-                                  units of meters.
             tracting the Precise Orbit Determination (POD) refer-
                                                                                                  The clock offset correction affects differently the GPS
             ence trajectory position from the MAIN absolute GOP
                                                                                                  data from doy 243 and 244 and results in a re-
             position each second.
                                                                                                  assessment of the navigation filter. As a counter meas-
             For simplicity the navigation filter is initialized using                            ure the maximum allowed difference between consecu-
             accurate state vectors from a precise reference trajectory                           tively observed GRAPHIC ambiguities has been set via
             (4 cm, 3D, r.m.s.). This minimizes the convergence time                              telecommand to 1 m, providing an improvement of the
             of the filter and avoids the additional post-processing of                           relative navigation accuracy which is not affected any-
             navigation solutions that are not available at integer                               more by discontinuities. For completeness, the esti-
               mated clock offset is plotted for GRACE-A and                                                                                                          and GOP and 30 s for GOD. The synchronization be-
               GRACE-B in Fig. 8 in units of meters.                                                                                                                  tween the simulation tick and the GPS receivers time is
                                                                                                                                                                      achieved by activating the generation of F48 messages
               3.5                   Real-time validation using GPS hardware
                                                                                                                                                                      at a 1 Hz rate. The onboard spacecraft elapsed time as
               The GPS Signal Simulator (GSS) test scenario is speci-                                                                                                 needed by GIF, GOD and GOP is computed from the
               fied in [12] and implemented through the SimGEN                                                                                                        GPS receiver time as provide by the F40 and F62 navi-
               software for Windows [7]. As listed in Tab. 1, the initial                                                                                             gation messages. The PRISMA software telecommands
               epoch is chosen as 2. July 2006, 00:00:00.0 GPS Time,                                                                                                  are set in accordance with the simulation scenario.
               and coincides with the ascending node crossing. Ac-                                                                                                    Nominal attitude information is provided to GOD to
               cordingly a value of GPS-UTC=14 s has been adopted                                                                                                     compensate for the CoM-GPS antenna offsets in the
               for the scenario. The GPS constellation is modeled                                                                                                     measurement modeling. No orbit maneuvers are in-
               based on the actual GPS almanac for week 1381, which                                                                                                   cluded in the hardware-in-the-loop simulation.
               is propagated to the scenario time within the signal                                                                                                   The simulation starts with a warm start of both receivers
               simulator. Ionosphere path delays correspond to a                                                                                                      commanded from Matlab/Simulink. The GIF status byte
               VTEC of 10 TECU, like emulated in PEM. In an effort                                                                                                    for the MAIN spacecraft is plotted for the first 100 s in
               to mimic a realistic User Equivalent Range Error, inten-                                                                                               order to show the initialization phase in more details (cf.
               tional broadcast ephemeris errors are applied with uni-                                                                                                Fig. 9). The first valid 3D navigation fix is obtained
               formly distributed random offsets in radial direction                                                                                                  within the first minute (cf. Valid navigation from F40
               with zero mean and a standard deviation of 1.5 m. The                                                                                                  flag in Fig. 9). The GPS s/c ephemerides are always
               antenna diagram is based on the specified gains of the                                                                                                 complete for the available measurements, thus GIF is
               Sensor Systems S67-1575-141 antenna. The following                                                                                                     properly requesting F14 messages from the GPS receiv-
               antenna offsets with respect to the center of mass are                                                                                                 ers.
               applied for MAIN (+1.2845,+0.398,+0.361) m (R,T,N)                                                                                                     0.010

               and TARGET (+0.3627,+0.0065,-0.0638) m (R,T,N).                                                                                                        0.005
                                                                                                                                                    Radial [m]

               The antenna orientation is always aligned with the ze-                                                                                                 0.000

               nith direction during the simulation.                                                                                                                  -0.005

                                                                                                                                                                            0    2     4       6          8   10     12      14     15
                                                         Mitel Msg arrived

                            1                                                       1                                  1
Bytes arrived


                                                                                                                                                    Along-track [m]


                            0                                                       0                                  0                                              0.000

                            0   25      50    75   100                              0   25      50    75   100         0   25      50    75   100                     -0.005
                                     Time [s]                                                Time [s]                           Time [s]
                                                         At least one sat tracked

                                                                                                                                                                            0    2     4       6          8   10     12      14     15
                            1                                                       1                                  1


                                                                                                                                                    Cross-track [m]


                            0                                                       0                                  0                                              0.000

                            0   25      50    75   100                              0   25      50    75   100         0   25      50    75   100                     -0.005
                                     Time [s]                                                Time [s]                           Time [s]
Valid navigation from F40

                                                                                                                                                                            0    2     4       6          8   10     12      14     15

                                                                                                                                                                      Figure 10 Relative navigation error computed by sub-
                            0                                                                                                                                         tracting the exact reference trajectory relative position
                            0   25      50    75   100                                                                                                                from the MAIN relative GOP position each second.
                                     Time [s]

                                                                                                                                                                      Fig. 10 shows the relative navigation error obtained
               Figure 9 Status byte generated by the GPS InterFace
                                                                                                                                                                      from the comparison of the real-time navigation output
               (GIF) flight software during the first 100 s of the hard-
                                                                                                                                                                      of GOP with the exact ephemeredes data logged from
               ware-in-the-loop simulation.
                                                                                                                                                                      the GPS Signal Simulator. The relative navigation accu-
               The standard simulation environment is simply com-                                                                                                     racy amounts to ca. 0.002 m (1D, r.m.s.), while the ab-
               plemented by two S-functions which read/write data                                                                                                     solute navigation accuracy (not shown) is ca. 2.2 m (1D,
               from/to the host PC serial ports. To that purpose, stan-                                                                                               r.m.s.). Note that these figures are obtained from the
               dard windows functions for serial communication (e.g.,                                                                                                 processing of the complete simulation arc, including the
               ReadFile, WriteFile) are used. This dedicated interface                                                                                                initialization phase of the GPS hardware and the con-
               allows full control of the Phoenix GPS receivers. In                                                                                                   vergence of the extended Kalman filter in GOD.
               particular the S-functions allow the generation of cold
                                                                                                                                                                      3.6       Tests on LEON-3 board
               start commands, the execution of warm start initializa-
               tion procedures and the provision of Transmit Ephem-                                                                                                   The tests performed on the LEON-3 board are of three
               eris (TE) commands as generated by the GIF flight                                                                                                      typologies. First long-term runs are executed which re-
               module to the GPS receiver. The Matlab/Simulink soft-                                                                                                  produce identically the aforementioned tests on the host
               ware is executed at the basic sample time of 1 s for GIF
PC. Based on this, max-path tests are defined and im-            In order to verify the effectiveness and reliability of this
plemented to determine the maximum CPU load of each              test, the same procedure has been applied to a dummy
software module. Finally dynamic memory allocation               software known to cause memory leakage problems due
tests are executed to determine the flight software usage        to an improper management of the dynamic memory.
of the heap.                                                     The information given by the test has been used to accu-
                                                                 rately forecast the stuck of the software run due to mem-
The tests performed on the host PC are identically re-
                                                                 ory saturation. The rightness of this forecast has demon-
produced on the LEON-3 board in a RTEMS environ-
                                                                 strated the validity of the test. As shown in Fig. 11, the
ment. Each Matlab/Simulink model is used to automati-
                                                                 flight software modules do not cause memory leakage
cally generate C-code via Real-Time-Workshop. The C-
                                                                 by a proper allocation and de-allocation of memory.
code is compiled and linked with the handwritten C++
libraries (S-function wrappers) using the RTEMS cross-                53625
                                                                                                            Available memory

compilation system. An accurate analysis of the long-

term simulations executed on the LEON-3 board en-                     53624

ables the definition of reliable max-path unit tests.
These tests reproduce the conditions of maximum com-                       0    1   2   3   4    5      6       7     8        9   10   11   12   13   14   15

putational load for each flight software module. In par-                 42
                                                                                                  Allocated and not released Heap

ticular GIF, GOD, GOP, AFC and AOK are stimulated                      41.5

with specific constant inputs that provide the maximum                   41

computational effort on the LEON-3 board. Dedicated                      40
                                                                           0    1   2   3   4    5      6       7     8        9   10   11   12   13   14   15
RTEMS functions (e.g., rtems_clock_get) are used to
                                                                                                Heap allocation calls without release
estimate the execution time of each software module.                    197

The dynamic memory allocation is closely monitored to                 196.5

determine if memory leaks exist in the heap region of                 195.5
the LEON-3 board RAM. The RTEMS function mal-                           195
                                                                           0    1   2   3   4    5      6       7     8        9   10   11   12   13   14   15
loc_info(index), which is a modified version of the                                                             Time [h]

function malloc_dump(void), is used to obtain informa-           Figure 11 Verification of GPS-based flight software
tion about the heap usage during run-time for each               usage of the LEON-3 heap memory region. The totally
software module.                                                 available memory (top), the allocated/not released heap
                                                                 (middle) as well as the heap allocation calls without
Table 3 Maximum execution times and CPU load of the              release (bottom) are constant during the tests.
GPS-based flight software for PRISMA.
Software module     Maximum execu-      Maximum CPU              4.            SUMMARY AND WAY FORWARD
 and sample time     tion time [ms]       load [%]
                                                                 The presented paper has shown the compliance of the
GIF (1 s)                 88                   9
                                                                 GPS-based navigation software to the main require-
GOP (1 s)                 58                   6
                                                                 ments of the PRISMA formation flying mission. Offline
GOD (30 s)               7396                 25
                                                                 real-world simulations which make use of real GPS
AFC (1 s)                 63                  0.2
                                                                 flight data from GRACE as well as real-time hardware-
AOK (30 s)                15                  1.5
                                                                 in-the-loop simulations in open-loop provide absolute
Tab. 3 lists the measured maximum execution times                and relative navigation accuracy figures at ca. 2 m and
obtained from the max-path unit tests on the LEON-3              ca. 0.05 m (1D, r.m.s.). Furthermore the navigation
board at DLR. Similar figures are obtained when exe-             software functionality and data interface have demon-
cuting the tests on the MAIN Engineering Model board             strated to behave as expected. The paper shows for ex-
at SSC. The CPU loads are computed by dividing the               ample how dedicated telecommands have been used to
maximum execution time of each software module by                improve the data editing of GPS flight data or how
its sample time (i.e., 1s for GIF, GOP and AFC and 30s           commands are automatically generated by the flight
for GOD and AOK). GOD and GIF generate the maxi-                 software to request the issue of missing GPS ephemere-
mum peaks of the CPU load with 9% and 25% respec-                des from the GPS receivers. The validation of the flight
tively. Because of this, they are implemented as low             navigation software is complemented by its extensive
priority tasks on the MAIN onboard computer.                     testing on a LEON-3 board fully representative of the
                                                                 PRISMA onboard computer. The implementation of
The following information is retrieved by the analysis of        max-path tests and memory allocation tests has given
the LEON-3 heap memory status before and after each              the possibility to evaluate the computational and mem-
call of the software modules:                                    ory loads of the application embedded into the target
    1.   Allocated and not released heap size.                   microprocessor. Despite the promising results, the vali-
                                                                 dation of the GPS-based real-time navigation software
    2.   Number of allocation calls without release.             cannot be considered complete as documented here.
First of all some relevant sources of GPS measurement              Formation Flying Mission; DLR/GOSC, PRISMA-
errors have been neglected, like e.g. multi-path effects           DLR-TN-11, Issue 02/08 (2006).
and uncertainties in the spacecraft attitude knowledge.       [12] M. Garcia-Fernandez, S. D'Amico; Scenario Defi-
Secondly maneuvers have not been incorporated in the               nition for PRISMA Software Tests using a GPS
navigation process and only open-loop hardware-in-the-             Signal Simulator; DLR/GSOC, PRISMA-DLR-
loop tests have been illustrated. Finally the PRISMA               TST-41, Version 2.0, October 16 (2007).
navigation software will have to face critical operational
scenarios like the spacecraft separation after initial sys-
tem checkout or attitude tumbling phases during safe
modes and contingencies. In view of these considera-
tions further detailed investigations are recommended
and are under preparation for future publication.

[1] Persson S., Jakobsson B., and Gill E.; PRISMA
     demonstration mission for advanced rendezvous
     and formation flying technologies and sensors;
     Number 05-B56B07, 56th International Astronauti-
     cal Congress, Fukuoka, Japan, International Astro-
     nautical Congress (2005).
[2] Gill E., D’Amico S., Montenbruck O.; Autonomous
     Formation Flying for the PRISMA Mission; Journal
     of Spacecraft and Rockets 44/3: 671-681 (2007).
[3] Montenbruck O., Markgraf M.; User’s Manual for
     the Phoenix GPS Receiver; DLR/GSOC; GTN-
     MAN-0120; Issue 1.7, 06 June (2006).
[4] D’Amico S., Gill E., Garcia-Fernandez M., Mon-
     tenbruck O.; GPS-based Real-time Navigation for
     the PRISMA Formation Flying Mission; 3rd ESA
     Workshop on Satellite Navigation User Equipment
     Technologies, NAVITEC’2006, 11-13 December
     2006, Noordwijk (2006).
[5] D'Amico S., Gill E., Montenbruck O..; Relative
     Orbit Control Design for the PRISMA Formation
     Flying Mission; AIAA Guidance, Navigation, and
     Control Conference, 21-24 Aug. 2006, Keystone,
     Colorado (2006).
[6] De Florio S., D’Amico S. and Garcia Fernandez
     M.; The Precise Autonomous Orbit Keeping Ex-
     periment on the PRISMA Formation Flying Mis-
     sion; AAS 08-212, Space Flight Mechanics Meet-
     ing, Texas, USA, (2008).
     DGP00792AAA (2006).
[8] Gaisler J.; The LEON Processor User’s Manual
[9] Gill E.; Requirements for DLR’s Contributions to
     Version 1.4, December (2005).
[10] Edfors A.; PRISMA ASW Subsystem Description;
     Document ID: SSPH1000-S38; Version 1.0; Swed-
     ish Space Corporation, Solna (2005).
[11] Gill E.; Simulation Scenario for GPS-based Guid-
     ance, Navigation and Control within the PRISMA