Final Report - European GNSS Agency · Final Report Code: IADIRA-DME-FRD-001 Date : 30/11/06 Issue : 1.1 Page : 3 This document is property of DEIMOS Engenharia and cannot be distributed

IADIRA Final Report

Code: IADIRA-DME-FRD-001Date : 30/11/06Issue : 1.1Page : 1

This document is property of DEIMOS Engenharia and cannot be distributed or duplicated without its written permission.

Inertial Aiding - Deeply Integrated Receiver Architecture

IADIRA

Propagation Channel

Inertial Measurement Unit (IMU)

Galileo-INSCombination Algorithms

Galileo Transmitter

Galileo Receiver

Dynamic parameters

PR, CF, Doppler

IMU Calibration States

Estimated Doppler

PVT Solution

IInneerrttiiaall AAiiddiinngg –– DDeeeeppllyy IInntteeggrraatteedd RReecceeiivveerr AArrcchhiitteeccttuurree IIAADDIIRRAA

FFiinnaall RReeppoorrtt

GGAALLIILLEEOO RReesseeaarrcchh aanndd DDeevveellooppmmeenntt AAccttiivviittiieess SSeeccoonndd CCaallll AArreeaa 33:: IInnnnoovvaattiioonn bbyy SSmmaallll aanndd MMeeddiiuumm EEnntteerrpprriisseess

Reference: IADIRA-DME-FRD-001

Issue: 1.1

Date: 30/11/06

IADIRA Final Report



Intentionally left blank

IADIRA Final Report



DDooccuummeenntt IInnffoorrmmaattiioonn

Name Function Signature

Prepared by: Project Team

Checked by: Pedro Freire da Silva (DME) Project Deputy Manager

Approved by: Augusto Caramagno (DME) Project Manager

Contract Data Classification

Contract Number: G2C_A3-DME-PRO-001 Public domain (PU)

Restricted to Galileo Partners (PP)

Restricted to Other partners (RE)

Contract Issuer: Galileo Joint Undertaking

Confidential (CO)

External Distribution

Name Organisation Copies

Project Team Institute of Geomatics 1 Project Consultants DEIMOS Space

Vincent Gabaglio, Eric.Guyader Galileo Joint Undertaking 1

Dr. Jan Skaloud Swiss Federal Institute of Technology

1

Archiving

Word Processor: MS Word 2000

File Name: IADIRA-DME-FRD-001-11

IADIRA Final Report



DDooccuummeenntt SSttaattuuss LLoogg

Issue Change description Date Approved

1.0 First issue for Final Review 16/10/06

1.1 Summarised version. Updated according to reviewer’s comments.

30/11/06

IADIRA Final Report



Table of Contents

1. INTRODUCTION_____________________________________________________________ 1-11 1.1. Purpose ______________________________________________________________________ 1-11 1.2. Project Objectives _____________________________________________________________ 1-11 1.3. Document Overview____________________________________________________________ 1-12 1.4. Acronyms and Abbreviations ____________________________________________________ 1-13 1.5. Related Documents ____________________________________________________________ 1-15

1.5.1. Applicable Documents _______________________________________________________ 1-15 1.5.2. Reference Documents ________________________________________________________ 1-15

2. INERTIAL AIDING AND COASTING ___________________________________________ 2-17 2.1. Galileo Combined Services ______________________________________________________ 2-17 2.2. Hybridisation concept overview __________________________________________________ 2-18

2.2.1. Inertial Aiding ______________________________________________________________ 2-20 2.2.1.1. Integration Level 1 _______________________________________________________ 2-20 2.2.1.2. Integration Level 2 _______________________________________________________ 2-20 2.2.1.3. Integration Level 3 _______________________________________________________ 2-21 2.2.1.4. Integration Levels 4 and 5 _________________________________________________ 2-21

2.2.2. IADIRA General Requirements ________________________________________________ 2-22 3. TARGET APPLICATION SELECTION__________________________________________ 3-23

3.1. Application Selection ___________________________________________________________ 3-23 3.2. Application Overview __________________________________________________________ 3-24

3.2.1. Traffic Control______________________________________________________________ 3-24 3.2.2. Track Surveying Applications__________________________________________________ 3-27

4. MAIN PROJECT RESULTS____________________________________________________ 4-29 4.1. Test-Bench Development________________________________________________________ 4-29 4.2. Test Campaign ________________________________________________________________ 4-32

4.2.1. Methodology _______________________________________________________________ 4-32 4.2.2. Test Results Synthesis________________________________________________________ 4-34

4.2.2.1. Sensor Calibration _______________________________________________________ 4-34 4.2.2.1.1. Navigation grade Sensor _______________________________________________ 4-35 4.2.2.1.2. Automotive grade Sensor_______________________________________________ 4-36

4.2.2.2. Position and Velocity Accuracy _____________________________________________ 4-37

IADIRA Final Report



4.2.2.3. Minimum required C/N0 ___________________________________________________ 4-39 4.2.2.4. Loop bandwidth reduction _________________________________________________ 4-39 4.2.2.5. Position and Velocity Accuracy under Signal Blockage __________________________ 4-40 4.2.2.6. Reacquisition after Outage _________________________________________________ 4-41 4.2.2.7. Carrier and Code Phase Errors ______________________________________________ 4-42 4.2.2.8. Velocity Accuracy for Doppler Shift Estimation ________________________________ 4-45 4.2.2.9. Tracking Capability as a Function of Receiver Clock ____________________________ 4-45 4.2.2.10. Cycle Slip Robustness ___________________________________________________ 4-45

4.3. Technology Transfer ___________________________________________________________ 4-47 4.3.1. Applicability to Target Application and User Terminal ______________________________ 4-47 4.3.2. Technology Provider Activities_________________________________________________ 4-49 4.3.3. Dissemination Activities ______________________________________________________ 4-50

5. CONCLUSIONS AND RECOMMENDATIONS ___________________________________ 5-51

IADIRA Final Report



List of Figures

Figure 1: Galileo’s End-User Service Synthesis .......................................................................................... 2-17 Figure 2: Levels 4 and 5 of INS/GNSS integration...................................................................................... 2-21 Figure 3: LE that composes the train control application [RD-8]. ............................................................... 3-26 Figure 4: Trolley used for track geometry surveying [RD-9] ....................................................................... 3-27 Figure 5: IADIRA Test-Bench Graphical User Interface............................................................................. 4-29 Figure 6: IADIRA Test-bench High Level Architecture.............................................................................. 4-31 Figure 7: IG’s TAG experimental INS/GNSS data acquisition system ....................................................... 4-31 Figure 8: The TAG multiple IMU rigid platform......................................................................................... 4-31 Figure 9: Multi-channel receiver implementation in GRANADA (example for 4 channels) ...................... 4-32 Figure 10: Data collection setup and instrument location ............................................................................ 4-33 Figure 11: Test trajectories: (a) track switch and (b) urban layout............................................................... 4-33 Figure 12: Reference (a) trajectory, (b) change in position, (c), velocity and (d) attitude ........................... 4-34 Figure 13: (a) Position, (b), velocity, (c) attitude and (d) clock errors for the FJI with ideal GNSS measurements ............................................................................................................................................... 4-35 Figure 14: (a) Position, (b), velocity, (c) attitude and (d) clock errors for the SSKS with ideal GNSS measurements ............................................................................................................................................... 4-36 Figure 15: Position errors for (a) aided (deeply coupled) and (b) unaided (loosely coupled) receiver with navigation grade sensor (unsmoothed PR) ................................................................................................... 4-37 Figure 16: Position errors for (a) aided (deeply coupled) and (b) unaided (loosely coupled) receiver with automotive grade sensor (unsmoothed PR) .................................................................................................. 4-37 Figure 17: PLL filter outputs for (a) unaided and (b) aided receivers (with narrow loop bandwidths) using automotive grade sensors ............................................................................................................................. 4-38 Figure 18: Velocity errors for (a) unaided and (b) aided receiver using unsmoothed PRs and automotive grade sensors ................................................................................................................................................ 4-39 Figure 19: Minimum C/No for (a) unaided and (b) aided receivers for different PLL bandwidths.............. 4-39 Figure 20: Expected (a) position and (b) velocity errors VS Drift time ....................................................... 4-40 Figure 21: Error and Standard Deviation using automotive grade sensor for SV14 for a 100s simulation with ideal GNSS measurements ........................................................................................................................... 4-41 Figure 22: Doppler Error for (a) automotive and (b) navigation grade IMUs during full outage of 20s (starting at t=25s).......................................................................................................................................... 4-41 Figure 23: (a) PLL discriminator outputs and (b) pseudorange error during full outage simulation for unaided receiver ......................................................................................................................................................... 4-42 Figure 24: Doppler estimate error for the aided receiver, with automotive grade IMU, during full outage of 20s (starting at t=25s) ................................................................................................................................... 4-42 Figure 25: Pseudorange error for an (a) unaided receiver and (b) an aided receiver with an automotive grade IMU and using unsmoothed PRs.................................................................................................................. 4-43

IADIRA Final Report



Figure 26: Carrier phase error for an (a) unaided receiver and (b) an aided receiver with a navigation grade IMU and using unsmoothed PRs.................................................................................................................. 4-43 Figure 27: Reference Doppler shift and PLL filter output for an unaided receiver...................................... 4-44 Figure 28: PLL filter output for aided receiver using (a) navigation and (b) automotive grade sensors...... 4-44 Figure 29: Clock bias and estimate for a TCXO clock................................................................................. 4-45 Figure 30: Probability of cycle slips for different sensor types and for (static and accelerating) unaided receiver ......................................................................................................................................................... 4-46 Figure 31: Selecting IADIRA enabled applications ..................................................................................... 4-47

IADIRA Final Report



List of Tables

