GNSS on track

This software is a key element for studying the overall sensors system before the ontrain test campaign and also defines 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.

Figure 1: GESS high-level scheme

The system includes two GNSS receivers, one on train’s head and the other on tail, an Inertial Measurement Unit (IMU), and an odometer. All measurements provided by the sensors are sent to the GRAIL User Terminal (UT) that elaborates them: it generates and then transmits through a standard PROFIBUS (Process Field Bus) interface the messages for the on-board ETCS (European Train Control System). The GRAIL-UT is an integrated Navigation/Communication user terminal demonstrator developed by Thales Alenia Space in the frame of GRAIL program. The communication between the User Terminal and the train cabin, through the CTODL (Current Time Odometric Data Line) and PROFIBUS lines, is also simulated.

Potential application of GNSS technology as an enhanced ETCS/ERTMS (European Train Control System/European Railway Traffic Management System) applications provider has been studied in the project, analysing the results of laboratory and on-site tests. In this context, the GESS has been a key element for testing the User Terminal (UT), developed for demonstration activities, and studying the overall sensors system before the on-train test campaign.

The software runs on a standard PC with a real-time operative system and has the same interfaces of the real sensors. Its development has been divided into three main activities concerning the definition and implementation of the Simulink model, the communication protocol, and the real time algorithms. Using the autocoding tool provided by Real–Time Workshop, the Simulink model has been completely coded in C and integrated in the RTAI (Real-Time Application Interface) operative system for Linux, following specific project requirements.

The software is available in several configurations depending on the foreseen laboratory tests. The first one is the complete configuration, in which all the components of the reference scheme are simulated; partial configurations are also possible, removing some simulated modules and substituting them by hardware elements. A control shell provides communication between the autocoded Simulink models and I/O interface. All configurations have been verified and validated in the CEDEX (Centro de Estudios y Experimentación de Obras Públicas) certified laboratory. The main components of the GESS reference scheme are (Figure 1): the trajectory and attitude simulator; the UT sensors, including two GNSS receivers and an IMU (Inertial Measurement Unit); the CTODL and PROFIBUS lines between the UT and train cab.

Simulink model

The environment and sensors Simulink model is composed by two main blocks, namely, the “train” and the “sensor system”. The train functions compute the train trajectory and attitude, which are used as inputs by the sensor system functions. These provide the UT with the estimation of position and velocity, and measurements of linear acceleration and attitude rate. The“train” module is composed by two elements: the head and tail cabins, where all sensors are located.

The mechanics of each cabin is described using the “rigid body” model. The trajectory and attitude are characterized by six variables, three linear coordinates for the position of the reference point (position on the cabin where the sensor system elements are located) and three angles for the orientation of the body frame with respect to the North-East- Down (NED) reference system.

The configuration of a train track can be done either by the geodetic latitude, longitude and height (WGS-84 Ellipsoid) or by the UTM (Universal Transverse Mercator) coordinates of real balises. Track geometry is defined by balises and control points. For each travelled distance the track position is obtained through linear interpolation of the balises coordinates. For a given configuration, the input for the simulator is the along-track dynamic profile (acceleration, velocity and position) (Figure 2), which can be generated internally by GESS or taken as input in real time (CEDEX configuration).

For each simulation step, the trajectory simulator computes the ECI (Earth Centred Inertial) components of position, velocity, and acceleration vectors. These are obtained applying the transformation from ECEF (Earth Centred Earth Fixed) to ECI corresponding to the configured date and time. ECEF components of position, velocity, and acceleration are computed as function of geocentric coordinates and their derivatives.

The attitude simulator computes the rotation and the angular rate of the body frame with respect to NED. The first axis of body frame is aligned with the along track velocity, the third one with the local vertical pointing toward the Earth centre and the second

Figure 2: Along-track train dynamics

Figure 3: Rotation angles

completes a right-handed orthogonal system. The rotation around (α) is assumed to be always null, while the rotation around (β) and (γ) are computed in terms of the derivatives of geodetic coordinates with respect to the along track position (Figure 3).

Sensor system.

The “sensor system” module is composed by four elements: the GNSS receiver (RX1), the IMU and the Odometer on head cabin and the GNSS receiver (RX2) on tail cabin. The train cab (Eurocab), located on the head, provides the UT with the odometric measurements through the CTODL line. In the scope of the project this line has been simulated only for testing synchronization between the Eurocab and UT.

Position and velocity estimations are obtained filtering the raw data generated by the GNSS receiver. In addition to the navigation solution, the receiver health and status message, the clock offset, and drift and the GNSS system time are provided.

The GNSS receiver model has been built to be fully configurable: it can be used for generic GNSS multisystem simulation. In the GRAIL project, GPS, EGNOS, and Galileo were taking into account; Space, Ground and User segments are modelled for constellation simulation, navigation message evaluation, and raw data generation. The high-level GNSS receiver (RX1) Simulink model is sketched in Figure 4.

Figure 4: GNSS Receive Simulink Model

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.