EVOLUTION AND INDUSTRIALIZATION OF A SBAS REAL-TIME PERFORMANCE MONITORING TOOL (EVORA)

Transcription

1 ENC 2015 Page 1 EVOLUTION AND INDUSTRIALIZATION OF A SBAS REAL-TIME PERFORMANCE MONITORING TOOL (EVORA) J. Doubek 1, M. Houdek 1, C. A. Pandele 2,3, A. Polivka 1, D. Chung 1 1 Iguassu Software Systems, Prague, Czech Republic 2 ESA, EGNOS Project Office, Toulouse, France 3 Institute of Space Science, Romania Abstract EVORA is a software tool being developed by Iguassu Software Systems under an ESA contract. It is the successor of the Real Time Performance Monitoring Tool (RTPMT), which measures performance of Satellite Based Augmentation Systems (SBAS) in real time. EVORA introduces new functions, capabilities and interfaces. Moreover, the software is presently being qualified to make sure it will give highly reliable results. The tool will be used by the ESA EGNOS Project Office, Thales Alenia Space France and other aviation end-users. EVORA is multi-constellation and multi-frequency real-time processor. It works with real, simulated or offline data. Real data is read from RTCM streams broadcast over the NTRIP network through internet. An example of a source of simulated data is the Support Platform for EGNOS Evolution and Demonstration (SPEED). EVORA provides users with performance analysis over specific region or station. At any moment the user can see protection levels, availability, continuity, position error, ESA Stanford diagrams and ARAIM results. EVORA implements algorithms from the Minimum Operational Performance Standards for Global Positioning System (MOPS) and it can also compute the dual frequency solution using the SBAS L5 frequency. The tool is divided in three parts: the receiver, the server and the client. The receiver is responsible for collecting data from input sources. The server then computes results for all SBAS regions and stations. It is written as a multi-process application capable of computing all analysis using inputs from different SBAS systems. The client is a Java applet visualizing results computed by the server. It can be comfortably run from the web browser without any additional installation. The client does not require any special computational power. Multiple users can be connected to the same server to visualize the results. Historical data can also be loaded. EVORA users can subscribe for events occurring during the processing. Such an event can be the loss of SBAS signal, misleading information, etc. Event notifications can also be sent to users by . EVORA creates automated HTML daily reports that include summary, statistics and graphs for all computed analysis.

2 ENC 2015 Page 2 1. EVORA overview The EVORA software tool is the successor of the Real-Time Performance Monitoring Tool (RTPMT). RTPMT was developed in the framework of the ESA Czech Incentive Scheme Call. It turned out to be very popular among users in ESA and elsewhere. This is due to a fact that the software works in true real-time and therefore provides valuable insight into SBAS performance. Although RTPMT is quite a powerful tool that is still being actively used, further evolutions have been identified to keep it up-to date. These new ideas were formalized in the EVORA contract. EVORA provides users with the multi-constellation and multi-frequency solutions, optimized processing algorithms, various input data sources and new analysis such as ARAIM, ESA Stanford diagrams, etc. The objective of the tool is also to obtain the DAL-E level of qualification with the support of TAS-F. Therefore users can trust the EVORA outputs and use them for non-safety of life applications. EVORA is a real-time performance monitoring tool processing all input data as soon as they arrive. The term real-time is relative, because EVORA is a data driven processor. Even though the most common usage is to use real time data, EVORA is also capable of processing data at slower or higher rates. The tool is divided in three parts: EVORA Receiver, EVORA Server and EVORA Client. EVORA Receiver processes messages from external sources (SPEED, NTRIP, SISNeT), extracts relevant information and sends messages to the EVORA Server. EVORA Server is the core of EVORA. It collects the messages from the EVORA Receiver, computes results and sends them to EVORA Clients. EVORA Clients are the graphic interfaces for users. It shows graphical representation of data received from the EVORA Server and allows the interaction with the server. Figure 1 shows the EVORA architectural design. Figure 1: EVORA architectural design 2. EVORA Receiver EVORA Receiver acts as the interface between the external data flow sources and EVORA Server. It converts external messages to EVORA internal format representing observation, navigation and SBAS messages. Those messages are then passed to the EVORA Server. The receiver allows connections to multiple systems like NTRIP, SISNeT, SPEED, etc. NTRIP is the Networked Transport of RTCM via Internet Protocol transferring RTCM messages over internet. For the NTRIP connection EVORA Client specifies which stations are to be monitored. NTRIP provides users with satellite ephemeris, station observations and SBAS messages. SISNeT is the protocol for broadcasting SBAS message over internet. It can serve as an auxiliary source of SBAS messages to NTRIP. EVORA can run without SISNeT when receiving SBAS corrections over the NTRIP network. SPEED is the platform for emulating SBAS systems and it uses its proprietary protocol for broadcasting

