An Augmented GPS/EGNOS Localization System for Alpine Rescue Teams Based on a VHF Communication Infrastructure

Transcription

1 An Augmented GPS/EGNOS Localization System for Alpine Rescue Teams Based on a VHF Communication Infrastructure F. Dominici, A. Defina, and F. Dovis Politecnico di Torino C.so Duca degli Abruzzi 24 Torino, 1129 Italy P. Mulassano and M. Gianola Istituto Superiore Mario Boella Via P. C. Boggio 61 Torino, 1138 Italy Abstract This paper describes the work performed in the design of a network-based positioning system exploiting the advantages of the European Geostationary Navigation Overlay System (EGNOS) tailored to support operation of Alpine Rescue Teams in the management of search and rescue operations. The positioning system is based on the raw pseudorange measurements collected by the users and transmitted to a Local Element over cellular or VHF radio channels. This latter exploits frequencies reserved for rescue teams and ensures good coverage in mountain environments. The results demonstrate that the system fully exploits the improvement given by the EGNOS signals, ensuring a suitable level of accuracy in the positioning for a larger time with respect to standalone GPS positioning. T I. INTRODUCTION HIS paper presents the work performed for the design of an automated localization system targeted to Alpine Rescue Teams. The work has been performed in cooperation with the Corpo Nazionale Soccorso Alpino e Speleologico (CNSAS), the Italian Alpine Rescue Team. Aim of the proposed architecture is to ease the real-time management and coordination of the on-field resources: precise positions of all the team members are calculated at control centre level thanks to the use of the European Geostationary Navigation Overlay Service (EGNOS) augmentation data. As a consequence, this architecture allows the operations coordinator to provide very precise directions to all the rescuers, allowing a sensible reduction of the intervention time, essential for the success of search and rescue operations. The paper is organized as in the following: Section II provides a description of the system architecture, whilst Section III describes the software approach used to develop the system and Section IV investigates more in detail the driver developed for managing the Global Positioning System (GPS) receiver chipset. The application of the EGNOS corrections to the raw data is described in Section V while Section VI summarizes the tests results, pointing out the performance improvement when taking into account the EGNOS augmentation data. Finally Section VII describes the activities that still have to be carried out in order to consolidate the system performance and draw some conclusions. II. SYSTEM ARCHITECTURE AND DESCRIPTION At present, although the high commitment of the CNSAS members and volunteers that allows for successful rescue operation in the largest part of the cases, the management of the operations on the field still presents some weakness due to the fact that it lacks of reliable and automated positioning. This fact leave almost completely the responsibility of monitoring the human resources on the field to the manager of the operations. As depicted in Fig. 1 each rescuer is equipped with a VHF radio transceiver transmitting on a reserved and certified frequency band and in some cases with a GPS receiver. The position, when available, is communicated by voice on the radio channel to the control centre where the operations coordinator manually records on a map the received positions in order to have a complete view of all the Fig. 1. Current operative scenario of CNSAS teams.

