EGNOS Central Processing Facility architecture and design

*J.Westbrook, J.Ventura-Traveset, European Space Agency

A. Rérolle, Alcatel Space Industries
H. Blomenhofer, I. McAnany - Astrium GmbH (formally Dornier Satellitensysteme GmbH)
J. Cosmen, - GMV SA
W. Werner, IfEN GmbH

Abstract
The European Geostationary Navigation Overlay Service (EGNOS) is being developed in
Europe to provide users with regional augmentation to the existing satellite constellations of GPS
and GLONASS. The EGNOS System is being designed to serve a multi modal community in
Europe, of which the principle users are expected to be Civil Aviation, Maritime, In-Land Water
Navigation and docking, rail and road transport and traffic monitoring systems. For civil
aviation, EGNOS Advanced Operational Capability (AOC) will provide a primary means service
of navigation for en-route oceanic and continental, non-precision approach and CAT-I precision
approach within the ECAC (European Civil Aviation Conference) area. EGNOS Full
Operational Capability (FOC), which follows the AOC phase, will ensure sole means operation.

The provision of real time Navigation and Integrity Information for Europe's multi- modal users
is undertaken by the EGNOS Central Processing Facility (CPF). This paper presents the
architecture and design of the CPF and introduces it’s two major components, namely the CPF
Processing Set and the CPF Check Set. The algorithms which are used to provide the Navigation
and Integrity Information for EGNOS are introduced and a presentation on the expected
performances available to EGNOS users is made and consolidated with test results.

* Contact Author
European Space Agency, 18 avenue Edouard Belin, 31055 Toulouse Cedex (France)
Tel: (33) 5 61 28 28 65 - Fax: (33) 5 61 28 28 66
E-mail: jwestbro@esa.hq.fr
EGNOS Central Processing Facility – Architecture and Design Page 2 of 17

EGNOS and the role of the CPF

The Central Processing Facility is the computational heart of the EGNOS system. It provides the
corrections and integrity information that are broadcast over the EGNOS service area. The CPF
therefore drives the EGNOS system level performance. The performance apportionment given to
the CPF is derived from the ICAO SARPS Signal in Space requirements.

The CPF is an integral part of the EGNOS Master Control Centre (MCC). It will be co- located at
each MCC with a Central Control Facility (CCF). Each CPF is dimensioned to compute
corrections for each GEO satellite in the EGNOS system. Therefore a Processing and Check
capability for each GEO satellite in the EGNOS system is required. The CPF also monitors the
other SBAS satellites visible by the EGNOS RIMS and provides integrity information regarding
these observations. The CPF shall be capable of being expanded to meet future satellite
constellation expansions as well as utilisation of the full EGNOS FOC architecture.

Using measurements from the RIMS (Ranging and Integrity Monitoring Stations) spread
principally over the EGNOS coverage area, the CPF Processing Set generates the following
applicable data for EGNOS users.

• wide area differential corrections for GPS, Glonass and Geo satellites
• ionospheric delay information
• integrity data (for the confidence of differential and ionospheric corrections)
• alarms (for individual satellites or ionospheric grid points when necessary)
• Geo satellite positioning data
• EGNOS network time/UTC offset parameters

The Integrity of the broadcast information must also be checked to protect all EGNOS users
from applying hazardous misleading information. This must be done within stringent SARPS
Time to Alert requirements. The Integrity checking must also detect and exclude satellite
anomalies that may cause hazardous misleading information for EGNOS users. Specific RIMS
support the CPF Check Set in this functio n.
EGNOS Central Processing Facility – Architecture and Design Page 3 of 17

CPF Architecture
The Processing Set (CPFPS) is designed to generate the EGNOS wide area correction data, two
redundant Check Sets (CPFCSs) in a CPF perform the Integrity check of the overall EGNOS
service and, in particular the CPFPS’s correction and integrity data. All correction data are
organized by a CPFPS into different messages and sent successively to a number of Navigation
Land Earth Stations (NLESs). Each NLES is linked to one Geo which will broadcast its assigned
sequence of messages. The messages passed on to the NLESs are called “operational” messages
(see “Op. Msg.” in Figure 1). Individual operational messages are determined for each Geo
satellite in the operational message generation function. They are derived from Geo independent
data (such as ephemeris corrections, ionospheric corrections (GIVD) and error bounds (GIVE))
and Geo dependent data (such as slow and fast clock corrections and error bounds (UDRE)) all
of which are the output of the Correction Generation (see Figure 1).