3 ENC 2015 Page 3 nominal and flexible messages. The architecture of the EVORA Receiver is shown in Figure 2. Server keeps information of all the users, their warning configuration and other settings. EVORA Server receives satellite ephemeris, observation data from various stations and SBAS corrections. The task of the server is to compute solutions for all available stations and for a defined geographic grid. Different results are available for different SBAS satellites for single and dual frequency solutions. Single frequency solutions are based on SBAS corrections broadcasted on L1 or L5. Dual frequency solution takes into account the combinations of L1 and L5. When L5 is not provided by the SBAS satellite, only L1 solutions are available. The algorithms for L1 solution implement the MOPS standard ([1]). Figure 2: EVORA Receiver architecture The current EVORA has two modes of operation: the real-time (NTRIP/SISNeT) mode and the SPEED mode. Each mode determines which input sources are accepted by the EVORA Receiver and sent forward for processing. In the real time mode only NTRIP and SISNeT inputs are taken into account as they represents real data streams. In the SPEED mode only the SPEED messages are processed. SPEED messages can come in real time rate or in any other rate (i.e. fast replay that is 7 times faster). EVORA Receiver has been designed to easily implement different type of inputs for future evolutions of the tool. 3. EVORA Server EVORA Server is the processing core of EVORA. It interfaces with the EVORA Receiver and the EVORA Client. EVORA Receiver passes to the server information coming from various streams. The server then performs all the necessary computations required by users. Results are then sent to the EVORA Client and stored locally in human readable text files. Furthermore, the EVORA Figure 3: EVORA Server architecture The main element of the EVORA Server is the EVORA Server Core. It is written in Python and receives the messages from the EVORA Receiver. It starts several instances of SBAS Processing Cores, each representing a unique SBAS satellite. The SBAS Processing Core is the responsible for making

4 ENC 2015 Page 4 computations through the interface to the GNSS processing library, which calculates the requested parameters and returns the results to the SBAS Processing Core. The GNSS processing library is developed in C++ and contains optimized GNSS algorithms to improve the server performance. The illustration of the server architecture is shown in Figure 3. EVORA Server is written as a multiprocessor application. It is recommended to run it on a machine with multiple cores, especially when there are more SBAS sources to be processed. The server computes solutions every second. When data input exceeds the computational capacity, the server can automatically skip some solutions to prevent the application crash. 4. EVORA Client The EVORA Client is the visualization part of EVORA. It is written in Java and can be run as an applet from the web browser. It continuously receives updated results that were computed in the EVORA Server. The client can be loaded on different computer than the server. This configuration is useful for separating the computational part from the visualization part. Moreover the EVORA Client does not require such a powerful machine as the server. Several EVORA Clients can be simultaneously connected to the EVORA Server allowing different users (e.g. from lab, office, home) to see real-time results and observe operational status of the tool. Each EVORA user has to have a registered account. Three account types are present: basic, advanced and admin. Basic account enables user to receive SBAS status, region results and results from particular stations. Moreover the Required Navigation Performance level can be specified. Advanced account adds to the functionality the warning management. Admin account can also manage stream sources and provides access to user management. EVORA visualizations can be split into three sections: the SBAS message content, geographical area results and station observation results. Each of the section shows results for single and dual frequency (when available). SBAS message part receives the augmentation messages from the server, performs the decoding and visualizes its content. Geographical area results show the XPL, availability, accuracy and continuity for a pre-defined area. And station results visualize for each station its details, computed position, position error, XPL, safety indexes, Stanford plots, ESA Stanford plots ([2]), satellites tracked by the station and ARAIM results. EVORA Client architecture is shown in the Figure 5. Figure 4: EVORA Client main window Figure 5: EVORA Client architecture

