Time Facility for
German Galileo Test Environment
GATE
Content
Overview of GATE
Major Objectives of GATE GATE Field and Service Area
Functions and Elements of GATE Control Segment Functional Architecture of GATE Time Facility
Requirements for GATE Time Facility
Physical Architecture of GATE Time Facility Controlling of GATE Time Facility
Overview of German Galileo Test Environment GATE
What is GATE?
Ranging system using Galileo signals
Based an stationary terrestrial signal transmitters Open to any user
Where is the GATE service area?
Near to Munich (Berchtesgaden) Who is the customer?
German Aerospace Center DLR Status of GATE?
Starting for operation in 3rd quarter 2006 Who develops GATE?
A consortium of 9 companies/universities
Major Objectives of GATE
Signal Experiment
Gain experience in building a Galileo ranging system Gain experience with new Galileo signal structure: flexible (BOC(1,1); extendible (GPS-L2C, L5); adaptable (Interference, Jamming)
Receiver Testing
Test facility for Galileo receivers
Testing of new BOC receiver algorithms
with realistic signal behaviour and strength, atmospheric effects User Application
Provide an environment for test of user applications Especially for hybrid GPS/Galileo applications
GATE – Limitations & Capabilities
GATE vs. „the Real Thing“
Constraints in geometry (DOP / Visibility) Careful choice of service area
Constraints in local signal propagation effects
Multipath: GTS-GMS geometry corresponds to SV-GMS worst case, but multipath due to user motion dominating effect!
Geometry induced effects can be emulated Ionosphere
Troposhere
GATE vs. Laboratory / Simulator
End to end test of receiver, including antenna
Real time dynamics, instead of predefined trajectories User selectable hosting vehicle applicable for application
GATE Field Segment in Berchtesgaden
Location of Transmitter Stations: Grünstein Toter Mann Störhaus Kneifelspitze Kehlsteinhaus Jenner
Location of Monitor Stations: Sulzberg
GATE Service Area in Berchtesgaden
Size: > 25 km² Performance Criteria: Min. 4 visible GTS HDOP < 2 VDOP 6-20 Infrastructure Criteria: Availability of GMS platforms Mountain area for GMSelevation
Typical User Environment Available:
Streets Railways
Functions of the GATE Control Segment
Hosting and providing the GATE system time
Monitoring and controlling of the entire GATE system
Archiving off all necessary data (housekeeping as well as user relevant data)
Hosting and operating a control centre which serves as operational node of GATE including e.g. mission planning
Provide an appropriate interface to the GATE user community
The main elements of the GCS are the GATE Time Facility (GTF)
GATE Monitoring & Control Facility (GMCF) GATE Archiving and Data Server (GADS) GATE Data Transfer Network (GDTN)
The Elements of the GATE Control Segment GCS
Control Segment Mission Segment GPF GTS GPS satellites Galileo IOV satellites GPS / Galileo GUT GMS Transmit Segment GNSS sensor GTF GCC GMCF GADS Operators UTC(DLR) Lab Monitoring system Expert team Master clock with hot-spare NTP server GMSF-SThe Elements of the GATE Control Segment GCS
Control Segment Mission Segment Transmit Segment User Segment GTF GCC GMCF GADS Operators UTC Lab Monitoring system Expert team GPF GTS GPS satellites Galileo IOV satellites Master clock with hot-spare GUT NTP server GMS GMSF-S GNSS sensor GURx GPS / GalileoThe Elements of the GATE Control Segment GCS
GATE Control Segment
GMCF GATE Monitoring & Control Facility GADS GATE Archiving & Data Server GTF GATE Time Facility GMSF-S GATE Mission Support Facility Standard
Located at DLR GSOC Control Centre
Located at DLR TL
Functional Architecture of GATE Time Facility GTF
The functions of GTF are
generation of reference time scale of GATE: GATE System Time GAST provision of access to GAST for other GATE elements
provision of access to UTC
provision of access to GPS Time
GTF takes the time keeping function similar to the Precise Time Facility in Galileo.
Decreasing the project costs, the GTF is hosted by the DLR Time Laboratory (DLR-TL)
The GTF has access to clocks and products (time scales) which are provided by the DLR-TL
GTF – Functional Architecture
The receivers are configured to send the following messages to the GPF: GPS observations
GPS navigation messages referenced to GAST
Additional Parameters through an internal OS service to GPF GAST-UTC offset and rate
UTC-TAI offset
GATE MC-UTC(DLR) offset and rate
Copies of all to GPF transmitted data to GMCF
Receiving and transmitting configuration data for the GTF from and to GMCF
GTF – Functional Architecture
DLR Time Lab Steering
to UTC
Responsibility of DLR Time Lab
Generation of UTC(DLR) Interface to BIPM Responsibility of GTF Element control & interfacing Network synchronzation Interface to GPS Time and GAST provision GPF/GMCF NTP synch M&C data/ GPS obs M&C data GAST BIPM UTC(DLR) correction GAST correction UTC(DLR) GAST UTC-UTC(DLR) GPS SIS Generation of GAST GAST-UTC comparison GATE-specific operations UTC correction
GTF – Requirements
GAST shall be produced at the GTF from a high-performance clock being the
GATE master clock.
The GTF shall have access to UTC.
The offset between GAST and UTC < 100 ns modulo 1s over any 1-year time interval within a 95% confidence level.
The offset between TAI and GAST < 50 ns (96%), assuming the estimation of TAI six weeks in advance.
The frequency instability of GAST expressed in terms of Allan-Deviation relative to TAI shall be better than 1e-13 over 10 000 s.
The frequency instability of GAST expressed in terms of Allan Deviation relative to TAI shall be better than 2e-14 over 1 month.
The life time of the GATE master clock shall be at least 3 years. The MTBF of the GATE master clock shall be no more than 1 failure per 12 500 hours.
The availability of the GTF has to be at least 98.1 percent in order to meet the overall GCS availability requirement.
GTF – Physical Architecture
Detailed Availability of GTF and its elements without redundancy
GTF – Physical Architecture
Total GAST availability without redundancy
Total GAST availability with redundancy
GTF – Physical Architecture
High availability of GTF needs a redundancy of single GTF elements The physical architecture of the GTF is based on COTS hardware. It consists of
2 Dell Windows Server 2003 (XEON 3 GHz, 1 GB RAM, RAID1 36 GB SCSI, 10/100/1000 Mbit Ethernet)
2 GPS time receiver Septentrio PolaRx2.
Meinberg NTP/LAN Server with GPS and 1PPS signal input
GTF will have access to DLR campus LAN to enable data exchange with other GATE elements.
The CPU clocks of the servers will be synchronized to GAST through the NTP protocol using the campus LAN.
GTF – Physical Architecture
DLR Time Lab GPS reception sub-system Equipment of DLR Time Lab GPS RX 1 PC1 GTF NTP server UTC(DLR)/GAST generationsub-system UPS WAN I/F 1Power supply 1 PPS 10 MHz Data GPS signals Networkinterface GPS RX 2 BIPM/IERS Interface sub-system WAN I/F 2 GPF/ GMCF GPF/ GMCF PC2
GTF – Physical Architecture
Clock subsystem Phase microstepper Switch Measuring subsystem Phase microstepperGAST realisation subsystem
GPS Rx GPS Rx
To GATE Control Center
Control PC Control PC
GAST processing
GPS Rx Control PC
UTC(DLR)
To GATE Control Center
Control Center Interface
PTF – Physical Architecture
Clock subsystem Measurement subsystem
GST processing
Precise Timing Facility
Time Service Provider
GST-to-TAI correction GST realization subsystem GPS constellation Galileo constellation GST GPS SIS IF Galileo sensor station GPS/Galileo time offset processing
The GTF at DLR Time Laboratory
UTC(DLR) Time Laboratory