Call for Proposals for Development of an Advanced RAIM Multi-constellation Receiver (ARAIM) - GSA/GRANT/01/2017

Deadline: May 15, 2017  
CALL EXPIRED

1. CONTEXT

1.1. Introduction

The mission of the European GNSS Agency (GSA) is to support European Union objectives and achieve the highest return on the European GNSS (E-GNSS) investment represented by the EGNOS and Galileo programmes, in terms of benefits to users and economic growth and competitiveness.

EGNOS is the European satellite-based augmentation system (SBAS) that is operational since October 2009 and will continue to provide its services for GPS augmentation and in the future for Galileo. Its open signal is free of charge and the service availability reaches 99% for the total of the EU coverage. EGNOS is able to enhance GNSS performance by offering an increased accuracy and reliability on the positioning. Since 2015 the EGNOS Safety of Life (SoL) service also includes LPV-200 service level, able to provide lateral and vertical guidance without the need for visual contact with the ground until a Decision Height/Altitude (DH/DA) of down to only 200 ft. above the runway, resulting in a better access to airports and in the reduction of delays, diversions and cancellations.

Galileo is a global navigation system under deployment in Europe. It is a civil system under civil control, intended to provide navigation services to users, including guaranteed services for specific user communities. Initial Services are based on a number of satellites placed in orbit that can be used in combination with GPS satellites. Already at this stage the user will be able to exploit a significant improvement in terms of signal availability, especially in harsh environments, as in urban canyons, where chances to receive signals from GNSS satellites are limited due to the restricted visibility of the sky. Galileo will provide precise, reliable and robust open service, enabling other desirable properties such as better resistance against multipath. In addition, Galileo is planned to provide Authentication over its Open and Commercial Services, a feature which is unique among the various GNSS providers. This will allow to assess the authenticity of the data provided through the signal in space against attempts to spoof it and will contribute to improve the robustness of GNSS for applications in which safety/security is concerned.

Integrity is one of the essential qualities of service to be provided to the users of Safety of Life applications. Advanced Receiver Autonomous Integrity Monitoring (ARAIM) is a concept to which much effort is being devoted with the intention to provide a global integrity service based on multiple satellite constellations. Galileo can substantially contribute to ARAIM. In this respect, cooperation with the United States of America was formally established through the creation of a specific EU-US ARAIM Technical Sub-Group (TSG) in Working Group C of the EU-US cooperation agreement. The ARAIM TSG has been established on July 1, 2010 and has been developing the concept with a focus on Civil Aviation, including possible architectures for its implementation as well as the reference user algorithm to be implemented at airborne receiver’s level which can lead to service provision based at least on the GPS plus Galileo constellations. The ARAIM TSG has produced several Reports with its findings which are publicly available (3 until now, see [RD.1], [RD.2] and [RD.3]).

The ARAIM TSG was given the task to develop a solution to ensure navigation integrity for en-route flight, terminal, and approach operations, which should support lateral and vertical guidance down to a Decision Height/Altitude (DH/DA) as low as 200 feet height above touchdown, as required per LPV-200 (Localiser Performance with Vertical guidance with DA/DH equal to 200 feet).

ARAIM has been developed to further extend the integrity concept used in SBAS but features different characteristics compared to current SBAS such as:

 Use of the dual-frequency ionosphere-free pseudo-range combination,

  NOT use of differential corrections (except for the Online ARAIM, see description below),

  Possible use of all GNSS constellations, providing a reliable and proven Integrity Support Message (ISM), and

  Timing constraints (i.e. time to alert) demanded to the receiver’s algorithm instead of to a ground segment facility.

Two constellations and dual-frequency are required to meet minimum availability requirements globally for LPV-200 using ARAIM, therefore the availability of both Galileo and GPS constellation and a receiver able to process their broadcasted signal in the space (SIS) is at the basis of the implementation of the ARAIM concept.

Even if they have many similarities ARAIM offers a number of functionalities that complement SBAS both in the near-term and in the long-term, such as:

•   Horizontal ARAIM in the Near Term Based on One Frequency, enabling dual or multiple constellation navigation based on one frequency, before dual frequency GPS (L1-L5) and dual frequency Galileo will reach their Full Operational Capabilities.

•   Arctic Navigation, requiring integrity value to support increasing demand (energy exploration, eco- tourism and shipping, also enabling travel in existing ice cracks) in areas where there is no coverage by geostationary satellites;

•   GNSS resilience: since integrity is either broadcast through GNSS signals, stored in the receiver itself or disseminated through aviation databases, ARAIM does not suffer from signal outages associated with the geostationary geometry. Indeed geostationary satellites’ signals are frequently received under low elevation angles which are subject to blockage by terrain or buildings, and intentional or non-intentional radio frequency interference.