5 ENC 2015 Page 5 Before EVORA Client visualizes specific results, it sends a request for data to the server. Then the computed data is received and plots are updated every time new data are available. After the visualization is closed by the user, the client stops receiving updates for that analysis. This approach guarantees that only needed data are transferred between EVORA Server and EVORA Client. 5. EVORA functions EVORA performance analyses can be divided into three principal categories. Results for specific geographical area, as described in 5.1, results for observation stations, as presented in section 5.2, and results related to SBAS satellites, as presented in section 5.3. EVORA Client provides a user graphical interface which shows analysis result on a region map. Each point in the region is represented by a coloured square. The colour of the square is bounded to the actual point value (Figure 6). It is also possible to switch to contour plot mode where borders between individual points are smoothed using the interpolation algorithm. The graphical interface can show results for just one region or for combined regions from different SBAS sources. Such configuration allows seeing the performance of different SBAS systems on one geographical map. It is also possible to show the optimal view, where best received results from all sources are displayed (see Figure 7). Apart from computations, EVORA can also send alert messages to users, in case a special event occurs. Finally the tool produces daily HTML report including analysis graphs from the previous day Results for specific geographical area SBAS satellites provide augmentation messages that can be used to compute protection levels, availability and continuity over specific region. In EVORA, region is the rectangular geographical area consisting of several individual points in a grid. The area borders and the resolution of the grid are configurable. The region is specific for the SBAS system and can be even configured separately for a particular satellite. For example EGNOS satellites have service regions usually over Europe (ECAC), WAAS over United States (CONUS), MSAS over Japan (FIR), etc. EVORA Server computes protection levels, availability and continuity for each point in the region. Results are available for all active SBAS satellites and for two single frequency solutions (L1, L5) and dual frequency solution (L1+L5). Figure 6: Horizontal protection level over Europe from SBAS PRN 120 Figure 7: Optimal availability for all available SBAS sources Protection level graphs are updated every second, availability and continuity graphs every minute. Update intervals are

6 ENC 2015 Page 6 configurable and can be adjusted for specific needs. The configuration of geographical area analyses shall reflect the computational power of EVORA Server machine. For powerful machines the resolution of the region grid can be smaller. On the other hand, on computer with less computational power, smaller grid resolution might be needed. contain true station position, computed station position, position errors (PE), protection levels (PL), availability, continuity, safety indexes (SI), Stanford plot, ESA Stanford plot for all geometries ([2], Figure 8), ESA Stanford plot for worst combination ([2]) and the polar plot of visible satellites (Figure 9) Observation station results EVORA receives observation from several stations. Depending on the mode, those stations provide real time data from NTRIP or emulated observations from SPEED Ranging and Integrity Monitoring Stations (RIMS). Each NTRIP station broadcast just one observation per epoch while the SPEED station offers observables on RIMS channels A and B. Figure 9: Polar plot at station TLSE0. NSE, PE, and SI are provided through textual and graphical form. Graphs contain values on y-axis while the x-axis holds the time (see Figure 10). Graphics is continuously redrawn as new values are received. Horizontal PE is also plotted on a polar position graph allowing the user to inspect the error distribution from the true origin (see Figure 11). PE values are available just for connected stations, but EVORA is able to plot the accuracy map over a region using the Kriging algorithm from available values. Figure 8: ESA Stanford plot for all geometries at station BRN. Station results are computed for each active SBAS satellite and for two single frequency solutions (L1, L5) and the dual frequency solution (L1+L5). For each combination, EVORA Client shows the map of all connected stations and user can interactively select stations for which the analyses window will be opened. Results for each station