The CPFCS checks operational messages proposed for transmission (before uplink) and
operational messages already sent and received by the RIMS network (after downlink). The
CPFCS reassembles a full set of linked corrections (iono-delays, integrity data etc…) from each
sequence of messages broadcast. This set is called the Navigation Overlay Frame (NOF). The
content of messages is monitored by the CPFCS by applying all data from the corresponding
NOF to GPS/Glonass/Geo raw data (pseudoranges and ephemeris) independently from the
CPFPS. For the operational messages, the dedicated function is called “Operational NOF Check”
(see Figure 1).

The NOF associated to messages already being sent and passed on by RIMS via the EGNOS
Wide Area Network (EWAN) to the CPF is called NOF-Signal- in-space (NOF-SIS). One half of
the “Operational NOF Check” checks this NOF-SIS (“check after downlink” or just “check-
after”). There is a 5 second delay before a broadcast message comes back through the RIMS
network to the CPF. Because of this delay, at a given time the NOF-SIS is different to what a
user might currently apply. In order to reduce alarm times in addition to the NOF-SIS a second
NOF is built and checked. To facilitate this, the last 4 messages already being sent are directly
sent back to the CPF by the NLES. These 4 messages, the current message proposed to transmit
EGNOS Central Processing Facility – Architecture and Design Page 4 of 17

and the NOF-SIS form the so-called “NOF-up”. This NOF-up is checked by the second half of
the operational NOF check (“check before uplink” or “check-before”).

There are several redundant CPFs in EGNOS all offering messages to the NLESs, but only
certain CPFs provide the actually transmitted messages. These CPFs are designated as “selected”
by the NLES, the other CPFs are called “backup”. A selected CPF sends the full set (all types) of
messages, a CPF that has been notified that it is backup (CPF not selected) just sends satellite
integrity data (UDREs in message type 6). This implies, that the CPFCS of a backup CPF cannot
pick the CPFs internal corrections out of the operational messages. In order to monitor the
backup CPF’s complete set of internal corrections and integrity data by its independent CPFCS,
they are formatted by the CPFPS into internal messages, transmitted to the CPFCS and checked
in the Internal NOF check. There is only one sequence of internal messages, since they are not
dependent on a Geo satellite.

The CPF selection by a NLES is based on a Quality of Service figure and Go/Nogo flags
provided by each CPFPS and CPFCS of a CPF and transmitted separately to each NLES, (see
Figure 1). The Quality of Service figures are derived from the broadcast integrity (UDRE and
GIVE) taken from internal CPF messages.

In addition to the raw data and EGNOS messages transmitted to the CPF by the RIMS A & B
network, a RIMS C network is provided specifically designed to detect satellite anomalies. Each
RIMS C provides individual satellite warning flags to the CPFCSs. If a majority of RIMS C
indicate a warning for a given satellite, that satellite will be marked as “Don’t Use” by the
CPFCS in a message to the CPFPS. The CPFPS then inserts the necessary alarm into the
operational message set.
EGNOS Central Processing Facility – Architecture and Design Page 5 of 17

PS-QOS PS Quality figure

UDREs
GIVEs
per Geo

Internal Msg Sv-pos Operational Msg 4 Last Msg

RIMS ant. broadcast,
RIMS ant. Generation coord. Generation CPF sel'd
Fast & Slow clock coord.
UDRE (T2 & T6)
ENT sync. par. don't
Ephemeris corr. use
Raw-meas
Ch/RIMS status Correction GIVD/GIVE
RIMS A/B Ephemeris Generation Sv-pos
NOF-SIS PS-
NOF-SIS Preproc'd
L1/L2 meas Internal Go/Nogo

Check
Internal Msg
Processing Set Op. Msg,
not mon'd/ ENT -steer
NLES
don' t use

RIMS ant. Op. Msg