2 rescuers. This type of system is easily affected by different types of errors, ranging from the wrong transmission of the rescuer location to the wrong introduction of the points on the cartography. On this basis, CNSAS representatives have identified some fundamental requirements for the development of an automated system providing precise positions in real time. Such requirements, hereafter summarized, have considerably driven the authors in the system development, leading to the definition of an architecture that can be introduced also in many other rescue environments such as fire fighting and civil protection operations: The positioning and the position record systems must be automated; The positioning system must reach a high degree of availability and reliability, especially in mountainous environments; The VHF radios already in use by the Alpine Rescue Teams have to be used as a communication channel (if needed) since they guarantee a good coverage in mountainous regions; The localization system must guarantee a high level of accuracy in positioning; The system infrastructure must be of easy and intuitive utilization; The rescuers user terminals must limit the battery consumption in order to guarantee the service till the end of the operations; The rescuers equipment must be portable and ruggedized since it has to be used in hostile environments; The system realization costs must be as limited as possible. On the basis of these requirements a system architecture for management of the rescue teams operations has been designed as reported in Fig. 2. The network-based positioning system is made up by two fundamental blocks, the User Terminal (UT) and the Local Element (LE), that communicate via GPRS link or VHF radio channel. The UTs are portable devices (Fig. 3) composed by a Personal Digital Assistant (PDA) with a software able to manage a GPS SiRF Star II chipset receiver and a communication unit composed by a VHF radio transceiver, a Terminal Node Control (TNC) and a GPRS modem. The UT receives the GPS navigation messages and sends the raw pseudoranges directly to the LE via the VHF radio channel or the GPRS link. The presence of two different communication channels allows a guaranteed connection between the UT and the LE. GPRS is the preferable link since it is a digital channel and allows a sufficiently large bandwidth for the data transmission; unfortunately in the Italian mountainous regions despite of the good coverage of GSM/GPRS networks, the cellular system availability is quite limited in non-tourist areas. As a consequence the analog VHF radio devices, already used by the Alpine Rescue Teams on its frequencies, are provided with a TNC modem and are also used for the transmission of digital data, anyway leaving priority to the voice communications. At the protocol level the GPRS and VHF radio links use respectively the TCP/IP and AX.25 protocols, whilst an adhoc application protocol has been developed to manage the communication between the UTs and the LE. This higher level protocol is in charge of authenticating users, establishing, managing and closing a connection and transmitting data. The LE (Fig. 4), is supposed to be located in a place with clear view of the sky and availability of the Internet connection; it has a complex software server architecture for managing both VHF and GPRS users. The software has the control of a GPS receiver and a communication unit composed by a VHF radio base station with a TNC modem and an Internet connection. Moreover, the LE manages a Database where all the available measurements and additional information are stored. Fig. 2. Developed architecture for the automated management of CNSAS teams. Fig. 3. User Terminal equipment: the prototype navigation and communication unit, the PDA and the VHF radio transceiver.

3 Fig. 4. Local Element Prototype: VHF radio station, Nav/Com module and PC. The LE has to be equipped with a GPS receiver that is exploited to download the information of the navigation message. With regards to the EGNOS corrections, two solutions are possible: if an EGNOS-enabled GPS receiver is used they are downloaded by the receiver itself or, as an alternative, the LE must have an Internet access (wired or wireless) and download them directly from the ESA SISNeT server. In order to have access to the EGNOS corrections a 56Kbps Internet connection, that can be obtained with a normal telephonic line, is sufficient. Tests and results presented in this paper are based on this second architecture. The LE receives the raw pseudorange measurements from the remote UTs on the TCP/IP network (if transmitted on the GPRS channel) or on the VHF radio link. It is in charge of raw data correction and precise PVT computation; this procedure represents the core of all its activities, as detailed in the following sections. At first the usual correction parameters available in the locally received GPS navigation message are applied (e.g. almanac, ephemeris and clock corrections); then, by means of the Internet connection, the LE accesses the ESA SISNeT server and downloads the EGNOS corrections that are properly applied to the raw measurements in order to reach a higher accuracy. With respect to the use of EGNOS the devised networkbased architecture allows for main advantages: The LE always allows to have valid EGNOS corrections independently from the availability of the EGNOS Signal-in-Space (SIS). The introduction of the EGNOS corrections at LE level allows the rescuers to be equipped with simple massmarket receivers that do not have to receive the EGNOS signal, limiting the system cost. In this way the UTs save battery since they do not have to acquire the EGNOS signal (action that may require a long time) that in mountainous areas can be unavailable (shadowing of trees, on canyons). Since the EGNOS corrections are characterized by a limited time validity, a continuous download of the EGNOS signal-in-space, in order to get the navigation message. Due to this architecture it is possible to put the SiRF chipset in the low power consumption mode (TricklePower Mode), as detailed in [1]. Once rescuers position has been determined the cartographic tool provides its visualization on digital maps by means of the OZI Explorer software, so that the operations coordinator can have a complete view of the on-field resources; at the same time all the useful data are automatically stored in the LE database for further utilization. The choice of the cartographic software has been driven by the CNSAS requirements since this kind of software is already in use for some applications of the CNSAS. On the other hand, the rescuer s position is transmitted back to the UT (on the GPRS or VHF radio link) where it is visualized on the rescuer s PDA together with other useful pieces of information (e.g. direction to the next waypoint, operative directions, etc.). III. SOFTWARE APPROACH The proposed Localization System is mainly based on four fundamental applications presenting the same structure and design even if realized using different languages and platforms. As far as the project here described is concerned, the software has been developed using a modular/multithread approach. As a consequence different areas of interest have been identified, e.g. management of the GPS receiver and Position Velocity and Time (PVT) computation algorithms, and have been developed independently from the other functionalities. Using this approach each module is comprehensible/intelligible, extensible and independent as far as possible of the others. Therefore, each module is portable and can be used simply in different applications. In particular, the multithread approach allows the definition of special modules called drivers which are classes containing an internal thread able to work independently from the other drivers and modules of the application. The UTs run with a C# application developed using the Visual Studio.NET 5 with the new.net Compact Framework 2.. Three further tools have been developed: the first one (called Local Element) is in charge of managing the LE itself in the computation of the assisted precise positioning; the second (Algorithm Developer) is a platform for the algorithms tests and the third is a Parser able to extract the useful information saved on a database. The Local Element and the Algorithm Developer store raw GPS measurements, like pseudoranges and ephemeris or corrections like EGNOS corrections, on a database and the parser tool converts them