7 ENC 2015 Page 7 having any additional information. EVORA provides SBAS message visualization and satellite monitoring status. SBAS message visualization decodes incoming SBAS messages and shows user the decoded information. Data are provided in tabular format, but in the case of ionosphere also the graphical view is present. Output is updated every time new SBAS message arrives. Figure 10: Horizontal position error (HPE) and protection level (HPL) at station BRN. Blue line is the HPE, green line is the HPL, yellow line shows number of visible satellites and pink line is the number of satellites used for the SBAS solution. Satellite monitoring status shows on a graphical timeline information, when satellite was monitored, not monitored or was declared as not used (Figure 12). This information comes directly from the integrity part of SBAS messages. Figure 11: Horizontal position plot at station ALB. Apart from the SBAS solution, station position and PL can be computed using the Advanced Receiver Autonomous Monitoring (ARAIM) approach. ARAIM inspects individual constellations and satellites and when specific criteria are met, satellites or entire constellation can be removed from the solution. More details can be found in [3]. All station results are stored by the EVORA Server and historical data up to 24 hours can be retrieved directly from the EVORA Client Results related to SBAS satellite The content of SBAS augmentation messages can be independently interpreted without Figure 12: Monitored satellites. Intervals when a satellite is monitored are shown in blue. When the state of a satellite is "do not use", it is shown in red Warning management User with advanced or admin rights can set up a warning management to be informed when a special event occurs. User is informed through a dialog in the EVORA Client or by receiving an . Warnings can be global or related to a specific SBAS satellite. It is also possible to define custom warnings through the user script. Warnings are available only for the real time mode of EVORA. Global warnings include notifications when EVORA Server starts or stop, when specific

8 ENC 2015 Page 8 observation station is connected or disconnected and when the server disk space is low. SBAS satellite specific warnings are set separately for each augmentation satellite. User can be informed when the satellite signal is lost or received and when the specific processing core started or stopped the observation processing. Detailed configuration for particular observation stations is also available. It is possible to monitor when system is available/unavailable for horizontal/vertical navigation and when misleading or hazardously misleading information occurs. Furthermore, the administrator can easily define its own custom warnings. 6. Conclusions EVORA is a software tool for monitoring the real time performance of SBAS Systems. It computes single frequency and dual frequency solutions and has multi constellation support. EVORA consists of three independent modules: the EVORA Receiver responsible for collecting input data, the EVORA Server performing all the calculations and the EVORA Client visualizing results. Input data can be real time delivered through NTRIP streams or simulated via the SPEED platform. The tool is being qualified to the DAL-E level with the support of TAS-F. EVORA computes protection levels, availability and continuity for specified regions. It visualizes observation station results including position solution, position errors, protection levels, availability, continuity, Stanford and ESA Stanford graph, ARAIM results and satellite positions. User can also inspect the content of incoming SBAS messages and see the history of monitored satellites. The tool will be ready in July 2015 for the navigation community, aviation experts and anyone interested in SBAS real time performance analysis. It already has two important user entities waiting for its release. Iguassu will be happy to discuss with you how EVORA could provide to you detailed real-time information about the SBAS of your interest. Please contact miroslav.houdek@iguassu.eu for further information. References [1] Minimum Operational Performance Standards (MOPS) for airborne navigation equipment (2D and 3D) using the Global Positioning System (GPS) augmented by the Wide Area Augmentation System (WAAS) [2] M. Tossaint, J. Samson, F. Toran, J. Ventura-Traveset, The Stanford-ESA Integrity Diagram: Focusing on SBAS Integrity [3] J. Blanch, T. Walter, P. Enge, Advanced RAIM User Algorithm Description: Integrity Support Message Processing, Fault Detection, Exclusion, and Protection Level Calculation