coord. +trans.par
Preproc'd
Raw-meas L1/L2 meas CPF sel'd
Ch/RIMS status Pre- Sv failre flags
RIMS B/A Ephemeris iono-obs.
NOF-SIS Processing Sv-pos
NOF-SIS 4 Last Msg
broadcast,
Internal NOF Operational NOF CPF sel'd
Sv-pos Check Check CS-
RIMS- ant. Go/Nogo
coord.
UDREs Go/Nogo
(Raw-meas) GIVEs Go/Nogo
Ch/RIMS status
RIMS C (Ephemeris)
(NOF-SIS)

CS-QOS CS Quality figure

RIMS
Check Set clock biases

Figure 1 – Central Processing Facility Functional Overview

EGNOS Central Processing Facility – Architecture and Design Page 6 of 17

CPF Processing Set

The CPF Processing Set is in charge of the computation of the navigation message to be
broadcast to the user through the NLES-GEO. Its high level functional architecture is depicted in
figure 2. The set is divided into five major components.

Compute
EGNOS
Feed- Information
back

Valid. EGNOS
Data Info

RIMS Common Processing EGNOS

raw pre-processing Output Message message
data and validation Management

Valid. Integ. & Qual.

Data Info

Check
Set Internal Check
Flags and Quality
evaluation

CCF
Commands Real Time Management
& Communications

Figure 2 - CPF Processing Set high level functional architecture

• RT Management & Communications. This provides and controls the external interfaces to the
EGNOS Wide Area Network allowing communications with RIMS, NLES, CCF and CPF
Check Set. This module is also in charge of internal communications management and of
monitoring the process of the rest of the modules, maintaining the proper processing sequence
and timing.

• Common pre-processing and validation. This function accepts the input data from the RIMS
and performs a validation screening upon it. It is in charge of minimising the systematic errors
present in the data by removing ionospheric and tropospheric delays. It detects and removes
carrier phase cycle slips and smoothes the input data to reduce the random noise and filter out
residual multipath components.
EGNOS Central Processing Facility – Architecture and Design Page 7 of 17

• Compute EGNOS Information This module is the core of the CPF Processing Set and
computes all the corrections and integrity information that is embedded in the EGNOS
messages broadcast to the users. This includes corrections to the navigation data of GPS,
GLONASS and GEO satellites, for both the orbital ephemeris and the satellite clock. It also
computes wide-area ionospheric vertical delays that are broadcast to the users for the
correction of their pseudorange data. This module maintains also the system time scale,
EGNOS network time, which is the reference for all broadcast clock corrections. Offsets to
UTC time are also provided to the users.

Finally, it computes upper error bounds for the satellite related corrections in the form of a
User Differential Ranging Error value (UDRE) for each satellite and for the ionospheric delay
values in the form of a grid of ionospheric vertical errors (GIVE).

• Internal Check and Quality Estimation. This module evaluates the integrity of the satellite and
ionospheric corrections computed by the "Compute EGNOS information" module and
broadcast to the user. It checks the consistency of the residual errors after corrections with
associated bounding (UDRE, GIVE). The module also provides an evaluation of the quality of
the service provided by the CPF Processing Set.

• Processing Output Message Management. This module selects the appropriate sequence to
transmit the messages to the user. It determines the actual message to be broadcast in the
current cycle and formats the message according to the standards set for the user receiver as
defined by ICAO SARPS.

The last 4 components include a set of complex mathematical algorithms whose capabilities are
directly driving the overall EGNOS performance. In particular, computation of the UDRE and
GIVE is one of the most critical issues of the Processing Set as these bounding algorithms are
vital to EGNOS integrity yet impact the continuity and availability of the EGNOS Signal in
Space.
EGNOS Central Processing Facility – Architecture and Design Page 8 of 17

CPF Check Set

The task of the CPF Ind ependent Check Set (CS) is to support the EGNOS user’s positioning
integrity. However, as the monitoring stations (RIMS) can neither observe all user- local effects
nor check all possible user satellite geometries, only the RIMS observed signal- in-space can be
validated sufficiently. The task of the CS is to verify the correctness of the EGNOS messages
that have been generated by the CPF Processing Set (CPFPS).