4 directly into a MATLAB workspace for post processing or plots. A common and flexible framework based on C++ classes has been created by means of the Borland C++ Builder 6. for developing these applications. This framework supports a wide range of functionalities exploited by Local Element, Algorithm Developer and Parser; the most important are listed hereafter: SiRF Receiver Driver SISNeT Service Driver OZIExplorer Driver VHF AX.25 Server GPRS TCP/IP Server GPS Parameters Database Driver System Reference Conversion Utilities Matrix and Vector Algorithms Errors Correction Models Position Computation Algorithms A. Driver Functionalities IV. GPS RECEIVER DRIVER In order to provide an example of the developed software routines, the driver interfacing the GPS receiver is described, since it represents one of the core elements within the overall architecture. The driver must be able, in fact, to set up the receiver interface with the SiRF binary protocol [1] instead of the standard NMEA protocol. This driver provides high efficiency in the control of all the receiver functionalities and allows the download of raw measurements necessary for precise positioning. The driver also provides the possibility to initialize the receiver with different options and the desired settings. Therefore, it is possible to upload an initial set of ephemeris, select the receiver starting mode, select the set of output messages and the output rates. In addition, it is possible to set the SiRF receiver for using the SBAS and define which satellites have to be tracked. After an initial reset phase the receiver enters the running phase and provides automatically the data with the selected rate. At this point, data can be downloaded and other information can be requested in asynchronous mode. In the running mode the driver is a thread of the main application and implements the abstract state machine shown in Fig. 5. The SiRF Binary Protocol, detailed in [1], is organized in different messages that contain all the receiver measurements in the format shown in Fig. 6. B. Driver Operation The driver may be in one of the following states: Start Sequence Wait Data Reception Message Decode Length Error Checksum Error Polling It continuously reads bytes from the receiver port and stores them in a local buffer called RXBuffer. When the driver is waiting for a new message, it is in the Start Sequence State and searches in the RXBuffer the bytes sequence (xa, xa2), i.e. the markers at the beginning of the sequence. When a start sequence is found the driver leaves the Start Sequence State and jumps into the Data Reception State. The driver stays in this state in order to receive all the bytes of the message until the reception of the end sequence (xb, xb3). When an end sequence is found the driver performs a checksum and a payload length check in order to validate the message payload. If the checks fail the driver jumps into the related error state, otherwise the driver is ready for decoding. In the Message Decode State a binary unscramble is done and the decoded parameters are saved into an internal data structure (SiRFData) on the basis of the SiRF Message ID. After the Message Decode the polling queue is checked and if there are no commands the state machine returns to the initial state and waits for another valid message, otherwise it jumps in the Polling State and sends the requests to the receiver through its communication port and then returns into the Start Sequence Wait State. In addition the driver manages a memory stack containing an image of the last SiRFData that contains a complete set of SiRF parameters for each measurement cycle. At the end of a cycle the contents of the internal data structure is copied into the stack. This stack is a swap area that permits to separate the driver data structure from the external data management. The Fig. 5. State machine describing the SiRF GPS driver. Fig. 6. SiRF Binary Protocol message format.

