GNSS | |
GNSS on track
|
||||
GESS (GRAIL Environment and Sensor Simulator) is a real-time software prototyped for analysing the GNSS introduction in rail sector. It has been developed by DEIMOS Space in the frame of the GRAIL (GNSS Introduction in the RAIL Sector) contract, lead by Ineco/Tifsa, for the GNSS Supervisory Authority (GSA).
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 modelThe 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 |
||||
Pages: 1 2
Leave your response!