There are two main types of correction information provided to the user: satellite corrections and
ionospheric corrections. The first include satellite orbit and clock corrections, while the latter
consist of vertical ionospheric delays at some pre-defined ionospheric grid points (IGPs). Both
types of corrections come with an error bound, which is called UDRE for satellite corrections
and GIVE for ionospheric corrections.

Due to the compact EGNOS message format, stand-alone messages are useless for any user. To
extract the necessary information, at least some message context has to be known by the user.
The CS is required to work to some degree “user-like” as it has to apply the corrections in a user-
like way. Based on the RIMS measurements and their known positions, pseudorange residuals
can be obtained and some statistics applied to detect potential faults.

Having in mind the user-like approach on the one hand and the necessity to know the message
context to derive valid corrections on the other hand, this leads to a main design characteristic,
namely the division of the CS into two main subsets. These are the Check After Down-Link and
the Check Before Up-Link subsets.

Due to the demanding time-to-alarm requirement (6 s for CAT I), there is only a very short time
(about 50 ms) allowed for validating a generated message before it is sent to the user. For this
reason, it is not possible to guarantee the full integrity of the EGNOS information including the
new message. The check before is not capable of providing isolation and can only provide a
limited degree of fault detection. Therefore, it is necessary to have an additional, more thorough
check that has to be applied after the message has been broadcast. This quite strict check is
performed in the Check After subset.
EGNOS Central Processing Facility – Architecture and Design Page 9 of 17

In fact, as there is some common pre-processing on measurements and the CS is required to

output a Quality of Service figure, there are altogether four different subsets in one CS. In the
following we will concentrate only on the Check Before and Check After subsets. Both of these
are instantiated once for each operational lane (for each GEO to be supported by this CPF).
Additionally, there is one internal Check After, which verifies the integrity of the CPF, when it is
in backup-mode.

Check After
The Check After subset is the heart of the CS. It has to verify the user’s integrity based on all
active EGNOS messages. Statistical tests are performed to verify transmitted bounding (UDRE
and GIVE). The high performance requirements necessitate statistical tests that are not only
“user- like”. The design of the Check After subset (operational la ne) is depicted in figure 3.

To NLES
Check After In Operational NOF
Lane

RIMS Positions
RIMS Antenna CS Integrity
Coordinates Flag
Apply NOF (long
term position Corrected S/V Positions Estimate RIMS
corrections) Clock Biases

Raw S/V Positions

Clock Biases
From
Iono / Tropo / IFB free PR's
Preprocessing

Apply NOF (fast, Compute PR

& long term clock Fully Corrected PR's Residuals (Post To Preprocessing
corrections) Adjustment)

Self
Status
PR Residuals RIMS Clock
From Message NOF SIS Check & Decode Biases
Dec. & Route NOF

Check UDRE
UDRE's (incl. Isolation)

NOF Store
GIVD/GIVE's Check GIVE (incl.
L1 / L2 Combination
(Iono Observables) Isolation)
and measurement time

Don't Use /
Check After Not Monitored
Flags

To Processing Set To Check Before

Figure 3 – CPF Check After Functional Overview

For the UDRE check, all measurements to one single satellite are combined to obtain maximum
statistical information of this satellite and the quality of the correction to its pseudorange. The
UDRE check therefore is partially user- like, in that the EGNOS corrections are applied to the
EGNOS Central Processing Facility – Architecture and Design Page 10 of 17

pseudoranges, but then deviates from the user concept by making use of the whole RIMS
network.

The GIVE check combines all ionospheric information from dual- frequency GPS measurements
in a single estimation for the ionospheric delay at the EGNOS Iono Grid Points. This estimation
is then compared against the value given by the PS and its error bound. If the CS GIVD
estimation deviates significantly from the PS GIVD estimation and its error bound limit, a “don’t
use” will be raised.

Any test failure leads to an appropriate satellite- or ionospheric grid point-specific alarm (“don’t
use” flag) that is forwarded to the Processing Set and the Check Before subset. A raised “don’t
use” flag does not lead immediately to a CPF switch over because any such alarm could be part
of normal operation. The philosophy is to send the flags to the PS, which has to incorporate
them. The Check Before will then check whether the PS correctly incorporated these flags in
their new up- link message.