Furthermore the integrity provision through core constellations could in future obviate or reduce the need for geostationary satellites used by SBAS. This would reduce the needed amount of ground architecture elements and could also imply the reuse of SBAS reference stations for ARAIM monitoring, resulting in a faster ARAIM deployment1.

The ARAIM concept is based on three possible architectures2 enabling different level of performance:

•   Horizontal ARAIM, to support horizontal navigation based on an occasional Integrity Support Message (ISM) updates.

•   Offline ARAIM, to support horizontal and vertical navigation based on a monthly Integrity Support Message (ISM) updates.

•   Online ARAIM, to support horizontal and vertical navigation based on an Integrity Support Message (ISM) frequently3 updates.

   

Horizontal ARAIM is similar to traditional RAIM, but has the provision to input new integrity parameters which are instead hardcoded in current RAIM GPS receivers. This capability will provide the users with information about large changes in the core constellation. It allows the allocation of uncertainties dependent on the actual status of each specific constellation, providing the architecture with the ability to adapt to actual performances by the constellations as they change (e.g. reporting the user with improved confidence in the ranging accuracy or a priori failure probabilities as the constellation matures).

Furthermore it introduces the use of dual frequency (L1 and L5) signals mitigating the effect of ionospheric uncertainty and the impact of radio frequency interference located on a specific band, by reverting to L1- only or L5-only operation (in exchange for reduced performance). It also utilises multiple constellations to reduce sensitivity to the strength of any individual constellation. This will obviate the RAIM outages currently experienced by aviation receivers since it is based on multi-constellation multi-frequency satellite navigation.

[RD.1], [RD.2] and [RD.3] analyse the feasibility to meet specific operational needs through the implementation of the ARAIM concept, as a function of the constellation strength (depleted, baseline, and optimistic) and the a priori failure probabilities.

Figure 1 illustrates the Horizontal ARAIM architecture, based on a multi-constellation space segment, a number of reference stations monitoring the Signal-In-Space (SIS) and supporting the computation and delivery of the Integrity Support Message (ISM).

Figure 1 - Horizontal ARAIM [RD.3]

Offline ARAIM is designed to support to support both horizontal and vertical navigation. It includes a link from the ground to the avionics to adapt to a changing signal environment. However the architecture does not aim at following short-term variations in constellation status or performance, therefore the user is provided with an Integrity Support Message (ISM) whose update is very modest (monthly updates are sufficient). Instead the parameters are conservatively chosen to cover short-term performance variations.

The link from the Offline ground segment to the airborne fleet may be a suitable wireless link (e.g. core constellations or geostationary satellite’s SIS, or terrestrial radio), or a database updated on a monthly basis.

Figure 2 shows the Offline ARAIM architecture which is very sensitive to the user range accuracies (URAs) that are contained within the navigation messages from the core constellations. These need to be consistent with published CSP performance commitments and verified by service history, therefore new constellation may be not able to initially achieve the needed level of URA performance. Thus Offline ARAIM is subject to availability risk.

Figure 2 - Offline ARAIM [RD.3]
Online ARAIM is designed to mitigate the availability risk through the implementation of a ground segment

able to:

1. Reduce the user range accuracy with respect to the URAs broadcast by the core constellations: the system estimates and replaces the ephemeris and clock information, by using trusted hardware and software. The ephemeris and clock corrections must be generated frequently enough to improve the URAs;

2. Timely detect and flag faulty satellites reducing the exposure time to failures.

The Online ARAIM approach is similar to the SBAS, however the six second time to alert associated with

LPV-200 and LPV-250 is completely demanded to the user algorithm.

[RD.1], [RD.2] and [RD.3] describe the performance reachable through the implementation of this architecture, as a function of the constellation strength (depleted, baseline, and optimistic) and the User Range Accuracy, under certain assumption in terms of a priori failure probabilities.

Since the aircraft must receive and apply the ISM content shortly before conducting an approach operation to use satellite navigation for vertical guidance, it is subject to connectivity risk.

Online ARAIM architecture is depicted in Figure 3.

Based on [RD.3], ARAIM services should be implemented incrementally, beginning with a horizontal only service, H-ARAIM, to support near-term, multi-constellation (MC) applications. A global vertical service (Offline and Online) can be implemented in a later stage, once sufficient experience is gained to demonstrate safe operations and to assess the monitoring capabilities necessary for the V-ARAIM.