Table 1: Acronyms and abbreviations ......................................................................................................... 1-14 Table 2: Applicable documents .................................................................................................................... 1-15 Table 3: Reference documents ..................................................................................................................... 1-16 Table 4: Inertial vs. GNSS characteristics.................................................................................................... 2-20 Table 5: GNSS application overview of candidate applications .................................................................. 3-23 Table 6: High level of user requirements for Traffic control ....................................................................... 3-26 Table 7: High level user requirements for track geometry surveying .......................................................... 3-28 Table 8: High level user requirements for line inspection............................................................................ 3-28 Table 9: Receiver Configurations and Market Characteristics..................................................................... 4-48

IADIRA Final Report



Intentionally left blank

IADIRA Final Report

Code: IADIRA-DME-FRD-001Date : 30/11/06Issue : 1.1Page : 1-11


11.. IINNTTRROODDUUCCTTIIOONN

11..11.. PPuurrppoossee

This technical note has been prepared by DEIMOS Engenharia, S.A. and by Institute of Geomatics in the frame of the “Inertial Aiding Deeply Integrated Receiver Architecture (IADIRA)” project, which has been carried out in the context of the European Commission 6th Framework Program, under Galileo Joint Undertaking contract GALILEO Research & Development activities Second Call Area 3: Innovation by Small and Medium Enterprises under call GJU/04/2423-CL/NV.

This document constitutes the final report of IADIRA project and synthesises main work performed, from the system engineering, requirements and design engineering to verification and validation and technology transfer activities.

11..22.. PPrroojjeecctt OObbjjeeccttiivveess

The IADIRA project aims at exploring the inertial aiding of the future Galileo or Galileo/GPS receivers where the ultimate goal is to develop a concept for an Inertially Enabled GNSS receiver architecture through an Tightly coupled or deeply integrated architecture, allowing the receiver to exhibit a superior performance in terms of trackable satellites and in the quality of the tracked satellites signals. More specifically, if the tracking loop is aided by providing a reference trajectory and dynamics, the loop bandwidth can be reduced significantly and the integration time can be dramatically increased from the typical figure of a few milliseconds to the order of seconds, and thus opening the door for innovative applications of satellite navigation. IADIRA aims at presenting an innovative concept of incorporating a low-cost, low-weight, low-consumption IMUs and MEMS MIMUs into the Galileo receiver architectures (Deeply Integrated architecture), so that it provides aiding to the carrier and code phase tracking loops and ultimately to develop a concept for an Inertially Enabled GNSS receiver architecture that can “take inertial antennas” through an tightly coupled or deeply integrated architecture. The Tightly coupled mode, also termed Deeply Integration is one of the several methods for integration of INS and GNSS measurements. The uncoupled mode uses independent PVT and/or PVAT solutions from the GNSS and INS that are selected or combined with a multimode Kalman filter. The loosely coupled mode is similar to the uncoupled but with error-state feedback for INS calibration where INS supplies position seed data as required (during SiS outages). In the tightly coupled mode the GNSS and INS sensors are limited to their sensor functions, that is, they do not compute a navigation solution: the navigation filter collects individual data and outputs the PVT and/or PVAT solution using a Kalman filter, allowing feedback to the INS sensor to refresh its navigation parameters. Another possible integration is reached in the tightly coupled where the INS is used to aid the GNSS phase/frequency and code tracking loops directly, allowing enhanced recovery following an SiS outage and better receiver performances. IADIRA focuses in the field of “inertial aiding” and “inertial coasting”. In the context of this document inertial aiding refers to the use of inertial-derived position and velocity for the improvement of the

IADIRA Final Report



GNSS receiver PLLs and DLLs. Inertial coasting refers to the use of inertial derived position and velocity to interpolate GNSS trajectories (for short periods), be it because of GNSS data gaps or just to interpolate between GNSS fixes. The main IADIRA project activities include:

Characterisation of low-cost IMUs able to be integrated in the receiver;

Definition of the combined IMU/GNSS receiver algorithms;

Prototyping of such receiver using as a base the GRANADA simulator available from the 1st call results;

Delivery of a test-bench including IMU data-set collected with in test campaign;

Simulation campaign for several environments and conditions;

Evaluation of the method and recommendations;

The different project phases, schedule and task description, milestones and deliverables can be found in [AD-5] together with the software design and development process description.

11..33.. DDooccuummeenntt OOvveerrvviieeww

This document is structured as follows:

• Chapter 1 provides the current introduction and document overview as well as acronyms and abbreviations.

• Chapter 2 introduces the hybridisation concept used in IADIRA.

• Chapter 3 presents a pre-selection of target applications and describes the two applications finally selected for IADIRA.

• Chapter 4 presents the main project results (description of the developed software, theoretical analysis, simulation results, technology transfer activities, etc.)

• Chapter 5 provides recommendations for IADIRA applications and further activities.

IADIRA Final Report



11..44.. AAccrroonnyymmss aanndd AAbbbbrreevviiaattiioonnss

The acronyms and abbreviations used in this document are the following ones:

Acronym Description ADC Analog-to-Digital Conversion AGC Automatic Gain Control AI Accuracy and Integrity AltBOC Alternative binary offset carrier AVE “Alta Velocidad Español” (Spanish High Speed Train) BOC Binary offset carrier BT Bit-true CF Carrier-Phase CRC Cyclic Redundancy Check CS Commercial Service DAB Digital Audio Broadcasting DGPS Differential GPS DLL Delay Lock Loop DME DEIMOS Engenharia DMS DEIMOS Space E&N Environment and Navigation ECEF Earth Centred, Earth Fixed EGNOS European Geo-stationary Overlay Service FLL Frequency Lock Loop FPSO Floating Production Storage and Offloading system GARDA Galileo Receiver Development Activities GARSIM Galileo Receiver simulator GJU Galileo Joint Undertaking GBAS Ground Based Augmentation System GNSS Global Navigation Satellite System GPRS General Packet Radio Service GPS Global Positioning System GRANADA Galileo Receiver Analysis and Design Application GSM Global System for Mobile communications GUI Graphical User Interface GUST Galileo User Segment Terminal HI High Integrity HMI Hazardously Misleading Information HW Hardware IAC Inertial Aiding and Coasting IADIRA Inertial Aiding - Deeply Integrated Receiver Architecture ICD Interface Control Document IF Intermediate Frequency IFR Instrument Flight Rules IG Institute of Geomatics

IADIRA Final Report



Acronym Description IGS International GPS Service IMU Inertial Measurement Sensor INS Inertial Navigation System KUPT Known position – Zero velocity Update LE Local Element LNA Low Noise Amplifier MEMS Micro-Electro-Mechanical Systems MIMU Miniature IMU NCO Numerically Controlled Oscillator OBS Observation OEM Original Equipment Manufacturer OS Open Service PLL Phase Lock Loop PPP Precise Point Positioning PR Pseudorange PRN Pseudo Random Noise number PRS Public regulated service PVT Position, Velocity and Time RAIM Receiver Autonomous Integrity Monitoring RF Radio Frequency RMS Root Mean Square RT Ranging and Timing RTK Real-Time Kinematics Rx Receiver SBAS Satellite Based Augmentation Systems SIS Signal-in-Space SoL Safety-of-Life SOW Statement Of Work SPS Standard Positioning Service SV Space Vehicle SW Software TAG Trajectory, Attitude And Gravity TBC To be confirmed TBD To be defined TCAR Tree Carrier Ambiguity Resolution UERE User Equivalent Range Error UMTS Universal Mobile Telephony Service URE User Range Error UT User Terminal UWB Ultra Wide Band WAAS Wide Area Augmentation System WARTK Wide Area Real-Time Kinematics ZUPT Zero velocity Update

Table 1: Acronyms and abbreviations

IADIRA Final Report



11..55.. RReellaatteedd DDooccuummeennttss

11..55..11.. AApppplliiccaabbllee DDooccuummeennttss The following table specifies the applicable documents.

Ref. Applicable Document

AD-1 Galileo Research and development activities, First call, Activity A: User receiver preliminary development, Statement of Work. Ref: GJU/03/094/issue2/OM/ms, Issue2.

AD-2 Galileo Receiver Development Activities: GRANADA Design Data Package, Issue 1.0. Ref: GARDA-DMS-DDD-001

AD-3 Galileo Signal-in-Space ICD (SISI ICD), Issue 6, Ref: ID/GAL/0258/GLI.

AD-4 ICD-GPS-200, NAVSTAR GPS Space Segment / Navigation User Interfaces, April 2000, Issue C

AD-5 IADIRA Project Plan, Issue 2.0, Ref: IADIRA-DME-PMP-001

AD-6 IADIRA Technical Proposal, Issue 1, 17/09/04, G2C_A3-DME-PRO-001

AD-7 IADIRA Requirement Analysis Document, Issue 1.2, Ref: IADIRA-DME-RAD-001

AD-8 IADIRA Verification and Validation Plan, Issue 1.0, Ref: IADIRA-DME-4100-001

AD-9 IADIRA Software User Manual, Issue 1.2, Ref: IADIRA-DME-SUM-001

AD-10 IADIRA Test Bench Dataset description, Issue1.0, IADIRA_3130_01

AD-11 IADIRA Validation Results, Issue 1.3, Ref: IADIRA-DME-4200-001

AD-12 IADIRA Design Document, Issue 1.1, Ref: IADIRA-DME-DDD-001

Table 2: Applicable documents

11..55..22.. RReeffeerreennccee DDooccuummeennttss The following table specifies the reference documents.

Ref. Reference Document

RD-1 Wis, M., Samsó, L., Aigner, E., Colomina, I., 2004. “Present achievements of the experimental navigation system TAG”. International Archives of Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol. 35-B1, Comm. I, pp. 136-141.

RD-2 GALILEI - TASK B - Galileo Service Definition -ISSUE: 1.0, GALI-TATMLtd-DD-010, 02/12/2002.