Check Before
Due to the limited time allowed for the Check Before, the tests performed here are only rough
statistical tests with no fault isolation capability. So, the CPF is designed in a way that
misleading information may be sent to the user at low probability. It is the task of the Check
After subset to detect any misleading information that has passed the Check Before tests.
The Check Before tests include a position domain test (user like) as well as a simple combined
(satellite and ionospheric) correction pseudorange test. In addition the correct incorporation of
“don’t use” flags as identified by the Check After is checked. The design of the Check Before
subset (operational lane) is depicted in figure 4.

The position domain test works in a user- like way. The measurement data of each RIMS are
corrected by the active EGNOS messages including the new message that is to be up- linked to
the GEO. Then a position solution is computed for each RIMS, using the full set of visible
satellites at the RIMS. The resulting position error is compared against the protection level as
EGNOS Central Processing Facility – Architecture and Design Page 11 of 17

obtained by the user formula. If the protection level does not bound the true position error, an
immediate alarm is raised.

Check Before (Operational NOF Lane)

RIMS Positions
RIMS Antenna
Coordinates To NLES

From Raw S/V Positions Apply NOF (ALL Corrected S/V Positions Estimate RIMS
Preprocessing Tropo free PR's corrections) Fully Corrected PR's Clock Biases

CS Integrity
Clock Biases Flag

NOF SIS Compute PR

All Corrections Residuals (Post
Adjustment)
From Message Check & Decode
Operational NOF
Dec. & Route NOF
PR Residuals
Last 4
Broadcast NOF's
Check = GO / NO GO
Combined UDRE/
GIVE Check Self Status
Decoded NOF Store
Operational
NOF

Self Status
GIVE's AIV Check in
Position Domain
Check = GO / NO GO
UDRE's
Check
Not Monitored /
From Check After Incorporation of Check = GO / NO GO
Don't Use Flags
Flags

Check Before

Figure 4 – CPF Check Before Functional Overview

The combined pseudorange test computes error bounds for each pseudorange based on UDRE
and GIVE values and checks these against the true pseudorange residuals after the corrections
have been applied. Any pseudorange residual exceeding the error bound will cause an alarm.
Due to the high number of tests involved, this combined test can only be a relaxed test, to keep
the probability of false alarm low.

Any alarm raised by the Check Before (“no go” flag set to true) will cause the NLES to switch to
another CPF. Therefore, the decision thresholds in the tests will have direct effect on the CPF
(and therefore also system) continuity. This is the main reason why the Check Before tests are
relaxed when compared to the Check After tests.
EGNOS Central Processing Facility – Architecture and Design Page 12 of 17

CPF Development – Challenging Issues

The CPF must meet hard real time constraints. This is driven by the overall time to alert
requirements placed on the EGNOS system and the need to deliver information to the EGNOS
user which is updated every epoch. The majority of the 6 seconds time to alert requirement is
absorbed by transmission of data over networks, the space link or RIMS computation.

The CPF development constitutes a large real time software development. The CPF and the
EGNOS system must be certifiable for the safe use of the signal in space by the European user
community. The development of software in the EGNOS project follows standards that are
largely derived from DO-178B guidelines. Following these guidelines, the CPF consists of
software to be developed at DO-178B Levels B and C. Certification of the CPF as part of the
EGNOS system represents a significant challenge. In order to demonstrate the adequacy of the
CPF design, highly complex reliability and safety analysis has to be performed.

Accurate performances are reasonably expected from the CPF algorithms for orbit, clock and
ionospheric corrections. The analysis of Integrity versus Continuity apportionment (and therefore
also availability) will remain a critical issue for the CPF. This will require careful and
sophisticated algorithm experimentation and tuning. A specific approach is defined to determine
requirements at CPF level with respect to Integrity and Continuity apportionment. This approach
is summarised as
• apportion at CPF level qualitative and quantitative requirements which can be analysed in
detail by the CPF development team (a “top-down” process),
• obtain from the CPF sub-system, qualitative and quantitative results based on these
requirements which can be consolidated in a ”bottom- up” approach.
The qualitative approach is based on a top down approach (fault trees). The top level event is
decomposed into lower level events taking into account the functionality and the architecture at
each system level, until the sub-system output feared events are identified. Then Continuity and
Integrity risk values are apportioned to the basic events of the trees using the minimal cut sets
obtained by analysis of the fault trees. This apportionment is first performed based on the
engineering feedback from the sub-systems, then consolidated at system level, using results from
all the considered apportionment trees. It is finally consolidated at sub-system level using
EGNOS Central Processing Facility – Architecture and Design Page 13 of 17

information from sub-contractors, which identifies for input feared events their transfer function
and applicability range.

One of the most demanding aspects of EGNOS performance is the provision of Integrity during
periods of high ionospheric activity. The approach taken by the EGNOS project has been to
identify and agree upon an ionospheric model to provide a realistic representation of the
ionosphere. This model is to be integrated in the EGNOS End to End Simulator (EETES ) as part
of system level experimentation and optimisation during EGNOS algorithm development. In
order to validate both the performance and integrity of the CPF ionospheric algorithms, a set of
recorded periods of high ionospheric activity have been identified and selected to provide a
demanding test for the developed algorithms of both EGNOS performance and provision of
integrity.
CPF Development plan
The CPF is currently in the detailed design phase. It’s first major milestone, the Preliminary
Design Review was held in March 2000. The development logic mostly consists of two serial
paths, algorithm design and development of operational software which is closely followed by
recurring production and warranty.

The algorithm development is composed of three incremental/evolutionary cycles. These cycles

include both algorithm design and prototyping activities. The first phase will deliver basic
functionality with an expected lower level of algorithmic performance. The second phase will
provide complete functionality and the final phase of development will deliver fully optimised
algorithmic performance.

Due to the criticality of algorithm development, a large effort is detailed to algorithm prototyping
and validation activities. A complex experimentation plan is also being carried out as the basis
for improving design and consolidating the performance budget. In order to support that
development and experimentation, the EETES has been developed so that is able to feed
algorithms with highly realistic simulated measurements and to process navigation solutions at
user level using the messages computed by the CPF. Real data gathered from the EGNOS
System Test Bed (ESTB) is also to be used.
EGNOS Central Processing Facility – Architecture and Design Page 14 of 17

Figure 5 - CPF Experimentation Results : UDRE vs errors

Some experimentation results based on the mentioned environment for the UDRE computation
algorithm are presented in figure 5 where the evolution of the UDRE (at 1-10-7 level) for one
particular satellite is plotted together with the real errors being bounded. Note that performance
objectives for UDRE values at the mentioned level are about 3.5 metres.

ESTB: User Vertical Performance (Rotterdam)

50

40
Vertical Protection Level (m)

58.2%

30
0.0%

20

0.0%
10
41.8% 0.0%

0
0 10 20 30 40 50
Vertical Error (m)

Figure 6 - ESTB Results : VPL Vs Vertical errors

EGNOS Central Processing Facility – Architecture and Design Page 15 of 17

A second major tool for supporting CPF experimentation is the EGNOS System Test Bed
(ESTB), a real time prototype of EGNOS that generate a MOPS compatible EGNOS SIS. Today
ESTB is operational and a SIS is being broadcast through Inmarsat AOR-E. While algorithms
implemented in the ESTB are only initial versions that have been largely improved in the frame
of the CPF Processing Set development, the current ESTB performance provides a strong
confidence in the adequacy of those algorithms for EGNOS. Very promising results have been
achieved, especially considering the reduced number of available RIMS that strongly constrains
ionospheric observations during the analyzed period of time with a very high solar activity.
Figure 6 shows the result for a real user in Rotterdam where an NPV-II availability of about 42%
is reached.

After successful completion of the algorithm development phases, operational software

development will start. The Final Qualification Review of the CPF is planned for the second half
of 2002.

CPF Development Industrial Consortium

The EGNOS development uses a large industrial consortium headed by Alcatel Space Industries.
For the CPF development, Dornier SatellitenSysteme GmbH (DSS) are the Prime contractor.
DSS operate from the Daimler Chrysler Aerospace facilities in Friedrichshafen, South Germany.

GMV (Spain) are responsible for the Processing Set including all integration and validation
activities. GMV will supply all algorithms except the Ionospheric and Clock Corrections
algorithms which are under the responsibility of Racal Research Limited (UK). SENER (Spain)
will develop the Real Time Monitoring and Control (RTMC) SW for the Processing Set and will
also be responsible for the Processing Set HW and SW procurement.

DSS, in addition to being the prime contractor for the CPF, are responsible for the design and
delivery of the Check Set. IfEN (Germany) will provide the design definition and validatio n of
the Integrity Algorithms for the Check Set. Logica (UK) will provide the RTMC SW for the
Check Set and will also be responsible for the HW and SW procurement of the Check Set.
EGNOS Central Processing Facility – Architecture and Design Page 16 of 17

Biographies
Jon Westbrook is a systems engineer at the European Space Age ncy where he is part of the
GNSS-1 Project team created for the delivery of the European Geostationary Navigation Overlay
Service (EGNOS). He is currently seconded to the European Space Agency from the UK
National Air Traffic Services Ltd. He was educated at the Univerity of East Anglia in the United
Kingdom receiving his BSc. Honours degree in Electronics and Business Studies in 1995.

Dr. Javier Ventura-Traveset holds a MS in Telecom. Engineering from the Polytechnic Univ.
of Catalonia (Barcelona, Spain, 1988); a M.S.E in Signal Processing by Princeton University
(Princeton, NJ) in 1992; and a PhD in Electrical Engineering by the Polytechnic of Turin (Italy)
in 1996. Since March 1989, he is working at the European Space Agency (ESA) involved in
mobile, fix, earth observation and satellite navigation programs; he is currently Principal System
Engineer of the EGNOS Project. Dr. Ventura-Traveset holds 4 patents and has co-authored over
100 technical papers. He is a member of the IEEE and the Institute of Navigation.

Antoine Rérolle is a graduate engineer from Ecole Polytechnique and Ecole Nationale des
Télécommunications of Paris. He has been involved in satellite navigation projects over the past
ten years, since the CE-GPS experimentation for CNES, and then the Euridis project. He is now
a systems engineer at Alcatel Space Industries on the EGNOS programme in charge of the
development of the Central Processing Facility.

Joaquín Cosmen graduated with a Bsc. in Aeronautical Engineering from the Universidad
Politécnica de Madrid in 1985. He joined GMV in 1986 where he participated in a broad number
of space projects covering very different fields as manned missions, rendezvous, Earth
observation, etc. In 1995 he started his involvement in EGNOS as project manager. In 1996 he
was nominated as the head of the GNSS Division in GMV.

Dr.-Ing. Helmut Blomenhofer is Project Manager EGNOS at Astrium GmbH (formally Dornier
Satellitensysteme GmbH). After finishing University Studies in 1989 he worked at the German
Geodetic Research Institute (DGFI) on PRARE (Precise Range and Range Rate Equipment).
From 1990 to 1995 he was Research Associate at the Institute of Geodesy and Navigation (IfEN)
of the University FAF Munich and did research and software development on high-precision
kinematic DGPS. From March 1995 to December 1997 he worked as a systems engineer at
Daimler-Benz Aerospace AG (Dasa); NFS Navigations- und Flugführungs-Systeme on an
Integrated Navigation and Landing System (INLS) for precision approaches and automatic
landings. Since January 1998 he is the EGNOS Project Manager at DSS.

Mr. McAnany is currently with Astrium GmbH in Germany and is the Lead Systems Engineer
for the EGNOS CPF Subsystem development team. Previously he was responsible for the
Systems Engineering activities in the development and type approval of the SCAT-1 LADGPS
Ground Station (a precursor to LAAS) produced by DASA-NFS (a subsiduary of Daimler-
Chrysler Aerospace). He gained his BSc in Electrical and Electronic Engineering in 1984 and his
MSc in Digital Systems Engineering in 1993.
EGNOS Central Processing Facility – Architecture and Design Page 17 of 17

Dr. Wolfgang Werner received a diploma in computer science from the University of
Technology in Munich in 1994. Subsequently he has been Research Associate at the Institute of
Geodesy and Navigation of the University FAF Munich. He received his Ph.D. in the field of
high-precision DGPS/DGLONASS, carrier-phase ambiguity resolution and pseudolite
investigations. Since 1999 he is Technical Director at IfEN GmbH, a technology transfer
company of the same institute.