In order to provide the above services, the corresponding Standards must be developed and validated. Activities are already starting to incoporate H-ARAIM into the future dual-frequency, multi-constellation (DFMC) SBAS Minimum Operational Performance Standards (MOPS) under development at the responsible organisations (such as EUROCAE). Similarly the Operational concept (CONOPS) will have to be as well developed and validated by ICAO.

All the above lead to the need of developing an ARAIM prototype implementing the ARAIM user algorithm, enabling global Horizontal and Vertical navigation for Civil Aviation.

At the end of the project, the prototype receiver shall be mature enough to allow the performance assessment in a number of Safety critical applications in aviation (both Horizontal and Vertical guidance).

It shall support the consolidation of the ARAIM algorithm, the characterisation of performance and shall contribute to validate the ARAIM concept against representative Safety of Life operations. In particular, this prototype shall guarantee enough flexibility to enable the analysis of the ARAIM error characterisation, its impact on performances and to accommodate changes and/or adjustments resulting from the project itself or from other related initiatives, as specified in section 2.2.

Furthermore, results obtained within the project can provide elements contributing to the development of the standards mentioned above.

1.2. Other initiatives in the ARAIM roadmap

The following initiatives, as well as any other project considered relevant for the scope of this action, shall be taken into account by the applicants while preparing the proposals, and by the beneficiary while executing the project:

 R&D FOR ADVANCED RECEIVER AUTONOMOUS INTEGRITY MONITORING: ARAIM DEMONSTRATOR – [RD.4]: the purpose of this project is to develop an ARAIM Demonstrator and to conduct the necessary tests, including tests with real Galileo Signal In Space (SIS) – as well as other constellations – that will serve as proof of concept for ARAIM and that will serve to clarify the open questions related to its implementation. Based on the achieved results, specific recommendations which can be accepted by the international community for the implementation of ARAIM shall be then proposed. The ARAIM Demonstrator (ADAM) project was kicked-off in September 2016.

 AVIATION STANDARDISATION FOR MULTICONSTELLATION (ATLAS): the project aims to support the introduction of Galileo and modernised version of EGNOS in the civil aviation sector in the context of new multiconstellation services recommended by the International Civil Aviation Organization (ICAO). The activities will consist in delivering draft technical standards for implementation of multiconstellation/dual frequency and of next generation SBAS as well as of Advanced RAIM techniques, as aviation receiver standards are currently published for GPS stand-alone and GPS/SBAS equipment. Standard deliverables generated are:

 Galileo stand-alone receiver MOPS (final version)
 Galileo/GPS receiver MOPS (final version)
 Combined Galileo/GPS L1/L5 SBAS MOPS
 ICAO SARPs for Galileo Open Service and Galileo SARPs Validation File  ICAO SARPs for next generation SBAS

 AVIATION DFMC SBAS RECEIVER PROTOTYPE – [RD.5]: The purpose of the project is to design, develop and test a prototype of the DFMC SBAS (Dual Frequency Multi-Constellation Satellite Based Augmentation System) user terminal for the aviation SoL service, augmenting GPS and Galileo capabilities. The developed receiver, besides the SBAS DFMC functions (for GPS and Galileo), shall also include Horizontal-ARAIM (Advanced Receiver Autonomous Integrity Monitoring) and RAIM (Receiver Autonomous Integrity Monitoring). The implementation of Horizontal-ARAIM, and the assumptions for the Vertical-ARAIM (only taken into account for the purpose of dimensioning the computational resources of the prototype receiver), are based on the current state of standardisation of this feature.

Based on the above identified projects, the applicant shall propose a project plan aiming at maximising the effectiveness of the results of the project (see IMPORTANT NOTE (1) in section 2.2) and allowing for the interaction with the above – or any other relevant – projects. In this regard, to be noted that the information about the progress of the relevant projects will be provided by GSA/EC to the beneficiary along the project.

1.3. Background of the call

This call is based on the Delegation Agreement concluded between the European Union, represented by the European Commission, and the European GNSS Agency (GSA) on the Exploitation Phase of the Galileo Programme signed on 2 October 2014.