RD-3 GALILEI – TASK C – Generic Local Element: UT Definition & Justification. ISSUE: 1.1. GALI-TNAV-DD029. 28/10/02.

RD-4 GALILEI – TASK C -Complementary Systems: Functions and Performance. ISSUE 2.1, GALI-ASPI-DD-021, 12/04/2002.

RD-5 Global Positioning Systems, Inertial Navigation, and Integration. M.S.Grewal, L.R.Weill, A.P.Andrews. John Wiley & Sons, Inc., ISBN 0-471-20071-9, 2001.

IADIRA Final Report



Ref. Reference Document

RD-6 GALI_INDRA_DD_054. Customized Local Element Architecture Report, Rail. GALILEI studies. July, 2003.

RD-7 GALI_FDC_DD020. Required Performances for Local Application. GALILEI studies. January, 2002.

RD-8 Casewell, I., Guida, U., “Galilei Tack C/D Local elements”. Galilei Fina Review, ESTEC, 10th July 2003

RD-9 Glaus, R., Peels, G., Müller, U., Geiger, A., “Precise Rail Track Surveying”, GPS World, July 2004.

RD-10 P. Silva, J. Silva, et al., “IADIRA: Inertial Aided Deeply Integrated Receiver Architecture”, Proceedings of ION 2006, Fort Worth, Texas

RD-11 Wiss, J-M., Barbu, G., et al. Requirement of Rail Applications. Final Draft. GNSS Rail User Forum. May, 2000.

Table 3: Reference documents

IADIRA Final Report



22.. IINNEERRTTIIAALL AAIIDDIINNGG AANNDD CCOOAASSTTIINNGG

22..11.. GGaalliilleeoo CCoommbbiinneedd SSeerrvviicceess

The Galilei study tackled the synthesis of Galileo user services in three steps. The first and simplest view of the services represents the Basic Services provided by Galileo, such as Position, Time or Authentication. Secondly, and built from this Basic Services, there are the Reference Services (OS, SoL, CS, SAR and PRS). Together, they constitute the set of user services supplied by the Galileo Core System. Finally, a third major group of End-User Services, labelled Combined Services, may be added to these core system services. They are built from the Basic Services by combining Galileo's services with those from other systems. They result from the inclusion of additional services from the “Enhancement” (local and regional elements like GBAS, SBAS, etc) or “Other” Service Suppliers (GPS, Maps, Inertial Systems, etc.), that may be offered from third party providers to give the final set of value added services [RD-2].

The general manner by which services may be built up or synthesised is illustrated in Figure 1 [RD-2].

Figure 1: Galileo’s End-User Service Synthesis

The following Combined Services have been identified for Galileo: Regionally or Locally Enhanced Navigation Services, GNSS Navigation Services, Communication Based Navigation Services and finally, Integrated Navigation Services, in which the IADIRA project is scoped.

Most end-users will not differentiate between the services they will get directly from Galileo (i.e. the Principal Service Supplier) and those that they get from the Value Added Service (VAS) Suppliers. In

IADIRA Final Report



many cases they will also be relying on services from other navigation systems such as GPS, Loran-C or Inertial Navigation Systems (INS), and from communication or information systems. From a user's perspective, Galileo will be just one of many sources of information employed in order to achieve their own particular goals [RD-2].

The Integrated Navigation Services result from combining GNSS with non satellite-based navigation and positioning services and systems. The Integrated Navigation Services provide benefits of redundancy and extended coverage though not necessarily improved performance. Galileo has no special built-in support for this kind of combined solutions but has been designed to work compatibly [RD-2].

For the Galilei definition three different integrated navigation services will be considered, consisting of:

GNSS + Loran-C Services (terrestrial navigation service),

GNSS + Indoor Navigation Services

GNSS + Hybrid Services (some other kind of sensor, such as an INS or odometer, that provides non-broadcast navigation services).

The purpose of the integration of INS and GNSS systems, considered in this last service, is to maintain the availability and stability of a GNSS positioning solution in the presence of interference, bad reception and even outages of the signals and to combine the long terms stability of a GNSS system with short-term accuracy of an INS system (using the GNSS position and velocity estimates to bound INS drift errors).

22..22.. HHyybbrriiddiissaattiioonn ccoonncceepptt oovveerrvviieeww

In this context, hybridisation is the use of measurements from several sensors (including non satellite-navigation sensors) within a single system [RD-2], in order to enhance the availability, continuity and/or integrity performance provided by GNSS, as well as the level of protection against poor environment conditions (loss of satellite visibility, RF interference, etc.).

The main interest of integrating GNSS with various additional sensors is to provide continuous navigation during periods of shading of the satellite signals, under signal interference or when satellite positioning is insufficient or not available [RD-4]. The use of other systems and sensors to assist GNSS services in troublesome environments has proven to be a valuable and attractive concept.

The integration of extra sensors results in an improvement in navigation availability, integrity, continuity of service and coverage. Integrated navigation services also have a significant role in providing redundancy of positioning solutions [RD-2].

A list of 24 sensors, used in the aviation, maritime, road and rail sectors, were identified in the Galilei Studies as candidates for hybridisation. The most popular are inertial sensors (Inertial Reference System, Attitude and Heading Reference System, Integral Motion Sensor, Motion Remote Unit, Gyrocompass, gyrometers, accelerometers), altimeters (Barometric Altimeter, Radio Altimeter), speedometers, pedometers, odometers and magnetic sensors. Map Matching may also be considered as a sensor in the way of relating trajectories to digital map. An additional accurate clock is also of great interest since it can be used to monitor the GNSS receiver clock error enabling a full navigation solution, over short periods of time, even if only three GNSS satellites are visible.

Inertial Navigation Systems estimate the dynamics (position, velocity, attitude, and attitude rates) of their host vehicle. An INS consists of the following [RD-5]:

IADIRA Final Report



Inertial Measurement Unit (IMU) or Inertial Reference Unit (IRU) containing a cluster of sensors.

Navigation computer(s), which calculate the gravitational acceleration base don these sensors and doubly integrate the net acceleration to maintain an estimate of the position of the host vehicle.

This acceleration integration causes the INS velocity errors to grow linearly with time. Position errors are proportional to velocity errors and, therefore, also tend to grow with time. Thus an INS, despite its convincing short-term stability, has to be realigned periodically.

The main advantages of Inertial Navigation over GNSS are as follows:

It is autonomous and does not rely on visibility conditions;

It is immune to jagging and inherently stealthy. It never receives, nor emits detectable radiation and requires no external antenna that might be detectable by radar;

The disadvantages include the followings:

Mean-squared navigation errors increase with time;

Cost (acquisition/operation/maintenance);

Size and weight, power requirements, heat dissipation… etc.

GNSS/INS integration exploits advantages of both systems, allowing the user to:

Cross-check independent solutions and have the benefits of a hybrid solution;

Maintain a specified level of navigation performance during outages of the GNSS satellite reception;

Access a complete six-degree-of-freedom navigation solution (X, Y, Z translation and rotation) at a higher output rate than is conventionally available from GNSS alone;

Reduce the random error component of the GNSS navigation solution;

Maintain the availability of a GNSS solution in the presence of severe vehicle dynamics and interference;

Bound INS drifting errors to those of GNSS.

GNSS receivers are a low-frequency response navigation sensor, which can provide instantaneous position accuracy in the order of 15m normally at 1 Hz rate (up to 10 Hz). On the other hand, Inertial Navigation Systems (INS) can “continuously” (up to hundreds of Hz) provide accurate short-term position, velocity and also attitude estimates. In summary, the errors in GNSS user position computations and the outputs of INS are complementary (as shown in Table 4). In particular, GNSS user position computations contain bounded errors, some of which are random and uncorrelated from one fix to the next. Dead-reckoning sensors are accurate only over short time periods but they drift over long time periods. Proper fusion of GNSS user position computations with inertial sensor data can take advantage of these complementary errors, enabling better performances than either type of stand-alone solution. INS can also achieve a high relative accuracy, which can support ambiguity resolution [RD-3].

IADIRA Final Report



Inertial System GNSS System Output data BW High (50-200 Hz) Low (~1 Hz)

Error characteristics Position errors grow with time (~1.5 Km/h, depending on the grade of the sensors) and are

affected by low dynamics vehicle manoeuvres

Position errors do not grow with time and are relatively

unaffected by low dynamic vehicle manoeuvres

Output Noise Level Very low, considering the high system BW

The main error characteristic is noise

Table 4: Inertial vs. GNSS characteristics

22..22..11.. IInneerrttiiaall AAiiddiinngg

Depending on how the INS and GNSS data are combined, different integration levels can be defined. There are two classification criteria:

• Computation distribution: This criterion indicates where the GNSS data processing is done: inside (centralized) or outside (decentralized) the Kalman filter.

• Coupling/integration strength: This criterion classifies the integration levels based on the kind of observations that are included and states that are estimated within the Kalman filter (uncoupled, loosely coupled, tightly coupled or ultra-tightly coupled).

It should be mentioned that the names given to those integration levels differs from authors and research groups. Therefore, the following description is based on a numerical classification. The higher is the integration strength, the higher is the classification number.

22..22..11..11.. IInntteeggrraattiioonn LLeevveell 11

Involves an INS navigator that generates a Position-Velocity-Attitude-Time (PVAT) solution at a high data rate (50 Hz to 400 Hz) and a GNSS receiver that generates a Position-Time (PT) or a Position-Velocity-Time (PVT) solution at a low data rate (1 to 10 Hz). The INS/GNSS Kalman filter is composed of 9 states and just corrects the INS trajectory with the GNSS trajectory. This filter is known as uncoupled or uncoupled-decentralized Kalman Filter.