5 driver users have in every moment the possibility to get the last valid SiRFData or to get a SiRFData on the basis of the GPS Time. Similar structures have been developed for the other drivers in order to design modular and self consistent procedures for the management of the hardware. A. Data V. DATA AND ALGORITHMS Starting point for the development of a correction procedure and positioning algorithm is the GPS navigation message detailed in [2]. The message is received by both the UT and the LE and contains different kinds of data that can be divided in two classes. Some pieces of information are exploited by the receiver in order to compute the raw pseudoranges while others are useful for satellites position computation and for basic corrections of raw GPS receiver measures. As described in Section II the raw pseudoranges together with their time stamp are downloaded by the UTs GPS receiver and then sent to the LE to be processed. At the LE side the GPS receiver downloads the navigation message for each visible satellite, in particular subframes 1, 2, 3 and 4 page 18. These data together with the UTs raw pseudoranges are used for the PVT computation. Subframe 1 contains satellite vehicles (SVs) clock parameters that allow to correct the code phase time received from the SVs with respect to both SVs code phase offset, relativistic effects and to compensate for the effects of the SVs group delay. In subframe 2 and 3 there are the ephemeris parameters which describe the SVs orbits during an interval of two hours. They are used to compute the satellites positions related to the pseudoranges received from the UTs at the time of the measurements. Finally, in the subframe 4 page 18, the ionospheric delay coefficients required in order to compute the ionosphere delay are contained. the atmospheric correction models are based on the SVs elevation at the user s location. After the first step an initial position and a rough estimated bias with respect to the GPS clock are available, hence it is possible to compute the SVs elevation and then the atmospheric corrections for each satellites. In the third step the EGNOS corrections are added, as described in the next paragraph. The correction is based on the well known Klobuchar model for the ionospheric delay and the Hopfield/Black- Heisen model, exploiting the European mean atmospheric values, for the troposphere delay [3]. Together with the atmospheric models the raw measurements are corrected for the SV clock error in each step, taking into account the relativistic effect and the group delay given in the subframe 1 of the navigation message. C. EGNOS Corrections In the third step of the correction procedure the EGNOS corrections downloaded from the ESA server through the SISNeT service are applied. The system architecture selected allows to directly add the EGNOS corrections on the raw pseudoranges downloaded by the UTs and transmitted to the LE. A complete driver able to link the LE to the SISNeT service B. Data Corrections The raw GPS pseudoranges downloaded from the receiver have to be corrected with different parameters and models, [2] [3]. The general way to remove these errors is shown in the Error Correction Diagram in Fig. 7 given in [2]. Therefore, in order to implement the Filter & PVT Computation block, an iterative procedure has been designed in order to correct the input data and obtain a set of clean measurements. The procedure is organized in three steps. The first step gives a sort of initial guess of the position taking into account only the SVs clock correction. At this step the other models are not applicable because the position is not yet known and Fig. 7. GPS error correction diagram. Fig. 8. Minimum Operation Performance Standard Message.

