GNSS on track

Raw data, comprising pseudorange, carrier phase and Doppler, are evaluated computing the geometrical range, the range errors, and the range correction for each allocated satellite.

Figure 5 : IMU Simulink Model

The principal error sources are taken into account: OD&TS (Orbit Determination & Time Synchronization) estimation error is simulated, including hardware biases; ionospheric and tropospheric delays are generated with the NeQuick and the MSIS models respectively, performing the integration of the atmosphere refractivity; multipath code and phase errors, induced by local user environment, are calculated considering configurable Gauss- Markov processes, both autocorrelation time and steady-state standard deviation can be set to simulate higher or lower multipath conditions; receiver tracking errors are computed considering the thermal noise and the dynamic stress due to relative receiversatellite acceleration.

The receiver health and status is defined by the receiver operative mode, health, integrity status, and DOP (Diluition Of Precision). In the frame of the project, nominal conditions have been assumed: navigation solution is running with no malfunctioning.

The measurements of reference point linear acceleration and body frame angular rate are obtained directly from the accelerometer and gyroscope of the IMU (see Figure 5), which adds a configurable noise to the effective acceleration and angular rate.

Figure 6 : CEDEX Experimentation scheme

Communication protocol

The User Terminal communicates with the two GNSS receivers (RX1 and RX2), with the IMU, and with the EUROCAB, for message exchange and to obtain the synchronisation data.

Since the goal of the system is to provide sensors simulation to execute performance tests before the final integration with real hardware, the interface of the GESS must be the same than that of the different equipments, to be transparent to the UT.

Communication with both GNSS receivers is carried out over a standard RS-232 serial line, using a proprietary frame protocol to transmit the receiver status and navigation solution (GNSS time, position, velocity). This information is sent periodically to the UT.

The IMU is connected to another RS- 232 serial line, operated in polled mode. The UT sends a packet requesting a new measurement to the IMU, which answers with a fixed length packet containing the measured three-axis angular rate and acceleration.

Two are the interfaces of the simulated EUROCAB with the UT. The first one is the CTODL line, used to synchronise the system with the EUROCAB, and the other one is the communication link.

The CTODL line uses a RS422 serial link. The messages have a fixed length of 20 bytes, sent each 50 ms. These packets carry information of the odometer present in the EUROCAB (travelled distance, and speed) and the time at which the packet was sent, with an increasing number to help the packet identification. The whole message is error-protected by a Cyclic Redundancy Code.

The bidirectional communication link between the UT and the EUROCAB is carried out over a PROFIBUS line, although for some tests it may be substituted by a RS-232. This line supports the different exchanges of information. All the packets have a header with an identification number and the packet length, and a trailer field with a CRC check of the message.

For the Enhanced ETCS/ERTMS Absolute Positioning functionality, the GRAIL-GNSS-UT sends a message to the EUROCAB when it detects that a specific point has been reached, using a digital map of the track. This is equivalent to a “virtual balise”, so the message contains the same information that the one provided when the train passes over a real one, i.e. timestamp and identification.

Real time algorithms

The real-time software is composed of several modules performing different tasks. The main real task is a skeleton running the Simulink model. It executes all engineering models at the correct rate providing to the lower layers the engineering data that should be transmitted by the output interfaces. The communication between the engineering models and the protocol layers has been done using inter-process communication (IPC) capabilities provided by the RTAI real-time operative system.

Communication protocol layers have been divided in independent threads collecting, formatting, and transmitting the engineering data by the needed interface when scheduled by the requirements.

Other modules, completing the simulator facilities, are related with database configuration, parameters configuration, and data monitoring.

Experimentation in CEDE

The GESS simulator has been tested in the CEDEX certified laboratory, which simulates the EUROCAB, PROFIBUS and CTDOL interfaces. As it is shown in the test configuration of Figure 6, GESS provides GNSS receiver measurements and IMU outputs to the User Terminal. The measurements were triggered by the CEDEX laboratory and were synchronised with the other signals. This experimentation campaign, comprising functional and performance tests for interface with the User Terminal and overall synchronization, were carried out in Spring 2008 before the User Terminal on-board test campaign (Figure 7).

Figure 7 : GES in CEDEX laboratory

Conclusions

The GESS real-time software prototyped for analysing the GNSS introduction in rail sector has been presented. This software allows the study of the overall sensors system before the on-train test campaign, defining a generic platform that could be used for the analysis of any other application of a GNSS system. It simulates the trajectory and attitude of train’s head and tail cabins and the measurements generated by the on board sensors: GNSS receivers, IMU and odometer.

The Simulink model, communication protocols, and real-time algorithms have been described.

The simulator has been used for the validation of the integrated Navigation/ Communication user terminal demonstrator developed by Thales Alenia Space in the frame of GRAIL program.