Involves an INS navigator that generates a PVAT and IMU calibration solution at a high data rate (50 Hz to 400 Hz) and a GNSS receiver generates a PT or a PVT solution at a low data rate (1 to 10 Hz). The INS/GNSS Kalman filter is composed of 15 to 30 states (depending on the implemented IMU model) and corrects the INS trajectory and adjusts the IMU calibration values with the GNSS trajectory. This filter may be known as loosely coupled or loosely coupled decentralized Kalman Filter.

IADIRA Final Report




Involves an INS navigator that generates a PVAT and IMU calibration solution at a high data rate (50 Hz to 400 Hz) and a GNSS receiver that generates a Pseudorange-Time (PRT) or a Pseudorange-Carrier Phase-Time solution at a low data rate (1 to 10 Hz). The INS/GNSS Kalman filter is composed of 15 to 30 states (depending on the implemented IMU model) and corrects the INS trajectory and adjusts the IMU calibration values with the GNSS trajectory. It is able to take advantage of less than four satellites geometries. Beyond this level begins the designation ambiguity: this filter may be known as closely coupled or loosely coupled centralized or tightly coupled Kalman Filter (depending on the author).

22..22..11..44.. IInntteeggrraattiioonn LLeevveellss 44 aanndd 55

In addition to what is done with level 3 integration, levels 4 and 5 (Figure 2) also enable the estimation of the Doppler shift due to satellite–receiver dynamics. These values are used to aid signal tracking in the GNSS receiver’s signal processing stage, increasing robustness to noise, interference, dynamics, signal blockage, etc. There is still some designation ambiguity since a level 4 system may be known as tightly-coupled, ultra-tightly coupled, deeply coupled or deeply integrated depending on the author and a level 5 system may be known as ultra-tightly coupled or (also) as deeply coupled.

Figure 2: Levels 4 and 5 of INS/GNSS integration

The main differences between levels 4 and 5 are:

The GNSS data fed to the integration filter, which are pseudoranges (PR) and carrier phases (CP) estimates (produced by the tracking loops), in the case of level 4, or I and Q measurements (generated by the receiver after correlation), in the case of level 5;

The rate of the GNSS estimates sent to the filter, which is a low data rate (1 to 10 Hz), in the case of level 4, and a medium-high data rate (50 to 200 Hz), in the case of level 5;

Level 4 was the integration level implemented and investigated in the IADIRA project. One of the most important features of this type of integration is the feedback toward the GNSS receiver. This feedback, consisting on the Doppler shift estimate, allows the reduction of the tracking loop

IADIRA Final Report



bandwidths, consequently reducing the noise in the PR and CP estimates and decreasing the minimum carrier-to-noise density ratio (C/N0) required for successful signal tracking. The external Doppler shift estimates thanks are based on the (known) satellite trajectory (easily available if ephemeris is known) and on the receiver dynamics estimated by the INS system.

22..22..22.. IIAADDIIRRAA GGeenneerraall RReeqquuiirreemmeennttss The IADIRA receiver is expected to outperform unaided receivers and aided receivers with lower levels of integration in terms of system availability, integrity, robustness, position and velocity accuracy. The developed IADIRA Test-Bench is meant to be a highly flexible and powerful software tool enabling this performance increase assessment.

IADIRA Final Report



33.. TTAARRGGEETT AAPPPPLLIICCAATTIIOONN SSEELLEECCTTIIOONN

This chapter provides a summary of the results of WP1400 of IADIRA [AD-7]. Three candidate applications (airborne remote sensing, rail navigation and road applications) were selected from a preliminary list of candidate applications. The potential applications and environments suitable for the technical and economical feasibility of the IADIRA concepts were identified and reviewed and only two applications domains (road and rail) were pre-selected. Finally the IADIRA target application on Safety of Life (rail) was selected and described in more detail.

33..11.. AApppplliiccaattiioonn SSeelleeccttiioonn

There are a large number of applications that are suitable for the IAC concept. An analysis of these applications was done considering the list of Galileo applications defined in GALA and Galilei projects. Each application has a series of criteria that were scored giving a qualitative idea of the importance of each factor for the application. According to a weighted average of the different criteria a final score was given to each application. This score determined a preliminary selection of some potential target applications that are considered for the evaluation of the IAC concept. The following table illustrates the results of the preliminary selection in three main markets: Professional, Safety of Life and Mass Market.

GALA ID MARKET SECTOR DOMAIN APPLICATION

6 Safety of Life and Security

Transport of Passengers and Goods Rail Train Control

10 Safety of Life and Security

Transport of Passengers and Goods Rail Track Survey

31 Safety of Life and Security Security Traffic Surveillance and

Monitoring Road Tolling

33 Mass Market Land and River Navigation Cars, Motorcycles Route Guidance

34 Mass Market Land and River Navigation Cars, Motorcycles Information Services

35 Mass Market Land and River Navigation Cars, Motorcycles Emergency Call Breakdown Theft and Recovery

36 Mass Market Land and River Navigation Trucks and Buses Route Guidance

37 Mass Market Land and River Navigation Trucks and Buses Information Services

38 Mass Market Land and River Navigation Trucks and Buses Emergency Call Breakdown Theft and Recovery

39 Mass Market Land and River Navigation All Road Vehicles Advanced Driver Assistance Systems (ADAS)

40 Mass Market Land and River Navigation Light Commercial Vehicles Route Guidance

41 Mass Market Land and River Navigation Light Commercial Vehicles Information Services

42 Mass Market Land and River Navigation Light Commercial Vehicles

Emergency Call Breakdown Theft and Recovery

63 Professional Market Scientific Applications Geodesy Precise Positioning for Geodetic Sensors

Table 5: GNSS application overview of candidate applications

IADIRA Final Report



The chosen applications correspond to the following markets:

• Professional Market (airborne remote sensing).

• Safety of Life Market (rail navigation).

• Mass Market (road applications)

An in-depth analysis was made for the last two before finally selecting the Safety-of-Life (SoL) market as the targeted market for the development of the IAC concept. The next section describes the actual selected applications.

33..22.. AApppplliiccaattiioonn OOvveerrvviieeww

Rail navigation is based on the positioning of the train (generally the locomotive) along the rail. The usual layout of the railway lines (between buildings, in tunnels, in manmade or natural canyons, besides mountains slopes, etc.) make any GNSS system prone to multipath interference or signal loss due to satellite blockage. This justifies the use of inertial aiding techniques to support the maintenance or reacquisition of signal lock. There are many applications that substantiate the use of a GNSS system for train positioning:

Track geometry surveying for the determination of track inclination and gauge;

Corridor mapping for automatic extraction of railway asset inventory;

Fleet Control for Cargo management applications;

Safety and Collision Avoidance applications;

Traffic management;

Traffic information…

It is clear that these applications do not have the same positioning requirements. In the next sections, the following categories of rail navigation applications are reviewed:

Safety related applications (traffic control);

Track Surveying applications.

Additional internal requirements for the IADIRA Receiver as well as for the IADIRA Test-Bench have been derived after a deep analysis of the target application requirements presented in §3.2.1 and §3.2.2.

33..22..11.. TTrraaffffiicc CCoonnttrrooll Traditionally, rail safety has been concentrated on the trackside. It has been based on electro-mechanic and, lately, in electronic elements that command signals along track. The concept is to divide tracks into blocks and protect the entrance to these blocks by a warning stop signal. The length of a block and distance of the warning stop signal to the entrance of the block are dependent on the maximum speed allowed into that block. Since this system is not at all 100% safe, additional warning systems for Automatic Train Protection (ATP) have been developed, based on trackside as well as trainborne solutions, to inform the driver about the status of the signals. This safety model is heavily conditioned to human errors [RD-6]. Emerging safety technologies are intended to increase traffic capacity by reducing both block length (by implementing the moving blocks concept) and the potential for human errors. This is accomplished

IADIRA Final Report



through the so called Automatic Train Control (ATC), by combining network management technologies with automatic control systems and having direct control of the train rather than providing information to the driver and a safety override system. In high-speed lines, the application of European Rail Traffic Management System and the European Traffic Control System (ERTMS/ETCS) standards based on ATC is going to be mandatory, but for low density and low speed lines the use of ATP should be enough in a first instance.

The use of GNSS systems on trains will be mandatory within the coming ERTMS/ETCS systems, where the ATC and/or ATP positioning constraints (preferably both) should be satisfied so as to decrease the deployment of electronic devices along the tracks. In such systems, the GNSS is used as a sensor to locate the train and control its position in the rail network within a maximum response time (1 second). The accuracy is also important in this application in order to locate the train within the track (about 1 meter).

Given the trend of standardization of the European rail networks, the ERTMS/ECTS system is needed for enhancing this homogenisation process. This control system involves the implementation of a complete signalling system that includes wired and radio-linked track presence sensors, radio balises, pseudolites and reference/integrity monitor stations (see Figure 3) that cover the positioning of the train on locations where the satellite visibility is compromised (tunnels and urban canyons).

According to the results of the analysis done in [RD-7] and [RD-8], a receiver that works with L1+E5a for the Galileo and L1+L5 for the GPS system is required to achieve an availability of 99.99% in shadowed areas. It could be possible to obviate the utilisation of balises by using Differential GNSS but as long as the elevation mask is set below 50º (not usual in high density urban areas or dense forests). The results of the analysis show that it could be possible to achieve 0.8m of accuracy in horizontal position (95% of confidence) providing that the reference stations are spaced 150 km along the main tracks. Integrity remains a challenge because the Local Integrity Monitors are sited in the same locations of the reference stations and must ensure a maximum Time-to-Alarm of 1 second. This threshold depends on the performance of the network with a moving element (the train).

In addition, given that the European rail network includes a large number of regional and local railways (up to 165,000 km), it is virtually impossible to implement this signalling system on every track. So, this traffic signalling system is only implemented on the main transeuropean lines or the high velocity lines (Spanish AVE or French TGV). Therefore, in the lines where the signalling system can not be implemented, the train positioning system must rely on additional sensors (as IMUs or odometers) to keep the required accuracy and integrity for this application.