In this framework, and in accordance with the Galileo Grants Plan for 2016 published on the GSA website (http://www.gsa.europa.eu/gsa/grants), the GSA is launching a call for proposals to increase Galileo adoption in aviation receivers.

2. OBJECTIVES AND SCOPE OF THE CALL

2.1. Objective of the call for proposals

This Call for Proposal aims to achieve the following objectives (for each grant):

1. (1)  to develop, test and assess the performance of an Advanced RAIM (Receiver Autonomous Integrity Monitoring) receiver’s prototype, following the guidelines defined by the ARAIM TSG (Technical Sub Group).

2. (2)  to characterise, consolidate and validate the local effects of the threat model as specified by the ARAIM TSG.

3. (3)  tocontributetothestandardisationactivitiesonARAIM.

2.2. Scope and areas of activities of the call for proposals

In line with the ARAIM roadmap defined in [RD.3], this call has the objective to fund specific activities to develop an ARAIM receiver’s prototype aiming to consolidate the user algorithm, assess and validate the performance of the ARAIM concept, liaising with the concurrent development of the ARAIM demonstrator (specified in [RD.4]) and other projects quoted in section 1.2.

The receiver’s baseline used to develop the ARAIM prototype shall at least feature dual constellation (Galileo and GPS) and dual frequency, with current state of the art SBAS capability.

In order to reach the objectives of this call, beneficiaries are expected to conduct the following activities within the scope of this call.

Task 1:

The first task of the project aims at defining the requirements and implementing the first version of the ARAIM receiver’s prototype. It also includes the consolidation and approval of a performance validation plan.

The beneficiary shall define all the receiver’s requirements (including functional, safety and performance) against which the design, development and testing activities will be carried out, based on the following considerations and technical constraints:

 The ARAIM algorithm, which has to be implemented, shall be based on the last available updated reference algorithm defined by the ARAIM Technical Subgroup in WG C, being it the reference algorithm defined in [RD.3] or a more recent version, if made available during the development of the prototype.

Beneficiary may in addition propose alternative or evolution versions of the reference algorithm. However those shall in any case result either in equivalent (or better) performance or in a significant computational complexity reduction providing comparable performance;

  The prototype receiver shall be able to support the following two ISM dissemination means, given that the options are still open:

1. 1)  Integrity Support Message (ISM) dissemination through Signal in Space (either GNSS core constellations or geostationary satellite’s SiS).

2. 2)  Integrity Support Message (ISM) update through one of the databases in the airplane which are regularly updated. For this, the beneficiary should first perform a trade-off analysis of various options (considering the need for interfaces and corresponding failure modes), to be later decided which option to implement, based on the analysis.

  Even though the Concept of Operations (ConOps) is not yet defined and is to be developed at ICAO, the beneficiary shall propose some operational requirements on which the prototype design shall be based, such as the option to de/select the constellation(s) and the frequency(ies), the option to switch between ARAIM and SBAS and switching modes based on algorithm computational burden (e.g. Online to Offline ARAIM in case of depleted constellation).

  The design approach shall aim at obtaining:

1. 1)  an incremental and flexible architecture supporting the performance assessment of the user

   algorithm under all the three ARAIM architectures (Horizontal, Offline and Online).

2. 2)  a flexible architecture able to accommodate potential changes/adjustments (e.g. in terms of ISM format, algorithm optimisation and further updates, ConOps developed at ICAO, error model, etc.).

3. 3)  a modular architecture that would facilitate interoperability, integration, test and validation.

  The prototype shall be able to operate as a minimum in the following modes:

1. Galileo and GPS modeforH-ARAIM
2. Galileo and GPS modeforV-ARAIM
3. Galileo-only and GPS-only mode for H-ARAIM;

 The
analysis (as specified in the text below);

receiver shall also implement the single-frequency GPS-only RAIM, to perform benchmarking

The beneficiary is also requested to perform a preliminary safety assessment, to identify all safety requirements (including the adequate Design Assurance Level (DAL)/Software Assurance Level (SWAL) levels) and to identify all the necessary activities and relevant associated documentation in support of the safety case.

The beneficiary shall present all the consolidated requirements (including functional, safety and performance) together with the preliminary design option in a Preliminary Design Review (PDR), to demonstrate that it meets the identified requirements, that all the components have been considered and that the verification methods have been properly identified.

The design of the receiver and its components shall take into consideration the following aspects:

 The beneficiary shall base the design, as much as possible, on already existing hardware. Minor hardware adaptations (if any) shall be justified in the proposal;

 The design of a dedicated antenna is out of scope for this project;

Upon successful completion of the PDR the detailed design shall be initiated.

The design shall implement, during the action, the flexibility required to adapt the architecture to potential changes resulting from the development of the ARAIM Demonstrator [RD.4], the operational concept developed at ICAO, the definition of an updated version of the reference algorithm and from the receiver’s performance assessment.

The beneficiary shall assess the final receiver’s architecture and refine the test and validation specifications and plan before the Critical Design Review (CDR), which shall demonstrate that the design is mature enough to support the development and test phases.

Upon successful completion of the CDR the beneficiary shall proceed to develop the first version of the ARAIM receiver’s prototype.