6 version 2.1, manages the automatic requests and downloads EGNOS messages. The messages are received with the Data Server to Data Client (DS2DC) protocol and decompressed as detailed in [4] in order to obtain the original EGNOS messages in the format shown in Fig. 8. The EGNOS correction format is the same for all the Satellites Based Augmentation Systems (SBAS) like the American Wide Area Augmentation System (WAAS) or the Japanese MTSAT Satellite-based Augmentation System (MSAS) and it is based on the Minimum Operational Performance Standard (MOPS) described in detail in [5]. The MOPS format, shown in Fig. 8 gathers the corrections in different messages as shown in TABLE I. The driver takes these messages and decodes them depending on the 6 bits type identifier and taking into account all the validity constrains. The driver evaluates the message relationships shown in Fig. 9 and the messages validity times as detailed in [5]. The validity times are different for each message and in some cases very short; this is one of the most limiting factors in the correction application. Hence, as explained in Section II, the PVT computation is done at the LE side that continuously has the availability of EGNOS TABLE I CORRECTIONS MESSAGES Type Contents Validity Time [seconds] 1 PRN Mask assignment 2 to 5 Fast corrections Variable 6 Integrity information 12 7 Fast corrections degradation 2 factor 8 Reserved -- 9 GEO navigation message 2 1 Degradation parameters 2 11 Reserved WASS Network Time/UTC 8 13 to 16 Reserved GEO satellite almanacs Ionospheric grid point mask 1 19 to 23 Reserved Mixed Fast/Long term Variable/2 corrections 25 Long term satellite error 2 corrections 26 Ionospheric delay corrections 27 EGNOS service message Clock-Ephemeris 2 Covariance Matrix 29 to 61 Reserved Internal Test Message -- corrections. The decoded EGNOS corrections are periodically saved into a swap structure; the SISNeT driver allows to get the EGNOS corrections block on the basis of the GPS time of the raw UT measures that must be corrected. The corrections are used in the third step of the algorithm depicted in Fig. 7 where a good estimate of the position is known. Actually the corrections exploited are: Fast Corrections (Messages 2-5) Long Term Corrections (Message 25) Ionosphere Corrections (Messages 26) After this step the mean of raw data errors are removed and it is possible to know the precise user position with different PVT algorithms. VI. TESTS AND RESULTS Many tests have been performed in order to demonstrate the validity of the selected architecture, the performance of the PVT algorithm and the effectiveness of the EGNOS corrections described in Section V.C. The results discussed in this Section are obtained using data of a measurement session about hours long, computing a PVT every 1 seconds and using as reference a georeferenced antenna. Hereafter, Fig. 1 depicts an example of augmentation due to the use of EGNOS with satellites masking angle of 5 degrees. The first plot shows the satellites availability and it is possible see that after the GPS time epoch 4.5e5 seconds the satellites availability is reduced to 4 satellites. In correspondence with the low satellites availability the Geometric Dilution of Precision (GDOP) increases and the 3D error of the PVT algorithm using the data without the EGNOS corrections (grey points) is up to 25 meters. At the same GPS epoch using EGNOS the 3D error (black points) is contained Fig. 9. EGNOS message constraints.

7 1 Vertical Percentage within 2 m Fig. 1. Comparison of the 3D positioning errors introducing (grey) and not introducing (black) EGNOS corrections in the system. Errors are provided together with the system availability and GDOP Masking Angle [ ] Fig. 12. Percentage of computed positions vertical errors within 2 meters for different masking angles. Measurements without EGNOS corrections appear in grey, with EGNOS corrections in black. 1 Horizontal Percentage within 2 m Masking Angle [ ] Fig. 11. Percentage of computed positions horizontal errors within 2 meters for different masking angles. Measurements without EGNOS corrections appear in grey, with EGNOS corrections in black. within 3 meters. Of course, the pure use of EGNOS correction cannot overcome the problem of missed positions due to a not sufficient number of satellites. The real advantages in the EGNOS use are well synthesized in the bar diagram of Fig. 11 and Fig. 12. Fig. 11 shows, for different satellites masking angles, the percentage of computed positions which are within a 2D error of 2 meters. With a mask of 5 and degrees the improvement is about 25% but with a mask of 35 degrees (i.e. with low satellites availability) the improvement grows up to %. These results confirm that in a harsh environment with low satellites visibility, as dense forest, mountain or urban canyon, a LE able to apply the EGNOS corrections maintains high precision in the remote terminal positioning. Fig. 12 highlights that the EGNOS corrections introduction increases the system performance also for the vertical component. In Fig. 13 the error comparison between the PVT Fig. 13. System performance (3D error) for different masking angles (5,, 35 ). Results are plotted for GPS stand-alone measurements (grey) and EGNOS corrected measurements (black). computations with and without EGNOS is shown as a function of the elevation angle. This figure confirms that, as expected, when the satellite elevation mask at the UT increases, during some time periods it is not possible to locate the UT due to an insufficient number of satellites in view. On the other hand Fig. 13 demonstrates that whenever a position is obtained the error in the EGNOS corrected PVT, has always a smaller mean than the standalone positioning. In particular, at some time epochs, with bad GDOP the standalone positioning would not reach a level of accuracy suitable for the management of rescue interventions. These results confirm the suitability of the EGNOS based system in difficult environments as mountain canyon, where the visibility elevation mask can be much higher than 35 degrees. As an example, Fig. 14 shows the advantages of using EGNOS over one hour of data collection during which the GDOP value increases due to the limited number of visible satellites. During this time period the stand-alone GPS does