Thanks to the INS/GNSS deep integration, the integrity of the system can be maintained within limits for a longer time than with an unaided GNSS. So the research effort applied in this project is justified for train control applications. The requirements ([AD-7], [RD-7], and [RD-11]) for this application can be seen on Table 6.

IADIRA Final Report



Figure 3: LE that composes the train control application [RD-8].

Requirement Value

Horizontal Accuracy 1 m. in 95% of confidence1. (5 m. in 100%)

Velocity Accuracy 2 km/h below 30 km/h (12 km/h at 500 km/h)

Update Rate 5 seconds

Availability 99.99 % of mission time

Integrity (Time to Alarm) < 1 second

Integrity (alert limits) 1.5 m. Cross track error and 2.5 m. Along track error

Integrity (Integrity risk) 2 10-9 – 10-8 / hour

Continuity3 99.99 %

Coverage European Land Mass (ELM)

Interrupt Threshold: < 5 seconds

Fix rate4 1 per second.

Communications 2400 – 9600 bps with BER of 10-4

Operational speed 5 – 500 km/h

Table 6: High level of user requirements for Traffic control

1 10 m. on medium density lines and 25 m. on low density lines. 2 Probability an alert is not given within the Time to Alert. 3 Probability that if a service that is provided at a certain time, the service is still provided over the following hour. 4 Position fixes and integrity checks per unit time.

IADIRA Final Report



33..22..22.. TTrraacckk SSuurrvveeyyiinngg AApppplliiccaattiioonnss Track surveying applications can also benefit from IADIRA developments. In this case the most important requirement is not the integrity or response time but the accuracy.

The track surveying consists of a series of tasks that involve:

Control of track geometry. To check if the line is within specifications and detect rail deformations. This task requires an extreme accuracy.

Inspection of the rail status. It is usual that this surveying is done with specialized sensors as optical and infrared cameras and uses artificial vision algorithms to detect irregularities.

Planning and verification of track infrastructures as beacons, balises, traffic signals and etcetera and building of the infrastructure database for its inclusion on a GIS.

For those applications it is usual that the system is complemented with a local augmentation system as reference stations in order to improve the accuracy of the solution. The real time navigation solution may be generated to assist any complementary sensor; but in this case, it is not critical, because it is usual to process all the collected data off line. However, information about the integrity of the system is needed in real time in order to check that the collection of navigation data is being done in good conditions.

The system is composed of a series of sensors as photogrammetric cameras, laser scanners, odometers, inclination sensors, track gauge sensors, total stations, reflectors, tactical or navigation grade IMUs, etc. mounted on a trolley or small wagon (Figure 4). The aim of such system is to collect all the possible data that allows accomplishing the tasks mentioned above. By that reason all these measurements need to be complemented by a GNSS system that will provide position and timing information.

Figure 4: Trolley used for track geometry surveying [RD-9]

The operation of such system can be done in two approaches.

In the first approach, the system is moved at medium-low velocities (below 100 km/h) along the track while making automatic acquisition of features along the track. This acquisition is done to check the rail status or the infrastructure.

IADIRA Final Report



In the other approach the system is moved at very low velocities (up to 5 km/h) or even stopped (static acquisition). This approach is used when high accuracy measurements are required (around 1 cm or less for track geometry measurement).

As in traffic control applications, depending on the location satellite obstruction or multipath may create problems. However these effects could last longer since the speed is slower than in the traffic control case and, consequently, the time spent in problematic locations is longer.

Integrity requirements are not restrictive. However, accuracy requirements, dependent on the operation mode, are a bit strong. These requirements have been extracted from [RD-6] and [RD-11] and are summarised in Table 7 and Table 8.

Requirement Value

Horizontal Accuracy 0.5 cm – 1 cm (95 % of confidence)

Vertical Accuracy 1 cm. (95% of confidence)

Availability 99 %

Integrity (Time to Alarm) 30 seconds

Integrity (alert limits) TBD

Integrity (Integrity risk) 10-9

Coverage Operating area covered by secondary stations

Operational speed From static to 5 km/h.

Table 7: High level user requirements for track geometry surveying

Requirement Value Horizontal Accuracy 0.1 – 1 m (95 % of confidence)

Availability 99 – 99.5%

Integrity (Time to Alarm) 5 – 10 seconds (depending on application)

Integrity (alert limits) 0.1 m

Integrity (Integrity risk) 10-9

Coverage ELM (depending on application)

Operational speed From static to 50 km/h.

Table 8: High level user requirements for line inspection

IADIRA Final Report



44.. MMAAIINN PPRROOJJEECCTT RREESSUULLTTSS

44..11.. TTeesstt--BBeenncchh DDeevveellooppmmeenntt

The IADIRA Test-Bench allows the test of the IADIRA concept in a friendly and intuitive environment [AD-9] (Figure 5) keeping a modular software approach. It comprises both SW and HW components. The IADIRA Test-Bench uses a modified version of GRANADA Bit-True (BT) [AD-2] to simulate the deeply integrated receiver. The GRANADA Environment & Navigation simulator (E&N) can also be used to carry out test preparations before using the modified GRANADA BT (such as satellite selection).

Figure 5: IADIRA Test-Bench Graphical User Interface

The IADIRA Test-Bench can operate in two distinct modes with different degrees of simulation detail.

Signal Processing and Navigation (mode 1). This simulation mode allows combining the navigation component (Integrated GNSS/Inertial Navigator and observables plus navigation data generated by the E&N simulator) with the BT signal processing component (generating realistic observables with errors inherent to the receiver signal processing stage), implementing the integrated architecture as close to the hardware as possible. Due to the computational load, the BT simulation it is recommended to not exceed a few seconds or minutes and the number of channels although not limited is recommended to be kept as small as possible (minimum of four

IADIRA Final Report



channels). This simulation mode can run with our without inertial aiding to the signal processing stage, so as to compare results.

Simplified Signal Processing and Navigation (mode 2). This simulation mode allows the simulation of longer periods (corresponding to several hours or days) taking into account constellation geometry effects and environment effects. It is based on an analytical multi-channel model of the correlators’ outputs (intermediate model) which includes many of the errors introduced in the signal processing stage of the receiver. This intermediate model replaces most of the heavy computational load of the GRANADA BT model (operations before the correlators) preserving all the tracking loops’ components (eventually modified) of the GRANADA BT model. This simulation mode can run with our without inertial aiding to the signal processing stage, so as to compare results. Note, however, that this model has been implemented only at prototype level and therefore has not been integrated in the current release of the IADIRA Test-Bench SW. It may be used as a standalone tool to perform fast and realistic simulations of the signal processing stage of the receiver.

The different components of the IADIRA Test-Bench (illustrated in Figure 6) are:

The Data Collection and Trajectory generation: composed of (i) a SW and HW system (TAG) [RD-1] (see Figure 7 and Figure 8), it allows the collection of actual INS and GPS data along a real trajectory – thus fixing the test scenario and picking its realistic environment conditions – and (ii) a standard SW that permits the post-processing of the INS/GNSS data for the generation of trajectory. In IADIRA, several data sets have been generated corresponding to low, medium and high dynamic scenarios [AD-10].

IMU simulator: responsible for generating synthetic IMU observations (with and without systematic errors and noise) based on a reference trajectory. It can feed the Integrated GNSS-Inertial Navigator software with simulated IMU data. This software module has been developed in C++ classes and all data is generated prior to all other simulations.

Bit True Simulator: synthesises the received GNSS signals (based on a reference trajectory and on satellite ephemeris) and simulates all the signal processing components of a Galileo receiver. It provides pseudorange and carrier phase estimates (and additional information) to the Integrated GNSS–Inertial Navigator which computes the PVT solution of the inertially enabled receiver and produces Doppler estimates that are fed back to the GNSS module. These Doppler estimates can (if inertial aiding of the receiver is enabled) be used to aid the tracking loops of the GNSS module. The signal processing simulation degree of detail depends on the selected mode (addressed above). The interaction with the Integrated GNSS-Inertial Navigator software is performed using .dll files. The code acquisition stage of the GNSS receiver is bypassed in the IADIRA Test-Bench.

E&N Simulator: generates synthetic GNSS data using satellite constellation models and environment models that can be used later on by the GNSS Simulator to generate UERE budget and perform satellite visibility analysis, among other possible preparation tests that will aid in the setup of the GNSS simulator.

Integrated GNSS-Inertial Navigator (IGIN): receives both IMU (real or simulated data) and GNSS observables. It outputs the navigation solution data as well as (eventually) necessary feedback to adjust the GNSS receiver’s tracking loops (modes 1 and 2). This SW component has been developed in C++ language and its core is platform independent, allowing to easily port to any other platform with minor changes. The communication with the GNSS simulator uses a dedicated interface for Windows operating environment.

IADIRA Final Report



IADIRA Bit-True GNSS SW Receiver Simulator

IMU Simulator

SIS generation Environment RF modelling

IF Down-conversion Code Aquisition

Data detection+

Code and Carrier Tracking

Integrated GNSS/ Inertial Navigator

GNSS processing(w/ or w/o

inertial aiding)

INS processing

GNSS Environment and Navigation Simulator

Environment Simulation

Multichannel Measurement Simulation

PVT computation

PR, CF, navigation data,

Control Logic data

a,

Estimated Doppler,

Clock Error

Synthetic Inertial observations (error free)

ϖData Collection

and Trajectory Generation

Post-Processing

SW

GNSS constellation

S/C Selection

User Dynamics

E&N Graphical User Interface

BT Graphical User Interface

GUI

Navigation Integration

Ephemeris, UERE error

characterisationMeasurement

corruption

Reference Trajectory

Intermediate Code and Carrier

Tracking Model2

1

1

1 1

Figure 6: IADIRA Test-bench High Level Architecture

Figure 7: IG’s TAG experimental INS/GNSS