As last step of Task 1, the beneficiary shall define and consolidate a performance validation plan (deliverable (8)) detailing the test campaign aiming at the validation of the receiver’s performance, by using theoretical models and simulated scenarios first (in-lab validation) and representative scenarios at a later stage (real GNSS signal validation). In that respect the beneficiary shall prepare a number of test scenarios to validate the ARAIM receiver against the Safety of Life (SoL) needs, in support of the following target operations:

 Horizontal ARAIM: the ARAIM receiver shall be assessed against the requirements defined for lateral navigation (RNP 0.1 and RNP 0.3).

 Vertical ARAIM: the ARAIM receiver shall be assessed against the requirements defined for lateral and vertical navigation, namely the requirements for approach procedures (LPV-200 and LPV-250).

The performance of the integrity concept algorithms shall be evaluated in terms of integrity, availability, and continuity against a full set of representative conditions. The tests shall also aim at identifying and assessing the vulnerabilities of the approach, in terms of availability risk and of connectivity risk, depending on the underlying ARAIM architecture (Offline and Online, respectively) under nominal and degraded conditions.

Furthermore the plan shall also include a section devoted to GPS-only RAIM testing aiming at comparing the performance achievable by ARAIM with the one achievable by RAIM under the same conditions, in the scope of both the in-lab and the real GNSS signal validation.

IMPORTANT NOTE (1): The applicants are requested to include already in their proposals (see deliverables (2) and (8)) a preliminary list of requirements for the prototype and a preliminary version of the plan describing how they propose to verify the compliance of the prototype with the target operational requirements (i.e. LPV-200, LPV-250, RNP 0.1 and RNP 0.3).

In this regard the applicant is also expected to analyse the ARAIM roadmap defined in [RD.3] and the inter-dependencies with the concurrent relevant initiatives listed in section 1.2 to propose a suitable validation approach and related planning. The proposed approach shall aim at the maximisation of the representativeness of the scenarios used for the ARAIM receiver validation.

The preliminary plan shall be evaluated against the award criteria (see section 10).

Task 2:

The second task of the project aims at assessing the achievable performance of the implemented receiver’s prototype.

Due to the conceptual differences between ARAIM and SBAS (such as the level and content of the broadcast information, single- vs. multi-frequency, single- vs. multi-constellation, ground vs. user segment based alerting service, etc.), the error characterisation applicable for ARAIM might differ from the one defined for SBAS. The preliminary characterisation of the nominal errors involved in the algorithm is specified in [RD.1], [RD.2] and [RD.3]: residual tropospheric error, code noise, multipath and the effect of the nominal signal in space error (which includes the nominal clock and ephemeris error, antenna bias, inter-frequency bias, code-carrier incoherence and the nominal signal deformation). It depends on the specific architecture (e.g. the Online ARAIM shall also provide ephemeris and clock corrections), also includes the threats resulting from the Integrity Support Message (ISM) dissemination and also the effect of ionospheric delay error has to be modelled to support the single frequency case (based on the Galileo Ionospheric Model).

Only local errors depend on the receiver, therefore the beneficiary shall focus on the specific local effects (i.e. receiver noise and multipath) which are also dependent on a number of scenario’s conditions such as the target aircraft, the local environment, the specific GNSS receiver’s noise, the operational scenario, etc. The outcome of the analysis shall be (for each scenario, if needed) a conservative threat model used for integrity purposes and a less conservative model used to define the accuracy.

The ARAIM threat characterisation, in terms of error models, together with the single (Psat) and wide (Pconst) fault probabilities, shall be used as design parameter for the ARAIM algorithm, which will calculate the All- in-view position, the Fault tolerant position, the Protection levels (VPL – Vertical Protection Level and HPL – Horizontal Protection Level) and the EMT (Effective Monitor Threshold, where needed) to evaluate the Integrity of the solution.

Once the error model has been characterised, the beneficiary shall launch the test campaign in accordance with the approved validation plan (see deliverable (8)).

IMPORTANT NOTE (2): A preliminary description of the proposed methodology to consolidate the characterisation of the ARAIM local errors shall be also submitted in the proposal (see deliverable (7)) and evaluated against the award criteria (see section 10).

IMPORTANT NOTE (3): The beneficiary may decide to initially assess the receiver’s performance based on an already existing threat model and in a later stage re-test the receiver having identified a more suitable

model. In any case the two activities (threat model characterisation and performance assessment) shall result in a reiterative process aiming at identifying the best model and assessing related achievable performance in compliance with the operational requirements, as described in Figure 4.

(TRUNCATED -- please visit the public link for full proposal)