8 Horizontal Percentage within 2 m Masking Angle [ ] Vertical Percentage within 2 m Masking Angle [ ] Fig. 14. Percentage of computed position horizontal and vertical errors within 2 meters for different masking angles, evaluated over one hour of measurements. Measurements without EGNOS corrections appear in grey, with EGNOS corrections in black. 1 Masking Angle = D Error - Cumulative Distribution 1 Masking Angle = Masking Angle = D Error - Cumulative Distribution Masking Angle = Masking Angle = Masking Angle = Fig. 15. Cumulative distributions of the 2D and 3D errors for different masking angles (5,, 35 ). Results are plotted for GPS stand-alone measurements (grey) and EGNOS corrected measurements (black). Masking Angle 5 35 TABLE II ESTIMATE ERRORS Error Components GPS GPS+EGNOS East Mean Std North Mean Std Up Mean Std D Mean Std D Mean Std East Mean Std North Mean Std Up Mean Std D Mean Std D Mean Std East Mean Std North Mean Std Up Mean Std D Mean Std D Mean Std not provide a possibility to have precision in the 3D positioning sufficient to make the system reliable in rescue operations. However, using EGNOS it is possible to maintain the rescue service management available for a larger percentage of time. Fig. 15 shows the cumulative distributions of probability of being within 2 meters as a function of satellites elevation mask. The black lines, representing the EGNOS corrected measurements, are always higher than the grey lines referring to the stand-alone GPS measurements. This means that EGNOS always improves the system performance, especially when there is low satellites availability. In TABLE II some numerical results, referring to the test performed, are summarized. VII. CONCLUSIONS AND FUTURE ACTIVITIES In this paper a prototype architecture of a local Element for the provision of a network-based positioning service for mountain environment has been presented. The devised infrastructure aims at speeding up and simplifying the coordination procedures of rescue teams, guaranteeing an higher level of accuracy in the positioning and avoiding problems related to the manual operations. The system implement a Local Element concept, realizing a network-based positioning in a remote centralized center where the EGNOS corrections are available (from the satellites or through the SISNeT access). These results presented confirm that the use of the EGNOS corrections, allows for reaching a level of accuracy in the positioning suitable to the search and rescue applications in mountain environments, where elevation angle of visible

9 satellites can be 35 or even higher. Future work will address the refinement of the communication link introducing more sophisticated coding and cryptography schemes in order to protect the pseudorange information exchange by UT and LE. ACKNOWLEDGMENTS Authors would like to thank Istituto Superiore Mario Boella research centre for providing the facilities exploited performing the tests in the Navigation Lab. Special thanks to the CNSAS members for the cooperation in the definition of the system requirements and for the provision of the VHF radio devices. The authors would like to thank also Dr. Carl Carter of SiRF Technology, Inc. for his kindness in providing the effective technical support. REFERENCES [1] SiRF Binary Protocol Reference Manual. San Jose, CA: SiRF Technology, Inc., April 5. Available: [2] GPS Interface Control Document ICD-GPS-, Revision C. U.S. Air Force. Available: [3] B. W. Parkinson, J. J. Spilker Jr., Global Positioning System: Theory and Applications, vol. 1. Washington, DC: American Institute of Aeronautics and Astronautics, Inc., [4] F. Toran, J. Ventura-Traveset, SISNeT User Interface Document, Issue 2, Rev. 1. European Space Agency, 2. Available: [5] Minimum Operational Performance Standards for Global Positioning System/Wide Area Augmentation System Airborne Equipment. Washington, DC: RTCA, Inc., 1.