data acquisition system Figure 8: The TAG multiple IMU rigid platform

The GRANADA Bit-True GNSS Software Receiver Simulator recreates in detail the signal processing chain of a Galileo receiver using a Simulink model, allowing the design, analysis and simulation of the

IADIRA Final Report



receiver’s critical algorithms and architecture. The Simulink based design provides extreme flexibility allowing the user to replace receiver modules (Please refer to [AD-2] for more information on the GRANADA Bit-True software). The GRANADA BT SW was modified to enable realistic and complex satellite-receiver dynamics and signal power simulation, multi-channel receiver simulation (illustrated in Figure 9) and INS integration. Some simplifications have been made in order to increase simulation speed. Specific algorithms have been designed and implemented in the Test-Bench (both INS and Signal processing). These include code and carrier lock detection, signal outage detection, cycle slip detection, aided phase rotation, etc., and were necessary for the proper functioning of the simulated receiver (providing control signals to trigger state transitions, enabling the simulation of post processing algorithms, increasing the overall performance and robustness of the receiver, etc.).

Figure 9: Multi-channel receiver implementation in GRANADA (example for 4 channels)

44..22.. TTeesstt CCaammppaaiiggnn

A test campaign was carried out in order to test the IADIRA concept and the IADIRA Test-Bench.

44..22..11.. MMeetthhooddoollooggyy The reference trajectories were generated based on data collected in real environments. Two sets of data were collected with two IMUs and a GPS antenna mounted on top of a van (Figure 10) which was driven throughout two relevant scenarios for the target applications: a low dynamics track switch simulation (T1, illustrated in Figure 11-a) and a medium dynamics urban rail layout simulation (T2, illustrated in Figure 11-b).

IADIRA Final Report



Figure 10: Data collection setup and instrument location

(a)

(b)

Figure 11: Test trajectories: (a) track switch and (b) urban layout

The generated reference trajectories were used in the IADIRA Test-Bench to simulate realistic scenarios and user dynamics enabling the performance assessment of the IADIRA receiver and the comparison between an unaided receiver and an aided receiver with different grades of IMUs (Navigation and automotive).

Due to a partial signal outage during collection of real data and problems with the software used to generate the reference trajectory, its quality was considerably affected, leading to a contamination of the error calculation (peaks in and drift in heading). Please refer to [AD-11] for more information on the reference trajectory quality.

Unless stated otherwise, the results presented in the following sections were obtained assuming the following conditions:

4 satellite constellation with a PDOP of approximately 1.6;

C/N0 ranging from 37dB-Hz to 42dB-Hz calculated based on a look-up table relating satellite elevation with nominal C/N0;

PLL bandwidth of 3Hz for inertially aided receiver and 18Hz otherwise;

IADIRA Final Report



DLL bandwidth of 1Hz for inertially aided receiver and 4Hz otherwise;

