Final Report Summary - POSTO (Methodology and SW libraries for the design and development of GALILEO/EGNOS-based POSiTiOning applications for smartphones)
Executive Summary:
POSTO provides the methodology and the software libraries required for the design and development of GALILEO/EGNOS-based mobile positioning applications, targeting SMEs who are seeking to develop positioning applications for smartphones by exploiting the full potential of the GALILEO/EGNOS benefits.
Within POSTO, a set of EGNOS SW libraries supporting the development of EGNOS-based positioning applications for popular smartphone platforms is provided along with pre-configured EGNOS SW libraries for different operational environments including, urban, low-density urban, high-density urban, rural, etc. in order to achieve EGNOS best performances. The POSTO SW libraries provide EGNOS compliant and more accurate positioning information along with integrity information to the applications that use them through a simple API.
Additionally, a set of the applications were developed/adapted in the POSTO project in order facilitate the testing of the behaviour of the POSTO software libraries and its components. These applications include a hiking application, a forest inventory application, an automotive application, a people tracking application, a site health monitoring application and an application targeting the agricultural market.
Following the overall assessment of the POSTO results, the POSTO concept was proved to be applicable in several environments, i.e. maritime, agriculture, maritime and Ambient Assisted Living by facilitating and enabling the increased accuracy of position provisioning and integrity. It has been identified that using an external EGNOS receiver is not acceptable for smartphone applications, a constraint that is mainly put by the smartphone manufacturers, which do not provide access to the internal chipset data. In order to overcome this constraint, an alternative solution has been integrated in the POSTO SW libraries, i.e. the SIGNATURE tool, for the computation of an “EGNOS” position with the built-in GPS chipset of a smartphone, nevertheless with questionable performance and no integrity. All in all, the POSTO approach is assessed as positive while synergies with other projects with potential benefit in future R&D and commercial activities are foreseen. Finally, a market value potential of the POSTO results within a 2 year window is expected since part of POSTO applications provided within the project are already targeting the evolution of existing commercial solutions.
Project Context and Objectives:
POSTO project provides the methodology and the software libraries required for the design and development of GALILEO/EGNOS-based mobile positioning applications, targeting SMEs who are seeking to develop positioning applications for smartphones by exploiting the full potential of the GALILEO/EGNOS benefits.
The project started on 01/11/2011 and ended on 31/10/2013. The partners involved in this project are HELILEO, EKITO, TRACKER, GNOMON, ARBONAUT, MILTECH, TELETEL, M3SYSTEMS, HANDCRAFTED SOFTWARE and EMYPEE.
The main project objectives of the whole project were:
• To perform a state-of-the-art analysis with respect to the existing smartphone platforms and their SDKs for supporting positioning applications development and to analyse the requirements from the SMEs perspectives.
• To adapt the existing EGNOS correction and integrity algorithms and port them to smartphone platforms.
• To define the design guidelines of EGNOS-enabled positioning applications for smartphones and implement/adapt a set of EGNOS-enabled smartphone positioning applications.
• To assess and evaluate the effectiveness of the EGNOS SW libraries for smartphones through the realization of a set of pilots to be administered by the participating SMEs.
• To disseminate the knowledge to be generated by the project and promote the adoption of the POSTO approach for smartphone positioning applications development at the European Level.
• To exploit the POSTO results for the benefit of the participating SMEs.
The main result of POSTO is the POSTO SW libraries for implementing EGNOS-based positioning applications and the POSTO applications. The POSTO SW libraries support the development of EGNOS-based positioning applications for Android platforms and additionally, they provide pre-configured EGNOS SW libraries for different operational environments including, urban, low-density urban, high-density urban, rural, etc. in order to achieve EGNOS best performances. The POSTO applications provide a set of the applications that were developed in the POSTO project in order facilitate the testing of the behaviour of the POSTO software libraries and its components for different application domains.
The following applications were implemented/adapted in the context of the project:
• Hiking application, which allows the user to track his hiking trips and has been developed from scratch for the Android platforms.
• ArboWebForest application, which allows forest inventory professionals to record information about forest plots.
• Mobile Locator tracking application, which allows the tracking of subjects of interest. An android smartphone application has been developed to act and perform as a tracking device.
• Site Health Monitoring application, which allows the precision navigation in a restricted or dangerous area. The Site Health Monitoring application has been developed from scratch for the Android platform.
• Automotive Application which which includes an adapted Hiking application that also receives information from the CAN bus of a vehicle (velocity, temperature etc.), which runs on an integrated demonstrator based on Time and Space Partitioning concepts (synergetic application with the POSTO and VOS4ES projects).
• AgriGeo application, which allows the recording and categorization of agricultural POIs. The AgriGeo application has been developed from scratch for the Android platform along with its server component.
The solution that the POSTO approach offers is mainly targeting SMEs or other organizations that are seeking cost-effective and easy to use solutions allowing for rapid development of smartphone positioning applications with higher accuracy and integrity by exploiting the full potential of EGNOS technology (and GALILEO in the future).
The benefits for the SMEs include but are not limited to:
• Rapid prototyping of positioning smartphones applications, based on EGNOS targeting almost the 80% of the smartphone growing market.
• Reduce time to market and development costs in smartphone applications that use EGNOS.
• Gain the know-how for exploiting integrity in smartphone positioning applications.
• Be competitive by enhancing existing positioning smartphones applications with EGNOS’ higher accuracy and integrity.
• Allow providing applications through existing popular applications stores (e.g. Android’s Google Play Market etc.).
• Target LBS, which is the main driver of the GNSS market and particularly the downstream value chain (a prediction is that the market size will reach 236 billion in 2025).
• Be ready to provide GALILEO based positioning applications in the near future.
The POSTO high level architecture is depicted in the following figure:
Figure 1: POSTO high level architecture
The POSTO high level architecture involves the following components:
• A smartphone device running the user application.
• The user application, which uses the POSTO libraries to determine the device’s position and integrity.
• An external GPS/EGNOS device, which feeds the POSTO libraries with the raw GPS and EGNOS data.
• The EDAS server, from which the POSTO libraries receive the EGNOS data through the Internet, in case the EGNOS satellites are out of view.
• The POSTO libraries, which calculate the device’s position and apply the EGNOS corrections to it, calculate the integrity and include an interface with the external GPS receiver and an interface with the EDAS server.
The POSTO SW libraries provide EGNOS compliant and more accurate positioning information along with integrity information to the applications that use them through a simple API.
The library manages the connection with the external GPS receiver and possibly with a network EGNOS messages provider (EDAS v2 is supported). The data must come from steady streams to allow the library to compute a position and provide it to the user application, as soon as it can.
The POSTO library encapsulates the EGNOS SDK core and the SIGNATURE tool. It operates as a proxy between them and the user application. Furthermore, the EGNOS SDK has been enhanced by adding various features including the enhanced accuracy module (Receiver Autonomous Integrity Monitoring – RAIM and DGPS (Differential GPS) based on RAIM) and the enhanced integrity/availability module (try to better consider multipaths or bad SNR in the value of the protection levels and in the computation of the position).
Project Results:
3.1 METHODOLOGY AND DESIGN GUIDELINES
3.1.1 OVERVIEW
More and more smartphone devices in the market are equipped with location determination mechanisms such as GPS. This allows for the creation of smartphone applications that use the device’s position to expand the application features and functionality and to enhance the user experience. These applications target a wide variety of users, from professionals to general consumers. Also, the positioning applications cover a wide variety of application areas such as navigation, resource tracking, social check-ins, local personalization, etc.
Currently in the market, the positioning applications are available for multiple endpoints, on top of smartphone devices, that use multiple configurations such as in-car navigation systems with external GPS receivers, smartphone devices with internal or external receivers, dedicated GNSS data collection devices, etc.
Regarding smartphone applications, multiple methods are available to determine the user’s position. However, the most accurate one is with the usage of the GNSS system. In this concept the POSTO Software Libraries and relevant techniques enable the calculation of user’s location according to EGNOS-enhanced position of a smartphone device.
Although different development environments exist for each smartphone platform, the following guidelines are generic and applicable to all positioning applications for smartphones.
3.1.2 DESIGN CONSIDERATIONS AND CHALLENGES
Due to technology limits and the mobile nature of smartphone applications, various challenges exist when designing a positioning application in order to be able to provide a smooth and seamless user experience.
To calculate the position of the user, the smartphone device receives messages from the GNSS constellations. In order for these messages to be received, the device must be in-view of the GNSS constellations otherwise no positioning fix will be achieved. The positioning applications should be designed to accommodate this issue so that they do not hang or crash when the device cannot receive any signals from the GNSS constellation. Also, the positioning applications should be designed with the philosophy that the location determination functionality of the device can be lost at any time. When the position of the device cannot be determined, some APIs may provide a false/trash position. For this reason, the positioning applications should always use the available APIs to check the status of the GNSS subsystem of the device before using the provided location.
Current consumer GNSS receivers depend on the measurement of the time that a signal takes to travel from the GNSS satellites to the receiver. Several factors affect the precise measurement of the travel time of the signal such as atmospheric delays, reflection on surfaces (multipath effect), shifts in satellite orbits, clock errors and relativistic effects. With the usage of a Satellite Based Augmentation System such as EGNOS, those errors are minimized but not completely eliminated. Due to the possible existence of errors in the reported position, integrity mechanisms are available by SBAS to provide a level of confidence in the calculated position. The positioning applications should always consider that the reported position of the device might be wrong and should use these integrity mechanisms, if available, in order to present to the user the level of confidence that exists for the reported location. Also, the positioning applications should adapt their behaviour depending on the integrity of the calculated location. For example, a tracking application should display the location of the tracked object and present the confidence level of the calculated position (e.g. ± 5m).
GNSS receivers and positioning calculation software that are currently used in smartphone devices and other consumer-oriented user endpoints are configured to be used in a wide variety of environments such as rural, urban, etc. Due to this generalness of their configurations, their accuracy is reduced in comparison with a receiver that is configured and operates under a certain environment. It is therefore important that the correct configuration is used depending on the operating environment. Smartphone positioning applications that use the POSTO Software Libraries for position calculation can greatly benefit in this context, by using the provided API to explicitly configure the position calculation subsystems for the exact operating environments that the application is expected to function on.
Smartphone positioning applications inherently operate in a mobile environment with limited resources. Positioning calculation, correction and integrity computation requires a significant amount of processing resources which in turn have a toll on the mobile device’s battery. Therefore, the positioning applications should only calculate the position of the device when it is absolutely necessary. For example, it is a waste of resources if the calculated position is not shown to the user because the device is on stand-by mode.
Calculating the position on a mobile device, especially when the GNSS receiver performs a cold start, requires some time. Also, under certain conditions, the device may not be able to produce a position (e.g. satellites out of view). In all cases the user should be informed of the status of the position calculation in order for the application to be able to provide a smooth user experience. The user will get confused if the application does not work as expected in case the position cannot be calculated and he is not notified. In this context, the application should display the error messages of the position calculation mechanisms, ideally using a graphical representation.
Smartphone devices offer a multitude of methods to determine the position, on top of the GNSS positioning. Some of those methods are the cell tower triangulation, WiFi networks and IP address based location. The most accurate method is of course the GNSS positioning, however not all applications require this level of accuracy. For example a weather application only needs to know the city that the user is and not his exact location. In this context, the applications should use the location calculation method depending on their accuracy requirements. The rationale is that it is much faster and less resource-intensive to use cell tower triangulation or the IP address to determine the user’s location than to wait for the GNSS unit of the device to initialize and calculate the position.
In summary the design considerations and challenges for positioning applications which are considered and addressed within the POSTO project are the following:
• Applications cannot expect the GNSS constellations to always be available, and should always check the status of the GNSS positioning subsystem before using the provided location.
• Even when using SBAS there is an error in the calculated position. Applications should use the available integrity mechanisms and adapt their behaviour depending on the confidence level of the calculated position.
• GNSS receivers and related software should be configured for the environment that the application is expected to operate on. Generic configurations reduce the positioning accuracy.
• Positioning calculation using GNSS in a mobile unit requires significant resources which have a toll on the device’s battery life. Positioning calculation should be used only when it is absolutely necessary and not if there is no use for the calculated position.
• In order to provide a smooth user experience, the applications should always provide the status of the positioning calculation to the user.
• Since various methods exist to calculate the position in smartphones, with various levels of accuracy, the applications should not choose the most accurate one but the one that provides the accuracy level that is required by the application. That way, the user experience stays smooth and the unnecessary usage of resources is minimized.
3.2 POSTO SW LIBRARIES AND CONFIGURATIONS FOR DIFFERENT OPERATIONAL ENVIRONMENTS
3.2.1 POSTO SW LIBRARIES OVERVIEW
The POSTO library provides EGNOS compliant and more accurate positioning information along with integrity information to the applications that use them through a simple API.
The library manages the connection with the external GPS receiver and possibly with a network of EGNOS messages providers (EDAS v2 is supported in the version 2 of the POSTO libraries). The data must come from steady streams to allow the library to compute a position and provide it to the user application, as soon as it can.
The POSTO library encapsulates the EGNOS SDK core and the SIGNATURE tool. It operates as a proxy between them and the user application. Furthermore, the EGNOS SDK has been enhanced by adding various features, as described in the following sections.
The figure below provides a high level diagram of the libraries:
Figure 3: POSTO Software Libraries architecture
The libraries break down into the followings components:
- Adapted EGNOS SDK, which is provided by the GSA and will be modified to be used by the POSTO libraries.
- SIGNATURE tool.
- EDAS, which manages the connection with the EDAS service provider and the processing of the received data.
- GNSS manager, which handles the data from the receiver (storage and access) and the launch of the position computation.
- SBAS manager, which handles the SBAS data (storage and access).
- Configuration, which provides a mean to set up the POSTO libraries.
- Computation which starts the PVT computation, when the required data are available.
- Application Layer, which makes the interface with the user application.
- Tools gather utility classes used by the others components.
The following section provides the description of each module
3.2.1.1 SBAS MANAGER
The SBAS manager manages all the SBAS data either from the signal in space or from the EDAS service. Its role is to gather the SBAS messages, to store them in order to make them available when they will be needed and to check whether their time-out has expired.
It sorts out the data coming from EDAS and the data coming from the signal in space through the GNSS manager.
3.2.1.2 GNSS MANAGER
This module is a part of the interface with the application layer. It manages the data received from the GPS receiver and launches the computation of the position when all the required data are available.
3.2.1.3 CONFIGURATION
This module is the other part of the interface with the user application. It allows configuring the POSTO libraries to adapt it to each situation.
It exposes methods to configure the raw values of the configuration parameters, but also methods to set them more easily with pre-set values.
The parameters could be stored in a text file, and so, the configuration module could load them if required.
The configuration module contains two classes and several enumerations to limit the value of some parameters.
3.2.1.4 TOOLS
The tools module gathers classes to manage the GPS time, the Ublox data and tools to manipulate binary data.
3.2.1.5 COMPUTATION
This module is in charge of the computation of the position. It uses the EGNOS SDK or the SIGNATURE tool for the PVT algorithm.
The EGNOS SDK is the core of the EGNOS SDK v3.
On Android and iOS, it has been developed in C and licensed under the European Union Public Licence (EUPL), Version 1.1 only (the "Licence"). A copy can be obtained at: http://egnos-portal.gsa.europa.eu/developer-platform/egnos-toolkits
The changes brought to the core of the EGNOS SDK are mainly located in functionalities to make them configurable, to adapt some parts of the algorithm and to add the differential algorithm.
As the EGNOS SDK, the SIGNATURE tool is provided by the GSA, to provide EGNOS on a smartphone. But while the EGNOS SDK needs an external receiver, the SIGNATURE tool uses the receiver embedded in the smartphone and an Internet connection to do the job.
This tool is available at: http://egnos-portal.gsa.europa.eu/developer-platform/egnos-toolkits
This tool has been adapted to be included in the POSTO libraries. If the user application required it and when the POSTO libraries get enough EGNOS data from EDAS and the required NMEA messages, the SIGNATURE tool is used to compute a new position fixed by the EGNOS corrections.
3.2.2 ENHANCED ACCURACY MODULE
3.2.2.1 RAIM
Position accuracy is one of the most important requirements for a navigation System. In order to enhance accuracy, one can think about selecting only a subset of the “best” satellites. In fact, sometimes measurements are affected by errors caused by the hardware used to estimate the position or the environment in which the signal travels. If a measurement is affected by one of these errors, it is better to ignore this measurement and compute a position estimate without it. The exclusion of “faulty” measurements is performed by the receiver integrity monitoring (RAIM: Receiver Autonomous Integrity Monitoring) algorithms which allow not only detecting a “positioning failure” but also excluding the source of this failure, and hence allow the accuracy enhancement.
3.2.2.1.1 RAIM overview
Receiver Autonomous Integrity Monitoring refers to a situation where a receiver uses the redundancy of satellite measurements to determine whether the difference between the position estimate and the true position exceeds a limit called the Alert Limit. If it is the case, we say that a “positioning failure” occurs.
The monitoring scheme generally consists of two functions: the fault detection and the fault exclusion. The goal of fault detection is to detect the presence of positioning failure. Upon detection, proper fault exclusion determines and excludes the source of the failure (without necessarily identifying the individual sources causing the problem) thereby allowing GNSS navigation to continue without interruption.
Most of the time, these functions are based on the comparison between a test statistic depending on the prediction error vector and a given threshold. It is a hypothesis test in which the test statistics computation is performed with the observable data. The decision threshold is set considering the statistical distribution of the test in the fault free case and a given false detection rate.
Concerning the performance prediction, as the position error remains unknown for the user, statistical tools have to be used to check requirements compliance (to predict the availability). This can be performed by predicting the smallest bias the algorithm is able to detect respecting the missed alert and false alert requirements (protection levels (PL) computation) or by predicting the probability of missed detection of dangerous biases.
Many Algorithms were developed in order to perform detection and exclusion, the most commonly used are the Least Square Residual RAIM (LSR RAIM) and the Maximum Solution Separation RAIM (MSS RAIM). The LSR RAIM can detect and exclude only one faulty measurement while the MSS RAIM can detect and exclude multiple faulty measurements.
3.2.2.1.2 Detection Mechanism
The detection of a positioning failure is performed by comparing a test statistic to a threshold (one threshold for the LSR RAIM and N thresholds for the MSS RAIM corresponding to every test statistic). If the test statistic is greater than the (corresponding) threshold, then detection occurs and, in this case, at least a “faulty measurement” leads to a positioning failure. Otherwise, all measurements are considered to be fault-free.
For the LSR RAIM, the test statistic is defined as the Squared Sum of Least Square residuals. A least square residual corresponding to a satellite is the difference between the measurement supplied by this satellite and the measurement predicted from the estimated position. The test statistic may be weighted by the inverse of the error covariance Matrix. If a “faulty” measurement exists, the residual corresponding to this measurement will be high and thus the test statistic exceeds the threshold. Otherwise, the test statistic value is small and never exceeds the threshold.
For the MSS RAIM, if we assume that only one faulty measurement exists, the test statistic is based on the difference between the position estimate generated by the full-set filter (using all the satellite measurements) and that generated by each one of the subset filters (each using all but one of the satellite measurements). The detection is therefore performed with N test statistics (N is the number of satellites in view). If a “faulty” measurement exists then the full set estimate is faulty while the subset excluding the faulty measurement supplies a good estimate. Therefore, the difference between these two estimates is greater than the threshold and hence, at least one of the test statistics exceeds the threshold. The other test statistics might also exceed the threshold. In fact, since the full set estimate and the subset not excluding the faulty measurement estimate are both faulty, nothing guarantees that their difference doesn’t exceed the threshold.
3.2.2.1.3 Exclusion Mechanism
If a positioning failure detection occurs, the “faulty measurements” must be excluded. The exclusion may be performed directly after detection or after an identification step. In the case of a direct exclusion, we just look for a fault-free subset of satellites (the detection statistic corresponding to this subset is smaller than the threshold) and exclude the remaining measurements. This method can exclude “good” measurements and therefore the step of identification is interesting. The identification is generally performed in the same way as detection.
For the LSR RAIM we compute N test statistics by removing from each subset one satellite. Normally we compute N thresholds corresponding to each test statistic, but since the noise distribution is assumed to be the same for all the measurements, the threshold is the same for all statistics. The only subset for which the test statistic doesn’t exceed the threshold is the fault-free subset. The satellite removed from this subset is the one that supplies the faulty measurement.
For the MSS RAIM, if we assume that only one faulty measurement is to be identified, the test statistic is based on the difference between the position estimate generated by the subset using all but one of the satellite measurements denoted n and the position estimate generated by the subset using all but the measurement n and another measurement m. Therefore, to perform the identification of one faulty measurement, we need N x (N-1) tests. Let’s denote i the faulty measurement, then the position estimate without i and that without i and another measurement are good and their separation (di,m) is certainly below the threshold whatever is m. Otherwise if j is a good measurement, then the position estimate without j is faulty (uses the measurement i) and that without j and i is good and therefore the test statistic (dj,i) certainly exceeds the threshold. In conclusion, for n fixed, we consider (dn,m) a test statistic. If (dn,m) is inferior to the threshold whatever is m, we conclude that n is a faulty measurement, otherwise n is considered a good measurement.
3.2.2.1.4 RANCO algorithm
The Range Consensus (RANCO) algorithm deals with the problem of multiple faulty measurements. It has a low computational complexity compared to the MSS RAIM if more than one measurement is faulty. It calculates a position solution based on four satellites and compares this estimate with the pseudo ranges of all the satellites that did not contribute to this solution. The residuals of this comparison are then used as a measure of statistical consensus. The satellites that have a higher estimated range error than a certain threshold are identified as outliers, as their range measurements disagree with the expected pseudoranges by a significant amount given the position estimate. This step is called Range Comparison. All subsets of four satellites that have a good geometry with respect to orthogonality and WGDOP (Weigted Geometric Dilution Of Precison) will be considered. If a measurement is consistent (after the range comparison) with a subset of four satellite measurements, this measurement is called inlier, otherwise it is called outlier. The subset with the most inliers is consequently utilized for identification of the outliers. This approach allows one to identify as many outliers as the number of satellites in view minus four satellites for the estimation, and minus at least one additional satellite, that confirms this estimation. As long as more than four plus at least one satellites in view are consistent with respect to the pseudoranges, one can reliably exclude the ones that have a bias higher than the threshold. The minimum necessary bias in the pseudorange that allows RANCO to separate between outliers and inliers is smaller than six times the variance of the expected error.
As the number of possible subsets is rather high and many of them have a weak geometry, it is reasonable to consider only the best subsets. Therefore, before performing the range comparison, a selection of the best subsets based on satellite geometry is necessary to reduce the computational complexity. By limiting the maximum number of failed satellites to a certain value, a post-selection of subsets can be performed to find the smallest combination of subsets that can investigate all identified failure modes. This allows reducing the number of subsets that will be used in the next step which is the range comparison. For the range comparison, the satellites, whose residuals of the comparison are smaller than the corresponding threshold, are defined as inliers of the current subset. A position estimate is re-computed with the subset with the highest inlier count and its inliers, and a final range comparison based on this position estimate is performed in the same way as the previous range comparison. The satellites whose residuals are higher than the corresponding threshold are considered by the algorithm as the faulty measurements.
3.2.2.2 DGPS BASED ON RIMS
Another way to improve the accuracy of the position is to use DGPS (Differential GPS) techniques. The main idea is to use one or several reference stations to correct the GPS measurements of the receivers. Many code-based DGPS techniques have been proposed to provide improvements in performance over stand-alone GPS. These techniques vary in sophistication and complexity from a single reference station that calculates the errors at its position for use with nearby GPS receivers to worldwide networks that provide data for estimating errors from detailed error models at any position near the Earth’s surface.
They may be sorted into three categories, local-area, regional area, and wide area, depending on the geographic area that they are intended to serve.
EGNOS is wide-area DGPS system, since it provides corrections all over the Europe through geo-stationary satellites. EDAS allows to get those exact same data via Internet but it offers other services too. Among others, there are:
- The GPS and GLONASS navigation messages in raw format and decoded
- The precise position of the RIMS antennas.
- The raw measurements of the RIMS
With the first one, EDAS can be used as an Assisted GPS system and then, reduce the time of the first fix.
The two last ones are required for the DGPS. Indeed, by knowing the exact position of a RIMS and its measurements of the satellite in view (pseudorange, doppler, …), it is possible for a nearby receivers to estimate the errors in their own measurements caused by satellites clock error, tropospheric and ionospheric effects.
This is the method used in most operational local-area DGPS.
3.2.2.2.1 Local-area DGPS
3.2.2.2.2 Position domain corrections
Conceptually, the simplest way to implement LADGPS is to place a single GPS reference receiver at a surveyed location, compute the coordinate differences (in latitude, longitude, and geodetic height) between that surveyed position and the position estimate derived from GPS measurements, and transmit these latitude, longitude, and height differences to nearby users. For the most part, the coordinate differences represent the common errors in the reference and user receiver GPS position solutions at the measurement time. The user receivers can use these coordinate differences to correct their own GPS position solutions.
Although extremely simple, this technique has a number of significant deficiencies. First, it requires that all receivers make pseudorange measurements to the same set of satellites to ensure that common errors are experienced. Therefore, the user receivers must coordinate their choice of satellites with the reference station; or the reference station may determine and transmit position corrections for all combinations of visible satellites. When eight or more satellites are visible, the number of combinations becomes impractically large (80 or more combinations of four satellites). A second problem may also arise if the user and reference station receivers employ different position solution techniques. Unless both receivers employ the same technique, (e.g. least-squares, WLS, or Kalman filters), with equivalent smoothing time constants, filter tunings, and so forth, position domain corrections may yield erratic results. For these reasons, position domain corrections are seldom, if ever, employed in operational DGPS systems.
3.2.2.2.3 Pseudorange domain corrections
Instead of determining position coordinate errors, the reference station determines and disseminates pseudoranges for each visible satellite. In order for the user receiver to determine its position accurately with respect to the Earth (i.e. for absolute DGPS applications), the reference station must have accurate knowledge of its own position in ECEF coordinates and disseminate it.
Once the user receiver gets those information from the reference station, it is able to compute the geometric range between the reference station and each satellite in the station’s view.
The geometric range is the range between the well known position of the station and the position of the satellite computed at the time of the pseudorange measurement done by the reference station.
The pseudorange measurement contains the range to the satellite, along with errors (ionospheric and tropospheric effects…).
The user receiver differences the computed geometric range with the station’s pseudorange measurement to form the differential correction. This correction, which may be a positive or negative quantity, is added to the user receiver’s pseudorange measurement of the same satellite.
To a significant extent, the user receiver’s pseudorange error components will be common to those experienced by the reference station with the exception of multipath and receiver noise.
By making pseudorange measurements to four or more satellites, the user receiver can compute its position by using one of the position determination techniques (e.g. least-squares, WLS, or Kalman filters). Since the residual pseudorange error is generally smaller statistically than the error of the uncorrected pseudorange, a more accurate position solution is generally attained. Importantly, when pseudorange corrections are applied, the clock offset produced by the position solution is the difference between the user’s clock error and the reference station clock error. For applications where the user requires accurate time, the reference station clock offset may be estimated using the standard position solution technique and removed from the pseudorange corrections. Removal of the reference station clock offset is generally desirable, even when the user does not require accurate time.
This is the method used in the POSTO libraries. The reference station is the closest RIMS (determined by the user receiver) and the data are sent through the EDAS service in the RTCM format.
The performances are directly linked to the distance from the RIMS and the difference of altitude between the station and the user receiver (for the troposperic delay). Note that multipath is the dominant error component over short baselines. For longer baselines, the residual ionospheric or tropospheric errors may dominate. For that reason, to use the DGPS functionality, the receiver must be close to a RIMS (less than 20km).
3.2.3 ENHANCED INTEGRITY/AVAILABILITY MODULE
To improve the integrity, the POSTO library implements a slightly different model to try to better consider multipaths or bad SNR in the value of the protection levels and in the computation of the position.
Then, the availability of the position is directly dependent on the availability of the GPS satellites. To improve accuracy, the “riskiest” satellites, the ones with a low SNR (Signal Noise Ratio) or the ones with a low elevation should not be used to compute the position.
This reduces the number of satellites available and might hinder the algorithm to get a new position (at least 4 satellites are required to get a position). That’s why a tradeoff between availability and accuracy must be found for each situation. In the POSTO libraries, the thresholds on the elevation and the SNR are configurable.
Finally, the POSTO libraries do not provide the position if it is considered as too bad. Indeed, the geometry of the satellites has a big effect on the final position. This can be represented by the HDOP value. The lowest it is, the best is the position. By using a threshold on the HDOP value, it is possible to filter the positions with a too high HDOP. This threshold is configurable in the POSTO library and so, it is possible to improve or not the availability. If the threshold is too high, the position might be really bad. But it is worth to note that the HPL value increases with the value of the HDOP, so the user is still informed about the quality of the position.
3.2.4 DATA INTERFACES
3.2.4.1 GPS INTERFACE MODULE
The POSTO libraries use an external GPS receiver to receive the raw GPS data. The communication with the receiver is performed over a Bluetooth connection and is controlled by the BluetoothWrapper component which abstracts the native platform’s Bluetooth functionality.
Then, once the connection is established, the application layer will manage the reception of the data with the help of the Tools module.
3.2.4.2 APPLICATION LAYER
The application layer gathers the classes exposed by the API and the threads used to provide the position to the user application and to collect the data from an external GPS receiver, from the internal receiver, from a recorded file and/or from an external SBAS provider.
3.2.5 INTERFACES WITH EXTERNAL SYSTEMS
3.2.5.1 EDAS INTERFACE
The EDAS Interface provides EGNOS data over the Internet, in case the external receiver is not EGNOS capable or is out of view of EGNOS satellites.
The EDAS Interface Module connects to the EDAS service indirectly through specialized server-side software which filters out and transmits only the messages that are required to apply the EGNOS calculations and integrity indicators, thus reducing the bandwidth requirements and network usage.
Figure 4: EDAS interface high level architecture
The EDAS Interface is composed of a server component and clients (the smartphones in POSTO).
EDAS server side
The server component consists of the Client Software, which is supplied by the GSA, and the Service Provider application. The Client Software is a platform independent interface allowing connection to the EDAS server over a TCP/IP connection. The Service Provider application is designed to receive, filter and forward the required EDAS data to the clients.
Specifically, the server component of the EDAS Interface connects to the EDAS server through a broadband Internet connection, obtains the EDAS messages in real-time from the EDAS server and processes them in order to provide the appropriate EDAS messages to the clients of the EDAS Interface.
The EDAS service required a registration and a static public IP address on the server side.
The Service Provider application is composed of a module in charge of connecting to the Client Software component through a TCP socket connection, receiving the EDAS data and performing the appropriate decoding in order to distinguish useful messages.
These required RTCM messages from the EDAS service level 2 are:
• Message type 1004 – GPS Observations (used in the DGPS algorithm)
• Message type 1005 – Stationary Antenna Reference Point of the RIMS (used in the DGPS algorithm)
• Message type 4085 subtype 0 – GPS/GLONASS/GEO Ephemeris (to have the EGNOS corrections)
The Service Provider handles the connections of the clients and forwards them, the filtered messages in the RTCM format.
EDAS client side
On the client side, the POSTO libraries include a module dedicated to the EDAS interface.
Here is its architecture:
Figure 5: EDAS module architecture
The EDAS package is composed of:
- A thread in charge of connecting to the server side and collecting the data.
- A set of classes to decode the RTCM messages
- A set of classes to store the data related to the RIMS and used for the local DGPS algorithm.
3.2.5.2 A-GPS INTERFACE MODULE
When the GPS receiver performs a cold start, it needs to download the GPS satellite ephemerides and almanac information in order to start providing useful data towards calculation of the PVT. Specifically, the receiver needs to continuously have a satellite in view for about 12 minutes in order to download the ephemerides and almanac information. The download time may be a lot bigger if the communication with the satellite gets interrupted and the process has to start again. In order to provide a fast time to first fix, an A-GPS server is used to provide the ephemerides and almanac satellite information over a network connection.
Figure 6: A-GPS Interface Module
The A-GPS Interface Module accelerates the calculation of position by delivering the following satellite data to the GPS/EGNOS receiver via the Internet:
• GPS satellite ephemeris
• GPS satellite almanac
• Accurate time
• GPS satellite status
The A-GPS Interface is implemented to retrieve the above data from uBlox’s A-GPS service which is compatible with all uBlox GPS receivers.
The A-GPS Interface Module features the following architecture:
Figure 7: A-GPS Interface Module architecture
The A-GPS Interface Module features a Client Software module which connects to uBlox’s A-GPS server, requests the respective A-GPS data and stores them to an internal queue. The data are then processed by the Message Handler module which checks their format and if they are compatible with the GPS receiver sends them to the GPS receiver through the Bluetooth Wrapper module.
3.2.6 POSTO API
The POSTO libraries expose an API which aims to provide a way to have EGNOS with integrity information on smartphones. To achieve that, the libraries need to have the raw data (pseudorange measurements, doppler…) from a GPS receiver. Since the built-in GPS receivers don’t provide that information, an external receiver is required. The POSTO API can use EDAS to improve the availability of EGNOS and can also use differential algorithm nearby a RIMS. Finally, it also integrates an experimental SW (called SIGNATURE) in order to support internal receivers, nevertheless in this case no integrity information can be provided.
The features of the API are listed below:
• Start/stop the computation.
• PVT computation with EGNOS (corrections and integrity) with GPS raw data from an external receiver.
• Positions received through callbacks.
• Connection to an EDAS Service Provider.
• Use the internal receiver (NMEA strings) to compute an EGNOS position (SIGNATURE tool) but without integrity information.
• Connection to an external receiver through Bluetooth connection to get the raw data.
• Status information about the computation and the connection to external components (external receiver, EDAS etc.).
• Configuration
o Select the source of the GPS data
internal GPS (SIGNATURE algorithm),
Bluetooth i.e. external uBlox receiver (GPS, EGNOS, DGPS algorithms),
File (uBlox record) for GPS, EGNOS and DGPS algorithms.
o Select the source of the EGNOS data:
Signal in space
EDAS (and configure the Service Provider to use).
o The status of the 3 EGNOS satellites (PRN 120, 124 and 126
Operational
Not used
Test
o The way the integrity is displayed (HPL or probability) and how to interpret it.
o Predefines settings based on the environment:
Aeronautic
Maritime
Rural
Urban.
o Advanced settings
Type of receiver
HDOP, low elevation and signal to noise ratio the parameters can be modified individually and predefined settings are proposed too)
Level of integrity (the parameters can be modified individually and predefined settings are proposed too)
Which positions to compute or to transfer to the application (it could be the four at the same time except if the built-in GPS receiver is used, then only the SIGNATURE position will be returned):
• GPS standalone
• EGNOS
• DGPS (nearby a RIMS)
• Ublox
The POSTO API allows to:
• Configure the library,
• Use a prerecorded receiver file to use as replay,
• Connect to the external receiver,
• Connect to the internal receiver,
• Connect to a network EGNOS messages provider,
• Get the positions as soon as they have been computed,
• Compute GPS standalone, EGNOS and Differential positions,
• Get some status about the internal execution of the library. Among others, it would inform about the connections with the external receiver or with EDAS, for instance.
3.2.7 POSTO SW LIBRARIES CONFIGURATIONS
In the POSTO software libraries, the configuration of the GPS sources of the data is the only mandatory parameter (all the other parameters can have default values). The GPS data can come from:
• External receiver: Bluetooth connection (GPS, EGNOS, DGPS algorithms, EDAS can be used but not required)
• Internal receiver: SIGNATURE algorithm (EDAS required)
• Recorded uBlox files: for replay (EDAS cannot be used with it)
The source of the EGNOS data can be configured too and in some cases, it is mandatory (SIGNATURE algorithm, for instance). The EGNOS data can come from:
• Signal in space
• EDAS (service provider to use)
The status of the three EGNOS satellites can be defined to:
• Operational
• In test
• Do not use
Two kind of integrity values can be defined:
• HPL: Horizontal Protection Level
• Percentage: It is the probability to be within a circle of the radius defined by the user.
It is also possible to define how to interpret the values of those parameters i.e. if the value is lower or higher than a threshold, it is good, bad or in the middle.
The library can output several kind of positions (for the same epoch, several positions can be returned, depending on the configuration). The choices are:
• GPS position
• EGNOS or SIGNATURE position
• Differential position: DGPS nearby a RIMS (EDAS required)
• External receiver position
The environment might have a big impact on the GPS accuracy. In rural area with few trees or sea area, there is a good visibility on the GPS constellation and EGNOS satellites and very few multi-path effects. One can expect a good accuracy and integrity. On the opposite, in urban area with high buildings, only a few satellites are visible at the same time and there are a lot of multi-paths. To work around those effects, it is possible to filter the “riskiest” satellites by checking the C/N0 or the mask angle. Indeed, a satellite with a low C/N0 means the reception of the signal is bad and so, inefficient. And a satellite very low on the horizon has more chance to get multi-paths. This reduces the number of satellites usable to compute the PVT and might hinder the algorithm to get a new position (at least 4 satellites are required to get a PVT). A bad position can be filtered by checking the HDOP value, since a high value means there is a bad geometry of the satellites in use, and the risk to have a wrong position is more important then. Thus, by adjusting those three parameters, the accuracy can be improved but the availability might decrease and vice-versa. A trade-off must be found depending on the application and on what it matters for the user.
The issue is to have a good accuracy with a good availability at the same time. By setting properly those parameters, a better integrity can be reached, too. Indeed, with a lot of multi-paths the integrity might be wrong. A trade-off between good accuracy/integrity and good continuity/availability must be found. The quality of the integrity can be managed with the integrity risk parameter. It is the probability to have a bad position and to not be informed.
In the frame of the POSTO project, predefined settings have been set for four environments:
• Aeronautic
• Maritime
• Rural
• Urban
The aeronautic environment requires the most accuracy and integrity and there are few constraints for GPS receiver with open sky most of the time. So in this kind of environment, the use of EDAS is not required because the EGNOS satellites will be visible most of the time. Moreover, the parameters to filter the GPS satellites don’t have to be too strict, because the risk of multipath effects or bad measurements is low.
The maritime and the rural areas are pretty close in terms of GPS constraints. Indeed, they are a kind of mixed environments with potentially a lot of masking like in harbours or on a river with trees (the trees can be a problem in rural areas too) and at the same time, the GPS receiver can be under an open sky most of the time. EDAS might be difficult to use too, because of the mobile networks coverage and maybe useless anyway, in case of open sky (as for the aeronautic environment).
The urban area is the most difficult one for the GPS receivers because of masking and multipath effects. It is not so easy to find the right settings for this environment. In this case, EDAS could help a lot to have EGNOS messages steadily.
Conclusion:
• Aeronautic: more accuracy and integrity, open sky, no need of EDAS, good measurements.
• Maritime: mixed environment, open sky offshore but masking and multipath in harbours or rivers (trees, bridges…), EDAS difficult to use because of network coverage.
• Rural: mixed environment, open sky but also masking and multipath because of trees or in villages, EDAS difficult to use because of network coverage.
• Urban: most difficult one, lot of masking and multipath, EDAS could help.
Thus, it is still possible to adapt each parameter individually, in the advanced settings:
• SNR (Signal Noise Ratio): to filter bad satellites
• HDOP (Horizontal Dilution of Precision): to filter bad positions
• Elevation mask angle: to filter bad satellites
• Integrity risk: to compute the HPL (Horizontal Protection Level)
• Receiver type: to define a way to handle bad measurements in the computation of the position and of the integrity. By the way, it depends also on the environment, the name of the parameter might not be appropriate in the frame of the POSTO project. For instance, with a high risk of bad measurements (high buildings density area for instance), the parameter should be put on “Low” and in open sky; it can be set on “High”.
3.2.8 MEANS FOR USAGE OF THE POSTO SW LIBRARIES IN APPLICATIONS
The POSTO libraries provide several solutions to get EGNOS on a smartphone or use derivative services from EGNOS, each one with its advantages and drawbacks:
Configuration mode Pro Cons
External receiver • Real EGNOS position and best result • The required equipment (external receiver, Bluetooth dongle, batteries, cables, antenna…)
Differential position • Precise position close to a RIMS • EDAS server required (data connection + EDAS service provider running)The required equipment (external receiver, Bluetooth dongle, batteries, cables, antenna…)It requires to be close to a RIMS (less than 20 kilometres)No integrityStill experimental, some of the RIMS send bad data.
Signature • Just the smartphone is needed • ExperimentalNo integrityEDAS server required (data connection + EDAS service provider running)
Table 1: Means for usage of the POSTO SW libraries (Pro/Cons)
Conclusion:
The only way to have a true EGNOS position on a smartphone, is to use an external receiver. In the POSTO library, the external receiver gives the best results. That’s why it is highly recommended to use an external receiver. But this solution has drawbacks, since it requires 2 external batteries, an uBlox evaluation kit and a Bluetooth/serial adapter. As a workaround, the SIGNATURE tool can be used, to have only the smartphone. But this solution has its drawbacks too, as the solution is pretty much experimental and it doesn’t provide integrity information.
To conclude, the external receiver is required to have a real EGNOS position and integrity. The SIGNATURE tool should be used as a second choice. The predefined settings are there to ease the configuration of the library and it is still possible to adjust the parameters manually.
3.3 POSTO APPLICATIONS
3.3.1 AGRIGEO APPLICATION
The Agrigeo application is an utility that allows the user to keep track of the Professional Measure Georeferenced (PMG). The user is able to order them in a catalogue, update and save them to the server. The user is able to download the PMG data from the server as well. The application allows the user to Georeferenced points of interest (PMGs) and associate additional meta-data with them such as text, audio and measurements performed from external devices. Finally the application uses the EGNOS libraries along with an external uBlox GPS receiver to determine the user’s position. The application communicates with the Agrigeo Server that provides all methods to retrieve PMGs catalogues and save them.
The following figure depicts the usage concept of the AgriGeo application.
Figure 8: AgriGeo application architecture
Figure 9: The Agrigeo application main screen
3.3.2 SITE HEALTH MONITORING APPLICATION
The Site Health Monitoring application (SHM) aims to assist users from several industrial sectors by enabling:
• High precision navigation in a restricted area with the combination of GPS/EGNOS positioning data and POSTO libraries,
• Configuration and display of a health monitoring road book (Points of Interest: POI to be monitored),
• Warning alarm when approaching a POI,
• Assistance for taking photos of the POI: photos of the POI taken periodically shall have the same format (ex: zoom level) so it can be compared to other photos,
• Storage of the photo for comparison over time and health monitoring,
• Transfer through 3G of the photo to a ground database,
• Addition of new POI when new degradation is reported.
Figure 10: Site Health Monitoring application functionalities
Login window Mission selection Map Mode
Figure 11: SHM application scheenshots
3.3.3 MOBILE LOCATOR TRACKING APPLICATION
The POSTO Mobile Locator application allows any Android device to act as a GTS-200 tracking device for the Mobile Locator monitoring solution. The application supports two of the three tracking modes of Mobile Locator (Location request and real-time) and communicates using SMS. Also, it uses the EGNOS SDK to communicate with a uBlox GPS/EGNOS receiver and provide the user’s position with increased accuracy.
Specifically, the POSTO Mobile Locator application features the following:
• It allows any Android 2.3 or later smartphone device to act as a tracking device of the Mobile Locator monitoring suite.
• It supports two modes of position tracking: On-request and real-time.
• It communicates with the monitoring application through SMS communication.
• It supports the usage of an external GPS receiver, through a Bluetooth connection, for the retrieval of position information.
• It uses the EGNOS SDK to retrieve EGNOS corrected position information and integrity indicators.
The Mobile Locator smartphone application has been developed from scratch and supports SMS communication and two tracking modes, location request and on-going. Also, it uses the POSTO Libraries to determine the user’s location and allows the configuration of which position to report, the GPS or the EGNOS calculated one.
Figure 12: Mobile Locator application architecture
Figure 13: Mobile Locator application main screen
3.3.4 HIKING APPLICATION
The Hiking application is an outdoor navigation, tracking and logging application ideal for hiking, biking, running, skiing, geocaching and other outdoor activities. The user can record, import and follow tracks. Also, he can take geo-tagged pictures and share collected information with his friends using popular social networks (as Facebook and Twitter). The application uses public available cartography (as OpenCycleMap) and allows the user to save map overlays a desired area and use them offline without network access. Finally, users are able to see in real time the measures of time, distance, space, speed and elevation of their track.
The main interface of the application is composed by a GPS strength indicator, a button to start tracking the trip of the user and a zoom control. The user is able to interact with the map with the standard smartphone gestures too (pinch, scroll, double tap).
Figure 14: Hiking Application Main Screen
3.3.5 ARBOWEBFOREST APPLICATION
ArboWebForest is a complete service for collecting, reviewing and publishing natural resource data. It removes the need for paper and pencil in the field and offers improved data collection, safe data storage, and excellent visualization and dissemination possibilities using Internet mapping.
The ArboWebForest smartphone application allows the collection of information about forest plots and uploads them to the ArboWebForest web application which is an easy-to-use web-based GIS application for data viewing and editing.
Field teams use the ArboWebForest application to collect forest inventory information around the world. They arrive at the predefined forest plot and determine its center using GPS coordinates. Then, they use conventional tools such as compasses and measurement tapes, to determine the edges of the plot using the project wide parameters of plot size. After the borders of the plot have been defined, the field team measures the canopy of the forest plot using densitometers. The measurements are completed by measuring the diameter of each tree that features a diameter above a predefined project wide diameter threshold and by measuring the height of a subset of them (e.g. the diameter is measured for each tree and the height for every fifth tree). Finally, all of the collected data are uploaded to the ArboWebForest server and are post-processed.
The existing ArboWebForest codebase has been expanded to use the POSTO libraries along with an uBlox external GPS/EGNOS Bluetooth receiver to determine the position. Also, the HMIs of the application have been adapted to allow the user to select the source of the position information.
Figure 15: ArboWebForest high level architecture
3.3.6 AUTOMOTIVE APPLICATION
The Automotive Application is part of the POSTO/VOS4ES/MODUS demonstrator that allows the demonstration of synergies between the POSTO, VOS4ES and MODUS projects by implementing an automotive platform, which enables the execution of safety critical real time and non-critical non-real time applications on top of the VOS4ES virtualization framework. A modified version of the POSTO Hiking application has been implemented and integrated with the VOS4ES virtualization framework as shown in the high level overview of the demonstrator in the Figure 16.
The Automotive demonstrator presents the potential usage of the POSTO results (POSTO SW Libraries and Hiking application) targeting the automotive sector in combination with VOS4ES virtualisation layer.
Figure 16: Automotive demonstrator high level architecture
Figure 17: Automotive Hiking Application
Potential Impact:
4.1 IMPACT
4.1.1 GNSS MARKET TRENDS
The GNSS market is the market of products and services using GNSS based positioning and navigation as a significant enabler.
The following six segments have been selected for this report:
• Road: PNDs and in-vehicle systems, supporting navigation and other ITS applications
• LBS: GNSS-enabled mobile phones and services
• Aviation: GNSS devices for commercial, regional, general and business aviation
• Agriculture: tractor guidance, Variable Rate Technology (VRT) and Automatic Steering
• Maritime: merchant fleet only and their GNSS applications in the open sea
• Surveying: land and hydrographic surveying
Figure 18: Global GNSS market size [2]
Core GNSS market includes only the parts of products’ retail value that are directly attributable to GNSS (1% in the case of GNSS enabled smartphones). It also includes service revenues directly attributable to GNSS.
Main GPS criteria for those applications are:
• Position accuracy: Expressed in a statistical way, assuming that the measurements follow a Gaussian model. Position accuracy is often given as the maximum distance from the actual position, within which the measured position fall for 95% of the cases (2σ).
• Integrity: Denotes the capacity to provide a position, together with a maximum error boundary HAL (Alarm Limit).
• Time To Alert: Maximum time within which a GNSS system shall warn the User when the HAL cannot be guaranteed.
• Availability: Percentage of time for which GNSS system can ensure a given HAL with a given integrity risk.
• Continuity: Probability of a GNSS system to meet its accuracy and integrity requirements over the next given period (say 150 seconds) knowing that these requirements are met at the beginning of the period.
Here bellow is an estimation of the market growth on the main market segments:
• LBS: LBS handset sales make up the majority of shipments (from 38 million in 2010 up to 170 in 2020)
• Road: Shipments are expected to reach over 50 million in 2020. Penetration will grow from 34% to almost 100%
• Aviation and maritime: Already highly penetrated and are expected to reach close to 100% by 2020
• Survey and agriculture: Steady growth : reaching approximately 60% and 40% respectively by 2020
By 2020, the percentage of all mobile devices in use that include GNSS capability is forecast to reach 67%. This growth is expected to slow down after 2020 as the markets in most regions of the world reach saturation.
These developments are driven by the increasing affordability of LBS devices and applications
• New applications such as mobile commerce, social networking and location based games are becoming widespread
• Rich content such as navigation road data is now free of charge at the point of use thereby opening up its usage to a much wider population of users
• Price erosion and reduced power consumption of GNSS chipsets thanks to closer integration and miniaturisation.
Figure 19: GNSS penetration in mobile phone [2]
The following section highlights the new market trends in each domain by providing some examples of new services based on GNSS.
• LBS market is mainly based on smartphone’s applications.
• Road market will be driven by 3 new types of services:
o Hybridisation for In Vehicle Device in order to improve availability of the positioning service (urban canyon, tunnels…)
o E-Call service: a 112 emergency call should be made automatically by the car as soon as on board sensors register a serious accident.
o Road tolling: many European countries are deploying new taxes based on GNSS positioning systems.
o ADAS: Advanced Driver Assistance Systems which encompasses services such as legal speed limit assistance, curve speed assistance and dangerous spot warning.
• Aviation market is based on EGNOS services and is driven by the entry into operation of certified approach with vertical guidance (APV-I). All new airplanes are now equipped with EGNOS or WAAS compliant positioning systems.
• Survey and agriculture applications require high accuracy and are the main customer of differential GPS service providers.
Based on all this information, we can conclude that GNSS market is still in a rapid grow period and should continue to grow until 2020 which is the estimated mature point for this market.
4.1.2 SMARTPHONES MARKET
The worldwide smartphone market grew 40.2% year over year in the third quarter of 2013 (3Q13), according to the International Data Corporation (IDC) Worldwide Quarterly Mobile Phone Tracker. Vendors shipped a total of 258.4 million smartphones in 3Q13, establishing a new record for units shipped in a single quarter by more than 9.0%. The previous high was 237.0 million units shipped in the second quarter of 2013.
Smartphones powered by the Android and iOS mobile operating systems accounted for more than eight out of ten smartphones shipped in the third quarter of 2012 (3Q12). According to the International Data Corporation (IDC) Worldwide Quarterly Mobile Phone Tracker, the mobile operating systems held shares of 74.9% and 14.4% respectively of the 186.7 million smartphones shipped in 3Q12. During the third quarter of 2013, the two operating systems held a combined share of 93.9%. The share gains mean that Android and iOS have successfully distanced themselves from previous market leaders Symbian and BlackBerry, as well as Linux and Windows Phone 7/Windows Mobile.
Table 3: Top Worldwide Smartphone Operating Systems Q3 2013 (Source: IDC)
4.1.3 POSITIONING APPLICATIONS FOR SMARTPHONES
The rapid growth of commercial applications for smartphones in recent years has surprised many industry observers and firms building positioning satellites and equipment. The differing needs of users and the availability of alternative solutions for meeting them have led to a highly diverse and competitive market for positioning technologies, equipment, and services. Currently in the market there are various applications running in smartphones, which are based on GNSS positioning including among others online social networking services, real-time tracking and tracing, navigation in rough outdoor conditions etc.
The development of smartphone applications has been increasingly spurred by Apple’s and Google’s platform concepts for application listing services. By Q1 of 2013, 900k applications were available on Apple’s App Store and 800k on Google’s Android Market (Google Play), as reported by mobilestatistics.com.
Figure 20: Total smartphone application available for difference OSs [source: mobilestatistics.com]
4.1.4 SMARTPHONE POSITIONING APPLICATION AREAS
The growing number of smartphones, technology convergence, mobile commerce, and location-based shopping are all expected to boost the positioning applications market worldwide. The driver of this growth is the widespread use of mobile mapping applications in the United States and Europe. GPS is a key component in many of the location-aware smartphone applications that have become so popular in recent times. Thus, the number of subscribers of GPS-enabled location-based services (LBS) is anticipated to grow substantially in near future, while it is projected that shipment of GPS/LBS devices will grow to reach around 1015 Million Units by 2015[1]. Additionally, an significant grow in the market size of LBS services is expected touching the mark of US$10.3 Billion by 2015.
The areas of location based applications vary and can be applied to different application sectors. Most applications are in the field of navigation, surveying, mapping, ground transportation, aviation and agriculture. Almost 74% of smartphone users enable location-based services to get real-time information, with 18% using the technology to "check in" to share their location with friends.
Figure 21: Global LBS Market Size (2010-2015)[3]
Transportation applications
Having some basic transportation applications installed in the smartphone could be used in-vehicle navigation systems for turn-by-turn directions e.g. CoPilot and Waze, traffic monitoring, fleet tracking & management solutions, e.g. IntelliTrak and Airwaves Fleet Management Software, freight movement monitoring (time-definite delivery), railway monitoring and collision avoidance systems etc.
Public-transportation applications are also available for many major cities and offer access to public-transportation maps using online maps.
Information applications
Information applications present points of interest around the user. Near-me applications present information about the user’s surroundings, real-time location tracking of other devices and notifications between the devices.
Health and Safety Applications
In case of a medical or family emergency, location-based applications can assist you in seeking appropriate help and care. Such can provide on-the-spot information about medical situations, conditions, and emergencies with access to emergency and instructions for scenarios such as choking, bites and stings, chest pains, and traumas. In addition, they can be used by families with phone-equipped children by receiving text-message notifications about a change in location, or previewing a child's location on Google Maps.
Agriculture applications
In the same concept, positioning applications can be used for precision farming, soil sampling, tractor guidance, sprayer aircraft navigation.
Surveying & Mapping applications
Positioning applications can also be used for the creation of new maps, mapping of various points of interest (oil pipelines, country borders, etc.) and checking irrigation needs in farmlands, through the use of infrared photography.
4.2 INNOVATION AND BENEFITS
The innovative aspects of the POSTO concept and approach can be summarised as follows:
• Supporting the development of EGNOS-based positioning applications for popular smartphone platforms with POSTO SW libraries: POSTO provides EGNOS SW libraries for the Android smartphone platform that would allow the use of EGNOS in smartphone positioning applications by SMEs or individual developers.
• Methodology and design guidelines for implementing EGNOS-based positioning applications in popular smartphone platforms: POSTO provides generic APIs for the EGNOS SW libraries, which allow their rapid integration on the target application as well as the retrieval of the corrected positioning information and the calculated integrity information.
• Pre-configured POSTO SW libraries for different operational environments: The POSTO SW libraries for smartphones includes advanced algorithms for the calculation of the corrected positioning information and integrity based on EGNOS for the different operational environments, thus different algorithmic configurations for each POSTO application in order to obtain the best performances.
• Provision of generic interface for accessing EDAS through smartphones: POSTO provides together with the EGNOS SW libraries, a generic fully configurable interface for accessing EDAS in order to allow applications running on smartphones to retrieve the appropriate data for feeding the correction and integrity algorithms with EGNOS data.
• Provision of EGNOS-enabled smartphone applications: POSTO project delivers a number of smartphone positioning applications that cover a wide range of needs including navigation, tracking and data collection for different application domains based on the SME’s existing application and applications that were developed from scratch within POSTO framework.
Based on the above innovation points, the benefits for the SMEs include but are not limited to:
• Rapid prototyping of positioning applications for smartphones, based on EGNOS. The POSTO SW libraries for smartphone platforms allow embedding EGNOS (in Europe) functionality in smartphone positioning applications without becoming an expert in this domain.
• Reduce time to market and development costs in smartphone applications that use EGNOS. The POSTO SW libraries allow for developing GNSS positioning applications or enhancing existing ones without requiring to become an expert in this domain, since significant know-how and effort is required. Thus time to market and development costs of new or upgraded positioning applications is radically reduced.
• Gain the know-how for exploiting integrity in smartphone positioning applications.
• Be competitive by enhancing existing positioning applications for smartphones with higher position accuracy and integrity provided by EGNOS.
• Be competitive by providing innovative applications for smartphones that exploit the full potential of confidence in positioning information (integrity) provided by the EGNOS technology.
• Allow the provision of positioning applications for smartphones based on EGNOS, targeting at least the 80% of the smartphone continuous growing market by supporting Android smartphone platform.
• Allow providing applications through existing popular applications stores (e.g. Android’s Google Play Market etc.).
• Target LBS, which is the main driver of the GNSS market and particularly the downstream value chain (a prediction is that the market size will reach 236 billion in 2025).
• Be ready to provide GALILEO based positioning applications in the near future.
4.3 SWOT ANALYSIS
The following table provides the Strengths, Weaknesses, Opportunities and Threats (SWOT) analysis of the POSTO project.
Strengths Weaknesses
• Experimentation with position accuracy and integrity in diverse application areas and in different operational environments based on the developed POSTO applications.
• Rapid implementation of smartphone positioning applications based on EGNOS using POSTO SW libraries.
• Easy adaptation of existing positioning smartphone applications based on GPS-only receivers to EGNOS- enabled applications.
• Provision of generic interface for accessing EDAS in the smartphone applications by public internet.
• Enhancing existing positioning applications for smartphones with higher position accuracy and integrity provided by EGNOS.
• Gain the know-how in providing position accuracy and integrity information adapted to each kind of positioning applications.
• EGNOS-enabled positioning applications for smartphones including navigation, tracking and data collection for different application domains. • Low performance in indoor environments.Access to the raw data of the antenna receiver is needed to guaranty best performances (usage of external receiver).EGNOS SW libraries are not possible for all smartphones due to the different platforms, SDKs and programming languages.Network latency and server load may make the external data unusable for real-time positioning applications (e.g. navigation).Low performance of the SIGNATURE configuration (EGNOS solution using built-in GPS) because we do not have access to the GPS raw data.
Opportunities Threats
• Reduce time to market and development costs.
• Better position in the continuous growing GNSS market of positioning applications for smartphones.Key enabler for differentiation (EGNOS integrity concept).Be prepared to provide GNSS applications at the time that GALILEO will be operational.Convince Smartphone’s manufacturers to provide a GPS API giving access to the GPS raw data. • New technology for smartphones applications.Compatibility of EGNOS integrity concept with future GALILEO system.Compatibility of EGNOS integrity concept with future BEIDOU system (China).
4.4 DISSEMINATION
The dissemination activities performed during the project course, are listed below:
- Maintained the POSTO website, available at www.posto-project.eu and performed continuous updates.
- Maintained the POSTO WIKI, available at www.posto-project.eu/wiki/
- Prepared the POSTO brochure.
- Prepared POSTO project video and made available over the public Internet through the POSTO web site and YouTube (www.youtube.com) popular video sharing platform.
- Presented POSTO activities and results in scientific conferences and workshops including
-- Presented POSTO activities in 2 workshops held in Athens (for MODUS project) and Cyprus (for the OPEN-SME project)
-- Presented the roadmap of ArboWebForest Mobile Client POSTO application and related activities to FAO at Rome on April 26 - 30, 2012
-- Presented POSTO activities to GALILEO Services Formal meeting on December 2012 in London, UK.
-- Presented POSTO activities in the event «Digital Skills and Competitiveness» on January 2013 in Warsaw, Poland.
-- Dissemination of POSTO brochures in the ICT2012 Proposers Day in Warsaw on 26-27/9/2012.
- Planned activities on presentation POSTO results including
-- Presentation of POSTO activities to GNSS association on February 2014 in Bordeaux France
-- Presentation of POSTO activities to Agriculture Chamber on February 2014 in Dax, France
- Book article of POSTO AgriGeo application in Revue Agricole, February 2014.
- Organised the POSTO 1st workshop within the Toulouse Space Show 2012.
- Organised the Joined POSTO-MODUS workshop in Athens on 04th of October 2013
- Planned the POSTO 2nd workshop in parallel with ERTS 2014 conference in Toulouse, France, on 5th - 7th of February 2014.
- Establishment and maintenance of the POSTO Special Interest Group (SIG).
- Liaison with other projects (MODUS, VOS4ES, GAPFILLER, WalkEGNOS, SIGNATURE).
4.5 EXPLOITATION
POSTO provides the methodology and software libraries required for the design and development of GALILEO/EGNOS-based mobile positioning applications, targeting SMEs who are seeking to develop positioning applications for smartphones or planning to enter this continuous evolving market by exploiting the full potential of the GALILEO/EGNOS benefits. The SMEs involved in the project are already active in the market of positioning applications and the smartphone applications sector, with established product lines and constantly struggling to improve services and products and growing their market shares.
The results of the POSTO approach facilitate the SMEs need to adopt new pioneering positioning applications for smartphones, with state-of-the-art technologies fast and efficiently, as in the case of augmentation systems such as EGNOS and future GALILEO for higher position accuracy and integrity of position information. The POSTO outcomes will bring new business opportunities and increase the competitiveness of the SMEs in the international market.
Considering the above, the exploitation strategy of the POSTO results on behalf of the POSTO SMEs, namely HELILEO, EKITO, TRACKER, GNOMON, ARBONAUT and MILTECH includes:
• Exploitation of the configurations of the POSTO SW libraries according to the specificities of each SME application.
• Experimentation and development of EGNOS aware extensions of SMEs’ positioning applications based on the POSTO SW libraries.
The methodology and design guidelines for implementing EGNOS-based positioning applications in popular smartphone platforms, e.g. Android, are publicly available through the POSTO website and relevant publications. This allows the implementation by third-parties, e.g. individual developers, companies, organisations etc., interested in the POSTO technology for developing GNSS positioning applications for smartphones with higher accuracy and monitoring of integrity with the integration of EGNOS correction and integrity monitoring algorithms for diverse application areas including telecoms, assistive living, animal and person tracking, transport, maritime and monitoring of traffic.
The exploitable results can be summarised in the smartphone applications that were adapted / implemented to validate the POSTO SW libraries. These applications include a hiking application, a forest inventory application, an automotive application, a people tracking application, a site health monitoring application and an application targeting the agricultural market, listed in Table 2.
SME Name SME Application
HELILEO AgriGeo application
EKITO Site Health Monitoring application
TRACKER Mobile Locator tracking application
GNOMON Hiking application
ARBONAUT ArboWebForest application
MILTECH Automotive application
Table 2: Exploitable EGNOS aware smartphone applications based on POSTO libraries
Finally, the RTD Performers, namely TELETEL, M3 SYSTEMS and HANDCRAFTED SOFTWARE, will provide maintenance and support services to the SMEs for 2 years after the end of the project, free of charge. Beyond that period, the RTD Performers might be assigned by the SME the upgrade and the evolutive maintenance of the POSTO SW libraries under special financial agreements
List of Websites:
www.posto-project.eu