ADVANCED GNSS-BASED LOCALISATION SYSTEM FOR RAILWAY APPLICATIONS José M. Fraile Socratec GmbH Maxhuetter Str. 16; 93158 Teublitz; Germany Tel: (49) 9471 3100 200 - Fax (49) 9471 3100 209 - e-mail:
[email protected]
SUMMARY For several years now a number of companies have been developing and testing train localisation systems which include GNSS as a positioning element. The utilisation areas of GNSSbased train locators range from their inclusion in Automatic Train Protection/Control Systems –ATP/ATC– to a simple provision of actual fleet position data to dispatchers or travellers. This paper describes a novel GNSS-based train localisation system currently under development in Socratec. This system, code-named SATURN, aims at the widest possible range of railway applications. Map information of the tracks is a key element in SATURN. The role played by the different types of available track cartographic material will be discussed too.
INTRODUCTION GNSS technology has been already used successfully for the provision of actual train location information to fleet dispatchers and travellers (see e.g. [6]). In this type of applications, a GPS receiver has been typically connected to a communication device which reported the actual location of the train to a central control station. In most of these application examples, standard GPS position accuracy was sufficient (sometimes DGPS was employed), no special requirements on integrity/availability were applicable and the link between the GPS position reports and the rail network data was done in the control station. On the other extreme, the use of GNSS sensors in the context of the future European automatic train control system (ETCS) has been proposed ([9], [4]). ETCS infrastructure is currently being deployed experimentally on some tracks. The envisaged standard train localisation system for ETCS is based on two key components: an odometer and a beacon reader ([1]), both interfacing with a central computer –sometimes called “European Vital Computer”. GNSS sensors have the potential to become part of a complete ETCS complementing the other sensors, or even eliminating the need for the odometer ([4]). However, since the new ETCS infrastructure is expensive to install, its deployment will most probably remain reduced to main rail corridors. GNSS-based train localisation systems could fill in the vacuum left between the ambitious ETCS and the low-level train localisation applications. Socratec’s SATURN (Satellite-based Autonomous Train Localisation System) is a GNSS-based positioning system for railway vehicles currently under development. SATURN aims at the
1
widest possible range of railway applications but with special emphasis in providing regional railway operators with an alternative to other costlier train localisation systems. GSM-R
EVC GNSS receiver
Odometer
Beacon
Fig. 1: GNSS in the ETCS context
GNSS AND AUTOMATIC TRAIN CONTROL: THE KEY REQUIREMENTS Navigation performance has been widely measured in relation to the following set of technical factors: • • • •
signal accuracy signal integrity signal continuity and system availability
The extensive analyses performed in the framework of the EGNOS/WAAS and Galileo programmes have made these factors rather well known. Those analyses however were influenced strongly by the civil aviation environment. In the civil aviation case the emphasis lies in the performance of the signal-in-space, probably assuming that users will have nearly unobstructed view of the sky. For the railway case, the situation complicates. The typical user has frequent and severe obstructions which limit the reception of satellite signals (not only due to tunnels but mainly to buildings and other natural obstacles). Unlike for the typical land mobile application facing similar conditions –car navigation–, reliability is of key importance because safety-of-life is a real concern. In this framework, acceptable levels of performance in usual terms of –specially– signal-inspace integrity and system availability are of little use for the railway user. He is rather confronted with the problem resulting from the non-guaranteed reception of the signals (specially if integrity information is available only on some of the signals as it is the case in EGNOS/WAAS). The criticality of this factor is clearly shown by the results of the wide and local area train localisation experiments described in [3]. The availability of differential positioning was only 63% and 79%, respectively.
2
On the accuracy side, typical requirements mentioned in literature for train control applications are: 2 metres, 95% of the time ([7]). Even the definition of such a requirement needs a careful look at the application in question. For instance, in the case that the GNSS sensor is to be used for automatic train control, there could be some exceptional situations where higher accuracy may be necessary. One example for this are the so called “stop points” at switches. Stop points are marks located at switches. They define the position which a train waiting for free way on the parallel track may not cross if a crash with the train “incoming on-the-other track” is to be avoided. These stop points are placed in such a way, that they may, by no means, be crossed by the waiting train. Even small crossovers of only decimetres can cause a crash.
Fig. 2: Stop-point at a switch The definition of requirements on the performance of a GNSS-based localisation system for the railway environment need therefore to have a clear link to the use’s environment and the application. It seems therefore, that “one-size-fits-all” approaches are not totally suitable for the railway environment. Is GPS suitable today? As of today, GPS is the only satellite-based localisation system available for the localisation of trains under operational conditions. The well known limitations of GPS for civil users in terms of low accuracy and lacking integrity have played till now an important role is the scarce use of GPS for the control of railway traffic. On the accuracy side, the elimination of Selective Availability ([5]) might help boost GPS’s attractiveness in non safety-of-life applications. In order to improve GPS’ performance, EGNOS/WAAS will offer regional complementary services which could be suitable for the railways. However, the already mentioned limited visibility of the GEO satellites –which transmit the differential and integrity data– for a railway user make EGNOS/WAAS as such of little help. The perspectives opened by the possible combination of EGNOS with Loran-C/Eurofix as additional data link represent a possible technical solution to overcome most of the limitations that affect GNSS-1 railway applications ([2]).
3
More in the future, Galileo with its highly accurate Three-Carrier Ambiguity Resolution ([8]), could enable nearly instantaneous cm-level relative positioning accuracy. However, this still needs more extensive assessment in the praxis once the new system is deployed.
TRACK NETWORK DATA Like in the car navigation case, GNSS-based train localisation can greatly benefit from the availability of cartographic information. If available in a suitable format, track network data can make processing algorithms based on „map-matching“ techniques possible. Socratec has worked to date with two types of track network data: •
the simpler type is basically a database of the network which includes data on the topology of the network (qualitative information only) combined with geographic information at discrete points, normally evenly spaced (e.g. every 100 metres). This type will be called “discrete”. • the second type is based on vector maps such as those employed in car navigation systems. Each of these types has advantages and disadvantages. In any case, realising about the consequences of the selection of one type of data or the other is very important. A A&B
A
A&B
A
A
A
B
A&B A&B
A
B B
A&B Discrete points with geographic and topology information
Fig. 3: Track network data with discrete geographic information and topology Discrete databases are ideal for transforming GNSS-based positions into railway position information (defined in terms of track identification number and kilometre on that track) with a minimum in complexity and amount of necessary data. However, due to the exclusive availability of geographic information at discrete points, they do not allow to use any type of “mapmatching” processing algorithms. Furthermore, the identification of the track on which the train after passing on a switch can result ambiguous if the positioning sensor does not provide the suitable accuracy. This type of databases can be very effectively employed in train localisation systems destined to the provision of network-wide actual fleet location information. Fleet operators in charge of dispatching and travellers can benefit from such information. Vector databases are more complex because they contain much more detailed information about the tracks network. In order to enable the positioning system to use „map-matching“ algorithms, they include not only the topology but also the exact course of the tracks, with the needed geometric information to reconstruct the tracks (curvature of curves, start and end points of straight sectors, etc.). As previously mentioned, track network data in vector format can be effectively used for the implementation of „map-matching“ algorithms as widely done in car navigation systems.
4
However, a number of important issues support an increase of efficiency in the railway environment. For instance, trains can only change tracks at predefined points –switches– which are accordingly attributed in the databases. Furthermore, trains can only head in the same direction as the tracks allow. The implementation of these and other constraints in the “map-matching” module of the train locator can increase the reliability and accuracy of the system, or alternatively, can help relax the accuracy requirements on the GNSS system as a whole. One of the most important disadvantages of vector databases is their scarce availability. Discrete databases are certainly not much more abundant but at least they are easier to generate with quick survey methods (which can e.g. consist of a train collecting GNSS data while operating normally on the selected tracks). Vector databases on the contrary are real cartographic maps and require more effort.
SOCRATEC’S TRAIN LOCALISATION SYSTEMS Two GNSS-based train localisation systems are currently under development in Socratec. SATURN is foreseen for demanding applications and employs vector track network databases. The second version, SATURNlight, uses databases of discrete type and is foreseen for the provision of network-wide fleet position information. The hardware platforms of both versions are common to a large extent and are based on industrial PC components which guarantees robustness in the hard railway environment and long availability of parts. All selected components are characterised by Mean Time Before Failure (MTBF) of more than 200000 hours. The use of mechanical fans was eliminated with the selection of Pentium CPU-boards with passive cooling. Finally, large capacity solid state data storage technology was used which is highly resistant against shocks and vibrations and operable within a wide range of temperatures (DiskOnChip). The localisation sensors are a 12 channels GPS receiver and an inertial module with two vibration gyros (pitch and yaw) and one accelerometer. The software runs under the real-time, multitasking operating system QNX. Both versions process the collected GNSS/inertial data in real-time combining those data with the track network databases; each system with the accordingly suitable algorithms. Both versions are ready to use GNSS differential corrections and pulses from a wheel sensor if available. SATURNlight In this system the combination of the GNSS position information provided by the localisation sensors with the track network data follows a purely logical approach. This approach can be briefly described as follows:
5
With the position information provided by the sensors the most probable track is initially selected and the position on that track computed. PCMCIA Storage Card
CAN-BUS
SATURN Light Solid-State Disc CAN-BUS
PCMCIA
Interface Card
Slot Card
Card (72MB to 288MB)
+5V +12V
PC/104-Bus
GPS Satellite Si gnals
GPS Receiver
COM
CPU
DGPS Corrections (optional)
COM
COM COM
Card
LP T 1
COM
COM
COM
COM
Inertial Platform
Switch Control
Localisation Card
Service
Doors Signal
Radar
Odometer
Fig. 4: Block diagram of SATURNlight Rail Network Search 1
User Interface Module
Rail Network Search 2
SLM Module
Administration of
Service Interface Module
Search Processes St at us M
Main Positioning
es sa ge s
Process
Rail Network
Positioning Module
Inertial Platform Control Module
Inertial Platform
DC/DC Converter
-12V
+5V
+12V
-12V
Sensors Module
GPS Control Module
GPS Receiver
Other Sensors
Fig. 5: Processes in SATURNlight
6
110V
From that point onwards, the selection of the best track candidate is done making a logical analysis of the position output from the sensors and the topology of the network (i.e. noticing which track was previously selected and which can follow it according to the topology. The same with the next best candidates). This type of processing has been code-named “SATURN logical method” (SLM) which is the core of the software module which transform GNSS-derived geographic data in railway position information. The organisation and flow of the different tasks which make the real-time data processing software package is shown in the figure below. SATURN The localisation algorithms in SATURN are aimed for more demanding applications where reliable track identification and position information is of key importance. This train locator makes use of vector track network databases in order to achieve the maximum performance. Before initiating SATURN’s development, we analysed the movement of trains on rails very carefully and draw conclusions on, firstly, how to exploit the constrained conditions in an optimum way, and secondly, how to combine it optimally with GNSS technology. The results of our analyses are being implemented in SATURN. In summary, the train localisation problem is divided in three parts which can independently from each other be resolved. The combined resolution of them all is the key factor for successfully using GNSS in the railway environment: 1. identification of the track on which the train rolls 2. detection of any change of track after a switch 3. determination of the train position on the track Socratec’s SATURN system, is inspired to a large extent by the advances achieved in modern car navigation systems, while maintaining high levels of reliability and robustness. Thanks to the available vector track data, the localisation module of SATURN can employ more complex algorithms than the light version does. Of course, the logical analysis (SLM) is still kept in this case, but its output is regarded here only as an indicative information about possible candidates. The final selection of the track where the train rolls on is done by means of a single navigation filter which combines the outputs from the localisation sensors with the network data. In this case, the combination with the vector network data is not done as a follow-on step after the GNSS-based localisation (with or less sensors), but it is integral part of the navigation filter. Basically, the vector track network data provides the boundary conditions which the train position needs to fulfil to be a possible candidate. A follow-on analysis of the residuals resulting from the navigation filter adjustment, together with a correlation analysis of the different available data (e.g. heading provided by the sensors and possible headings according to the
7
track data) completes the selection of the most suitable track and the identification of possible changes of track after rolling over a switch. Once the correct track has been selected, the computation of the position of the train within that track is directly based on the output of the combined navigation filter mentioned above corresponding to the track selected. The development and assessment of these localisation algorithms is being the subject of a project partially funded by the German Aerospace Center (DLR).
FIELD TRIALS SATURNlight A prototype unit of SATURNlight developed for the German Railways (DB AG/FTZ) was delivered in the first quarter of 2000. In April 2000, extensive field tests took place around the Munich area. Data was collected at 1Hz for a total of two days.
Fig. 6: SATURNlight Prototype The results of the field tests are currently being evaluated in order to assess the performance of the system. Preliminary results indicate however that approx. 85% of the time the correct track was identified unambiguously, while the rest 15% of the time the correct track was one among three ambiguous candidates but could not be unambiguously identified. Socratec is working on the potential improvement of the SLM processing module in order to reduce the number of ambiguous track determinations. However, a total elimination will not be possible due to the discrete network database employed. Detailed results of the field campaign will probably be made public as soon as the final results of the assessment are available. SATURN As previously mentioned, the development and software implementation of the special localisation algorithms employed in SATURN has not been completed yet. As soon as they has been completed (expected for end 2000), extensive field trials will take place with a functional model of the system under operational conditions. For this purpose a railway operator will be selected as project partner.
8
SUMMARY In this paper we analysed the requirements which are typically used to characterise the performance of a navigation system and discussed why they have to be handed very carefully when using them in the railway environment. Socratec’s train localisation systems were presented and their functionality described. The two main types of available track network data were introduced and their advantages and disadvantages assessed. Finally, a qualitative analysis of the different possible on-board data processing methods in relation to the type of track network data employed was presented.
ACKNOWLEDGEMENT The work described in this paper has been partly supported by the German Aerospace Center DLR, Bonn (FKZ:50NA9921).
REFERENCES [1]
[2] [3]
[4]
[5] [6] [7] [8]
[9]
Alonso Andino, C. and J.-M. Ribes y Ardanuy: Sistema ERTMS. Proceedings of Ferroviaria’98, Congreso Nacional de Ingeniería Ferroviaria, A Coruña, Spain, June 3-5; 1998. DGON e.V. (Ed.): Symposium Proceedings. International Symposium on Integration of LORAN-C/Eurofix and EGNOS/Galileo, Bonn (Germany), March 22-23; 2000. Gu, X.; M. Schmidt and J. Winter: GNSS-based Train Positioning Experiments with Local and Wide Area Augmentation. Proceedings of the 1st European Symposium on Transport Telematics, ETT’99, Potsdam (Germany), Nov. 8-12; 1999. IfRA-IFF/TUBS: RailOrt – Ortung in spurgebundenen Verkehr auf der Basis von Satelliten-Navigation. Report to project FKZ19R9503 “RailOrt”, Institut für Regelungs- und Automatisierungstechnik, Technische Univ. Braunschweig, Version: 1.02, January 29; 1999. Nordwall, B.D.: Degrading GPS Signal May End. Aviation Week and Space Technology, Vol. 152, No. 16, pp. 44; April 17; 2000. Roca, J. and J.L. Pérez: All Aboard! On Track with Catalonia’s Trains. GPS World, June; 1997. US Departments of Transportation and of Defense: 1996 Federal Radionavigation Plan. Report Number DOD-4650.5/DOT-VNTSC-RSPA-97-2, July; 1997. Vollath, U.; S. Birnbach; H. Landau; J.M. Fraile and M. Martín-Neira: Analysis of Three-Carrier Ambiguity resolution Technique for Precise Relative Positioning in GNSS2. NAVIGATION, The Journal of the Institute of Navigation, Vol. 46, No. 1; Spring; 1999. Winter, J.: GNSS1-based Train Positioning Platform. Presented at Eurailspeed’98, Berlin, October; 1998.
9