Medium dynamics (full or part of dataset #2 depicted in Figure 11-b);

No carrier smoothing of pseudoranges;

Only two IMUs were simulated: a navigation grade IMU (the FJI) and an automotive grade IMU (SSKS)

In all tests, the navigation solution is provided at a rate higher than 1Hz, which was the requirement for the IADIRA receiver.

44..22..22.. TTeesstt RReessuullttss SSyynntthheessiiss

44..22..22..11.. SSeennssoorr CCaalliibbrraattiioonn

For the simulations referred in this section, a part of the T2 dataset (more than 4 minutes) was used (illustrated in Figure 12 along with the estimated values for the navigation grade IMU test). Ideal (error free) GNSS measurements were used to exclusively analyse the errors inherent to the IGIN module.

(a)

(b)

(c)

(d)

Figure 12: Reference (a) trajectory, (b) change in position, (c), velocity and (d) attitude

IADIRA Final Report



44..22..22..11..11.. NNaavviiggaattiioonn ggrraaddee SSeennssoorr

A simulation was performed using a navigation grade sensor (FJI) for a medium dynamics scenario, providing evidence that:

The implemented IMU model correctly fits the observed data;

The horizontal position attitude error statistics achievable with ideal aiding and a calibrated navigation grade sensor is 0.27 meters (1 sigma);

The velocity error is 0.057 m/s (1 sigma).

Figure 13 illustrates the errors of the PVAT solution. The abrupt error increase around second 120 (particularly visible in Figure 13-d) and apparent heading drift are due to the reference trajectory contamination mentioned in §4.2.1.

(a)

(b)

(c)

Figure 13: (a) Position, (b), velocity, (c) attitude and (d) clock errors for the FJI with ideal GNSS measurements

IADIRA Final Report



44..22..22..11..22.. AAuuttoommoottiivvee ggrraaddee SSeennssoorr

Figure 14 illustrates the errors of the PVAT solution using an automotive grade sensor (SSKS), for the same scenario as in the previous section, providing evidence that:

The implemented IMU model correctly fits the observed data although the performance, when compared to the navigation grade IMU, is not as good..

The horizontal position error achievable with ideal aiding and a calibrated automotive grade sensor is 0.24 meters (1 sigma) meters and for the velocity 0.1 m/s (1 sigma).

When compared to the navigation grade sensor, the horizontal position error obtained with the automotive sensor is less stable and noisier.

The clock bias estimated by the receiver is noisier than when using the navigation grade sensor.

The abrupt error increase around second 120 (particularly visible in Figure 14-a) and apparent heading drift are due to the reference trajectory contamination mentioned in §4.2.1.

(a)

(b)

(c)

(d)

Figure 14: (a) Position, (b), velocity, (c) attitude and (d) clock errors for the SSKS with ideal GNSS measurements

IADIRA Final Report



44..22..22..22.. PPoossiittiioonn aanndd VVeelloocciittyy AAccccuurraaccyy

For the aided receiver configuration, the 0.8 meter (3-sigma) horizontal position error requirement in [AD-7] is reached for both the navigation and automotive grade sensors but only if smoothed pseudoranges are used. If unsmoothed pseudoranges are fed to the IGIN, the error in position using the automotive grade sensor rises up to 4 meters. The horizontal position error for the automotive and navigation sensors match the expected values for BOC signals (1.84 m and 0.86 m, respectively) as seen in Figure 15-a and Figure 16-a (please note the different scales).

As for the unaided receiver the horizontal position error requirements are not met when unsmoothed pseudoranges are used and although not indicated in current document the results when smoothing is used are very similar to those of the aided receiver (the superior performance of the aided receiver is most noticeable when unsmoothed pseudoranges are used, as patent in Figure 15-b and Figure 16-b).

(a)

(b)

Figure 15: Position errors for (a) aided (deeply coupled) and (b) unaided (loosely coupled) receiver with navigation grade sensor (unsmoothed PR)

(a)

(b)

Figure 16: Position errors for (a) aided (deeply coupled) and (b) unaided (loosely coupled) receiver with automotive grade sensor (unsmoothed PR)

IADIRA Final Report



Since the position accuracy is enhanced, a higher availability of accuracy is expected and therefore the system integrity availability is also increased. If smoothed PRs are used, the integrity limits are respected for both unaided and aided receivers and for both navigation and automotive grade sensors.

When using equal loop bandwidths (3Hz for the PLL and 1Hz for the DLL) the advantages of the aided receiver are clear from Figure 17 which shows the PLL filter outputs for unaided and aided receivers with an automotive grade sensor. The approximately zero mean filter outputs of the aided receiver, denoting low PLL dynamic stress, contrast with the unaided receiver’s filter outputs, in which the loop’s dynamic stress (most noticeable for the last 2 channels) depends on the difference between the real Doppler shift and the Doppler shift estimate used to perform the Doppler removal.

(a)

(b)

Figure 17: PLL filter outputs for (a) unaided and (b) aided receivers (with narrow loop bandwidths) using automotive grade sensors

For the unaided receiver, the horizontal velocity requirements are not achieved when unsmoothed PRs are used. The difference between the aided and unaided receivers in the velocity estimate is considerable as shown in Figure 18 (the error for the aided receiver is slightly above half the one for the unaided receiver).

With the aided receiver, the horizontal velocity error requirement [AD-7] of 0.55 m/s is always respected except when using the automotive grade IMU (SSKS) and unsmoothed PRs, where the horizontal velocity error occasionally reaches 1m/s errors (Figure 18-b).

IADIRA Final Report



(a)

(b)

Figure 18: Velocity errors for (a) unaided and (b) aided receiver using unsmoothed PRs and automotive grade sensors

44..22..22..33.. MMiinniimmuumm rreeqquuiirreedd CC//NN00

Although not tested using The GRANADA BT, theoretical results [AD-7] shown in Figure 19 suggest that tracking can be performed down to at least 23dB-Hz for a PLL bandwidth of 12Hz. This constitutes a gain of more than 20dB-Hz when compared to the unaided receiver in the same conditions. Tracking under 24dB-Hz has been tested using the intermediate model with a PLL bandwidth of 3Hz.

12 13 14 15 16 17 18 19 20

20

25

30

35

40

45

Bandwidth (Hz)

C/No min (dB-Hz)

No Aiding

(a)

2 4 6 8 10 12 14 16 18 2016

17

18

19

20

21

22

23

24

25

26

Bandwidth (Hz)

C/No min (dB-Hz)

Low CostAutomotiveTacticalNavigation

(b)

Figure 19: Minimum C/No for (a) unaided and (b) aided receivers for different PLL bandwidths

44..22..22..44.. LLoooopp bbaannddwwiiddtthh rreedduuccttiioonn

Loop bandwidths have been successfully reduced from 18Hz to 3 Hz, for the PLL, and from 4 to 1Hz, for the DLL, still enabling signal tracking for the aided receiver. For these bandwidth values, tracking was unstable or not possible when aiding was not available.

IADIRA Final Report



44..22..22..55.. PPoossiittiioonn aanndd VVeelloocciittyy AAccccuurraaccyy uunnddeerr SSiiggnnaall BBlloocckkaaggee

Full and partial (1 out of 4 satellites) outage of 20 seconds (from second 25 through second 45) was simulated with the IADIRA Test-Bench.

For the navigation grade IMU, in a full outage situation, the theoretical time before reaching the positioning integrity alarm limit of 2.5m (train control application) is around 70 seconds (Figure 20-a). Only 10s were obtained during simulation. This discrepancy may be due to the error in the PRs fed to the IGIN at the time of the outage start.

Regarding the automotive sensor, an also in a full outage situation, the expected time before alarm is 10 seconds (Figure 20). The time obtained in the simulations exceeded this expectation (12 seconds) possibly due to the good quality of the sensor calibration.

As for the partial outage, with both the automotive and navigation sensors the 2.5 meters limit was never reached within the 60 second simulation.

As for the cross track alarm limit of 1.5m, the results were inconclusive.

0 10 20 30 40 50 60 7010

-2

10-1

100

Drift Time [s]

Position Error [m]


(a)

0 10 20 30 40 50 60 70 80 90 100

10-3

10-2

10-1

100

Drift Time [s]

Velocity Error [m]


(b) Figure 20: Expected (a) position and (b) velocity errors VS Drift time

For the full outage, the velocity performance was fully compliant with the requirement for the navigation and automotive grade sensors.

Regarding the Doppler requirements, for the navigation grade IMU, the 0.52Hz (0.1m/s) requirement is not achieved. The standard deviation of the Doppler error varies between 0.3 and 0.6 Hz (the first value corresponding to satellites with a C/N0 of 37dB-Hz). For the automotive grade IMU, the Doppler error was observed to increase with time during the outage, exhibiting an error between 2.5 Hz and 5.2 Hz. Therefore the requirement is not met for this sensor. Note however that these results are for smoothed PR measurements and, if carrier smoothing is used, the requirement is expected to be reached as illustrated in Figure 21 (worst case), where for a simulation for 100 seconds using ideal GNSS the Doppler error standard deviation is seen to be under 1.5 Hz.

IADIRA Final Report



Figure 21: Error and Standard Deviation using automotive grade sensor for SV14 for a 100s

simulation with ideal GNSS measurements

If the Doppler threshold is changed from 0.5Hz to 1.5Hz, the time to reach it increases to 6 seconds for the automotive sensor and more than 20 seconds for the navigation sensor (threshold not reached within the signal outage period), as seen in Figure 22.

(a)

(b)

Figure 22: Doppler Error for (a) automotive and (b) navigation grade IMUs during full outage of 20s (starting at t=25s)

44..22..22..66.. RReeaaccqquuiissiittiioonn aafftteerr OOuuttaaggee

In Figure 23-a it is observable the difficulty that the PLL of the unaided receiver has while trying to converge after a full outage. The receiver is not able to maintain lock of the carrier phase for two of the channels (3rd and 4th channels) at least until the end of the simulation. Cycle slips keep accumulating for these channels and, consequently, the carrier phase estimate keeps diverging even after the outage has ended.

The DLLs also have trouble keeping lock. In fact, for the 3rd and 4th channels, after the outage the DLL locks in a secondary autocorrelation peak leading to a biased and noisier pseudorange estimate (Figure 23-b). This is due to the multi peak correlation function of BOC modulations (as is the case for the

IADIRA Final Report



Galileo L1 signal, which has BOC(1,1) modulation). Special tracking algorithms adapted for BOC signals (such as the bump-jumping technique) must be implemented to overcome this inconvenience.

If the navigation grade IMU is used to aid the GNSS receiver, after the outage has ended carrier lock is declared in less than 0.6s for the worst case. Code lock is declared in less than 0.35s and the DLLs remain locked on the main autocorrelation peak.

If the automotive grade IMU is used, DLL lock is declared in less than 0.35s after the outage has ended. As for the PLLs, they have some difficulties reacquiring lock due to the degraded Doppler estimate at the end of the outage resulting from the new convergence period of the filter (Figure 24).

(a)

(b)

Figure 23: (a) PLL discriminator outputs and (b) pseudorange error during full outage simulation for unaided receiver

Figure 24: Doppler estimate error for the aided receiver, with automotive grade IMU,

during full outage of 20s (starting at t=25s)

44..22..22..77.. CCaarrrriieerr aanndd CCooddee PPhhaassee EErrrroorrss

For the unaided receiver configuration the achievable pseudorange error standard deviation using unsmoothed PRs varies between 1.1m and 2m.

IADIRA Final Report



For the aided receiver configuration using unsmoothed PRs, the achievable pseudorange error standard deviation is similar if navigation or automotive grade sensors are used and varies between 0.7m and 1.2m (an almost 6dB gain with relation to the unaided case), as can be seen in Figure 25. If smoothed PRs are used, the error range drops to about 7mm to 20mm (an additional gain of 20dB or more).

For the carrier phase error, although the standard deviation values of the error are very similar for the aided (with unsmoothed PRs) and unaided cases (between 2mm and 20mm), for the unaided case it is noticeable a higher frequency noise due to the wider loop bandwidth (Figure 26-a). For the aided case, a low frequency noise dominates (Figure 26-b). This noise is due to the quality of the aiding signal, which produces small transients in the PLL at the IGIN-BT interface rate. However, this is only true if the navigation grade sensor is used. In the case of the automotive grade sensor, these transients may sometimes produce cycle slips and prevent the correct tracking of the carrier phase. If smoothed PRs are used, this problem ceases to exist.

(a)

(b)

Figure 25: Pseudorange error for an (a) unaided receiver and (b) an aided receiver with an automotive grade IMU and using unsmoothed PRs

(a)

(b)

Figure 26: Carrier phase error for an (a) unaided receiver and (b) an aided receiver with a navigation grade IMU and using unsmoothed PRs

IADIRA Final Report



The dynamic stress on the DLL when aiding is not available can be clearly observed in Figure 27-b. The approximately zero mean filter outputs of the aided receivers (Figure 28), denoting low PLL dynamic stress, contrast with the unaided receiver’s PLL filter outputs, in which the loop’s dynamic stress (most noticeable for the last 2 channels) depends on the difference between the real Doppler shift (Figure 27-a) and the Doppler shift estimate used to perform the Doppler removal (assumed constant since the acquisition to tracking transition).

It is also clear in Figure 28 the difference in magnitude and duration of the transients produced by the Doppler estimates update at the start of each second. As expected, these updates produce worst results when calculated based on the automotive grade IMU measurements (Figure 28-b).

(a)

(b)

Figure 27: Reference Doppler shift and PLL filter output for an unaided receiver

(d)

(d)

Figure 28: PLL filter output for aided receiver using (a) navigation and (b) automotive grade sensors

IADIRA Final Report



44..22..22..88.. VVeelloocciittyy AAccccuurraaccyy ffoorr DDoopppplleerr SShhiifftt EEssttiimmaattiioonn

Even if smoothed PRs are used, the requirements of 0.5Hz as maximum Doppler shift error are not reached when the SSKS IMU is used. The reported standard deviation varies between 0.34Hz and 0.87Hz. The errors, when PRs are not smoothed, fall between 0.9Hz and 2Hz. The worse performing channels are those with satellites in lower elevation angle and, consequently, smaller C/No.

For the FJI IMU with unsmoothed PRs, the standard deviation of the Doppler error is between 0.7Hz and 1.17Hz. With smoothed PRs, this range drops to 0.24 Hz to 0.62Hz. However, Doppler requirements are still not reached. Increasing the number of satellites in view would probably result in a more accurate PVT solution and the 0.5Hz requirement could become achievable.

Simulations indicated that, for an aided receiver with an automotive grade sensor and using ideal (error-free) GNSS measurements, the Doppler error limit should be between 1 and 1.5Hz. If instead a navigation grade sensor is used, then the Doppler limit of 0.5 Hz can be kept.

44..22..22..99.. TTrraacckkiinngg CCaappaabbiilliittyy aass aa FFuunnccttiioonn ooff RReecceeiivveerr CClloocckk

The use of TCXO oscillators introduces an additional error source that will have as consequence an additional component for the PLL and DLL tracking loops to follow and therefore requiring longer times for loop convergence and stabilisation. According to [AD-12] for the TCXO a minimum 1Hz bandwidth for the DLL is necessary to meet the requirements therefore the PLL and DLL in IADIRA receiver have been dimensioned to account for such error. In Figure 29 it can be observed the clock bias evolution and the correspondent estimate produced by the IGIN.

The OCXO oscillator type was not tested in IADIRA, although it is expected to have less impact on the pseudoranges (smaller error contribution) and eventually allow further reducing of the bandwidth of the tracking loops.

Figure 29: Clock bias and estimate for a TCXO clock

44..22..22..1100.. CCyyccllee SSlliipp RRoobbuussttnneessss Although not tested using GRANADA, the mean time to cycle slip (MTCS) was calculated for a first order loop Costas PLL and for the different types of IMUs. Figure 30 illustrates the cycle slip probabilities for different C/N0, inertial sensors as well as for the case of the unaided receiver (static and under 1g acceleration). The bandwidth used for the PLL was 3Hz for the aided receiver and 18Hz for the unaided receiver. It can be seen the increase in performance when aiding is used. Such improvement

IADIRA Final Report



can be indeed very useful when carrier smoothing is performed since the number of filter resets will be reduced resulting in more continuous availability of usable measurements by the navigation filter.

20 22 24 26 28 30 32 34 36 38 4010-16

10-14

10-12

10-10

10-8

10-6

10-4

10-2

100

C/No (dB-Hz)

Pro

babi

lity

of C

ycle

Slip

in 1

sec

ond

Low CostAutomotiveTacticalNavigationUnaided no dynUnaided dynamic

Figure 30: Probability of cycle slips for different sensor types and for (static and

accelerating) unaided receiver

IADIRA Final Report



44..33.. TTeecchhnnoollooggyy TTrraannssffeerr

44..33..11.. AApppplliiccaabbiilliittyy ttoo TTaarrggeett AApppplliiccaattiioonn aanndd UUsseerr TTeerrmmiinnaall The selection process of the optimal user terminal applicable to IADIRA results from the intersection of different factors that lead to the IADIRA enabled application.

Type of applications where IADIRA can be used,

Simulation campaign results,

Positioning Techniques,

Terminals characteristics and configuration.

IADIRA enabled application

IADIRA List of Potential Application

Positioning Techniques

Simulation Campaign Results

Terminal Types

Figure 31: Selecting IADIRA enabled applications

The most adequate Galileo User Segment Terminal (GUST) applicable to the IADIRA selected target application is the SoL and Professional since both are able to deliver better performance and provide the potential to adequately support different configurations for a wide variety of applications that can benefit from the inertial aiding techniques.

The most adequate positioning technique to obtain 0.26m (1 sigma) horizontal position error and 0.5 m/s (under 50Km/h) would be the combined GPS + Galileo using phase smoothed code measurements and automotive sensor with local elements providing differential corrections. Other less demanding applications would require different receiver configurations and positioning techniques but as stated previously, this procedure can be applied.

According to the test campaign results and considering the required positioning technique, user requirements, cost, and Integration of IAC GNSS navigation into target application architecture (ERTMS/ETCS level 3) the most adequate user terminal would be B.2 and, in case certification is required, C.1 (see Table 9).

IADIRA Final Report



Receiver Market Category

Market Specific Characteristics ID Configuration Frequency

Bands

B.1 Single Frequency Galileo & GPS + LE; (Precision) w/o Integrity

E5* , L5

B.2 Dual-Frequency Galileo & GPS + LE; (Precision) w/o Integrity

E5* + L1, L5 + L1,

AltBOC(E5) +L1

B.3

Triple Frequency Galileo & GPS + LE, (High-precision) w/o Integrity

E5+E6+L1,

L5+L2+L1

Professional

Single or Multi frequency, cost driven, low volume; high performance

B.4

Single Frequency Galileo & GPS + comm. assistance; (Precision) w/o Integrity

E5a, L5

C.1

Dual-Frequency Galileo & GPS + LE (+EGNOS), (Precision) w/ Integrity

E5a/E5b + L1,

L5 + L1

AltBOC(E5) + L1 Safety of Life

Double/ Multi frequencies, requirements driven, low volume, high performance, high reliability; strict certification requirements C.2

Triple Frequency Galileo & GPS + LE (+EGNOS) (High-Precision) w/ Integrity

E5a/E5b+E6+L1

L5+L2+L1

*- Either E5a or E5b signals can be used.

Table 9: Receiver Configurations and Market Characteristics

The inclusion of an IMU within the GNSS antenna mount in a deeply integrated architecture helps to improve the performance, availability and integrity of the GNSS solution. In addition, a navigation grade IMU may be setup in the train; and can be used to keep the accuracy under long term under full satellite blockage (e.g. long tunnels).

The main advantages of the deep integration of an IMU with GNSS [AD-7] in the selected target application include:

Acquisition and tracking of weaker signals - If the INS is used to estimate the Doppler shift, the tracking loop bandwidths can be reduced generating less noisy carrier and code phase measurements. This allows the receiver to operate under more demanding conditions such as under dense foliage and urban environments thus improving the availability of the GNSS system;

Navigation with less than 4 satellites in view - When less than four satellites are available (3, 2 or 1) the KF is still able to produce a valid solution based on the remaining PR and CF observations. Even when no satellites are in view, the inertial system can be temporarily used to provide a navigation solution. This also improves the availability of the solution and the integrity of the system;

IADIRA Final Report



Nearly instant reacquisition after signal blockage – during a partial or full SiS blockage, the Doppler aiding signals can be used to drive the tracking loops (coasting) and preclude the need for code reacquisition;

Increased robustness to interference - This is another outcome of the narrower bandwidths

Increased robustness to cycle slips - The INS can aid cycle slip detection because it can make a correct estimation of the Doppler shift and the carrier phase in the PLL therefore increasing integrity and availability;

Increased precision and accuracy – Finally, assuming that the calibration of the INS has been performed correctly by the KF and taking into account that the position noise introduced by the INS is smaller that the noise introduced by the GNSS it is possible to improve the precision and accuracy of the navigation solution.

44..33..22.. TTeecchhnnoollooggyy PPrroovviiddeerr AAccttiivviittiieess DEIMOS has been actively involved in Galileo receiver development activities and therefore enjoys both network and knowledge of European industry players in GNSS receivers while Institute of Geomatics is an European centre of excellence with recognised expertise on inertial sensors and laboratory facilities. Together, DEIMOS and the Institute of Geomatics make up an ideal team for further developments and technology transfer steps.

Several commercial contacts have been performed during the project that gave prospects for commercialisation of project outcomes.

Additionally, with the recent commercialisation of GRANADA, a new opportunity for exploring IADIRA as an additional tool-box has emerged, therefore potentially granting access to market segment of users involved in integrated inertial-GNNS systems.

In order to protect project outcomes the project consortium decided to initiate the patent process after a preliminary patent search. The exclusive right provided by a patent may be crucial for the technology transfer process since it will provide:

Strong market position and competitive advantage: patent gives its owner the exclusive right to prevent or stop others from commercially using the patented invention, thereby reducing uncertainty, risk and competition from free riders and imitators.

Return on Investment: To have a return and recovering costs of R&D activities.

Income from licensing or assigning the patent: A patent owner may license rights over the invention to others in exchange for lump-sum payments and/or royalties. Selling a patent implies transfer of ownership whereas licensing implies only permission to use the licensed invention under specific conditions.

Access to technology through cross-licensing: In case of interest in technology owned by others, it is possible to use the patent to negotiate cross-licensing agreements, by which both parties agree to authorize each other to use one or more respective patents under specific agreed conditions.

Access to new markets: licensing of patents (or even pending patent applications) to others may provide access to new markets, which are otherwise inaccessible.

IADIRA Final Report



Diminished risks of infringement: obtaining protection enables to prevent others from patenting the same invention and also reduce chances of infringing the rights of others when commercialising products.

Enhanced ability to obtain grants and/or raise funds at a reasonable rate of interest.

A powerful tool to take action against imitators: Owning a patent considerably improves the ability to take successful legal action against copiers and imitators of the protected invention.

Positive image for the company: Patent portfolios demonstrate the high level of expertise, specialisation and technology capacity to costumers, partners, investor and shareholders.

Once the technology is adopted (or imminent) by the technology consumer, assistance needs to be provided. In the case of the test-bench this can be done simply by providing SW documentation relevant for the user to gain adequate understanding of the SW operation. In the case of receiver technology and inertial sensor, this can be achieved with the provision of engineering or scientific consulting services to organisations wishing to adopt the technology either by Institute of Geomatics or DEIMOS.

A critical factor in the technology transfer is the dissemination of project results, further detailed in §4.3.3, that would help technology consumers to identify the technology.

44..33..33.. DDiisssseemmiinnaattiioonn AAccttiivviittiieess This section briefly resumes the outcomes of WP5300, “Dissemination of Results”, and provides a list of the products associated with technology transfer activities. Such technology transfer products are, in the IADIRA case, the outputs produced as part of the dissemination plan.

The dissemination activities within IADIRA project aim at projecting an international visible R&D project. The main dissemination activities are included in the following categories:

Presentation of IADIRA project and scientific results to international congress:

• Galileo SME work-shop,

• ION GNSS 2006 [RD-10],

• NAVITEC,

• Geomatic Week,

• Other future workshops and courses (specialised workshops, courses and tutorials organised by the IG and/or DEIMOS).

Promotion of project results through other communication channels :

• Matlab story use case of GRANADA,

• Individual presentations to industry in general,

• Internal Publications (IG),

• Poster,

• User Manual.

On site demonstrations.

Compilation of scientific paper and communications:

• CDROM compilation of most relevant data from IG and DEIMOS has been performed.

IADIRA Final Report



55.. CCOONNCCLLUUSSIIOONNSS AANNDD RREECCOOMMMMEENNDDAATTIIOONNSS

Inertial Aiding and Coasting using lower cost sensors deeply integrated in GNSS receivers is a promising technology that definitely opens the door for innovative applications.

IADIRA has demonstrated the potential of such technology by having developed a dedicated test-bench for a hybrid Galileo-INS system, using the GRANDA Bit-True simulator deeply integrated with a GNSS-INS navigator. Tests conducted with this hybrid receiver have shown main benefits in terms of:

Carrier and code noise (noise reduction when compared to unaided solution);

Position and velocity accuracy (accuracy increase when compared to unaided solution);

Minimum required C/N0 for successful tracking (possible operation under lower C/N0 when compared to unaided solution);

Reacquisition time (faster or even instantaneous reacquisition of signal lock when compared to unaided solution);

Overall system robustness.

Therefore, the overall system integrity and position accuracy, not only applicable to train control applications but to other equally demanding applications (where conventional GNSS or unaided solutions fail), is increased when deep integration (level 4) is used.

Despite the fact that additional challenges still remain, the IADIRA Test-Bench and the experience acquired during the IADIRA project execution indicate and recommend a very promising way forward:

Conduct additional (and more extensive) testing activities in more diverse and harsher environments allowing to further highlight the possible achievements using deep integration as well as fine tune or further development of algorithms (e.g. GNSS outage detector, INS aligner, etc.);

Test lower cost sensors since, in IADIRA, the main effort was dedicated to automotive type sensors, which although low cost when compared to navigation grade could still be too expensive for mass-market applications.

Industrialise the IADIRA concept: find partnerships and potential technology consumers that could benefit from this technology and would like to adopt the IADIRA concept, taking advantage of the IADIRA project outcomes.