In a first for any satellite navigation system, Galileo has achieved the first position fix based on navigation signals carrying authenticated data, according to the European Space Agency.
Galileo’s Open Service Navigation Message Authentication (OSNMA) is intended as a way to combat malicious spoofing of satnav signals.
OSNMA receivers successfully calculated an OSNMA-protected position fix after Galileo satellites started transmitting authentication data at 15:28 UTC on Nov. 18, 2020. The first tests used eight Galileo satellites for around two hours on Nov. 18. Tests have continued ever since, for intermittent periods, and will continue over the next months ahead of a public observation phase.
The first authenticated signal position, velocity and timing fixes were made using a total of eight Galileo satellites for around two hours on Nov. 18, 2020. The tests represent a first proof-of-concept for an eventual operational service offering positioning with authenticated data to users. (Image: ESA)
Pioneering a long-awaited service
The Galileo OSNMA authentication mechanism allows GNSS receivers to verify Galileo information, making sure that received data are indeed from Galileo and not modified in any way.
“Ensuring the validity of positions elaborated by GNSS is one of the main challenges before addressing an entirely new set of applications demanding dependability and resilience,” said Matthias Petschke, director of space at the European Commission, DG DEFIS. “Galileo is now set on course to deliver on this highly anticipated feature and has many more novel features in store for the coming years.”
Testing is taking place at ESA’s Navigation Laboratory at ESTEC in the Netherlands, the same site where the first Galileo positioning fix took place in 2013.(Photo: ESA)
Increased robustness
OSNMA test signals are being broadcast by the Galileo constellation using the spare bits from the current navigation message, therefore not impacting the legacy OS receivers implementing the current OS Signal-In-Space Interface Control Document (OS SIS ICD).
“Galileo’s Open Service Navigation Message Authentication is one of its key differentiators,” said Rodrigo da Costa, executive director of the European GNSS Agency. “The additional robustness that it will provide to the Galileo signal will be critical for many applications, particularly those where security and trustworthiness are a priority, making the OSNMA a key component in any resilient PNT solution.”
OSNMA works on a comparable basis to everyday encryption, where sending a digitally signed document involves both sender and recipient using compatible cryptographic keys (private and public) to validate the document’s source of origin.
“Up until now, as a navigation satellite disseminates navigation and timing data, there is no way of confirming these data are indeed coming from their apparent originator,” explained Paul Verhoef, director of navigation at the European Space Agency. “As a result, the data could be falsified, a phenomenon known as spoofing, where corrupt false signals mislead receivers about their position, misleading their users in turn, with potentially serious consequences.”
An ESA Navigation Directorate team at the ESTEC technical centre in the Netherlands worked with their European GNSS Agency (GSA) counterparts at the twin Galileo Control Centres in Italy and Germany and the Galileo Service Centre (GSC) in Spain to develop and test the OSNMA.
Next steps
Upon successful completion of the internal testing phase, a public observation phase will begin, in which the OSNMA signal will be publicly accessible. In preparation for this phase, the OSNMA user Signal-In-Space Interface Control Document (OSNMA SIS ICD), receiver implementation guidelines, and the necessary cryptographic materials will be published. This will allow receiver manufacturers and application developers to test and prepare their products.
During the public observation phase, feedback will be gathered from users, leading to the consolidation of the service.
Testbed vehicle by ESA’s Navigation Lab. (Photo: ESA)
Yury Urlichich, First Deputy Director General, Roscosmos. (Photo: Roscosmos)
By Yury Urlichich, First Deputy Director General of ROSCOMOS State Space Corporation Sergey Karutin, Designer General of GLONASS Nikolay Testoedov, Director General, Information Satellite Systems
Roscosmos keeps concentrating on user needs as it did in previous years. Growing digitalization is driving a high demand for high-accuracy navigation services. Space information technologies support user needs by modern digital services, including increasing accuracy of position and velocity determination. Because of this, it is of vital importance for us to ensure that GLONASS provides continuous services and stable performance.
Figure 1. Mature Glonass-M satellites show improved cesium frequency standards performance in terms of daily stability. (Image: Roscosmos)
Performance Standard & ICD
This year, we finished drafting the GLONASS Open Service Performance Standard (GLONASS OS PS; the Russian language version is available). In 2020, the new version of the GLONASS Interface Control Document (ICD) also will be publicly available.
GLONASS OS PS serves as a high-level mainframe document specifying the values of the achieved GLONASS performance characteristics plus the significant guaranteed margin. These, coupled with the signal reception environment and a priori estimation of user equipment performance characteristics, can further be translated into the performance that an end user can expect to achieve in his specific PVT solution.
This GLONASS OS PS is a basis for certification of GLONASS services and development of lower level standards for user receiver and GLONASS-based service, as well as for development of international standards like those of the International Civil Aviation Organization (ICAO), the International Maritime Organization (IMO) and others.
Use of the unified set of performance parameters and calculation methods for all GNSS — GLONASS, GPS, Galileo and BDS — is a conventional practice. The similar standards for GPS, Galileo and BDS have been published and are regularly updated.
In fact, this GLONASS OS PS is the second one after the ICD baseline interface between GLONASS and user receiver manufacturers and the GLONASS-based services developers. The OS PS establishes the minimum performance that can be achieved by users with a high level of trust based on the system’s long-term statistical history.
Signal-in-Space. This OS PS specifies standards for the GLONASS OS Signal-in-Space (SIS) performance neglecting receiver biases, signal propagation and reception biases (in terms of performance metrics used to specify system performance, that is, taking into account the GLONASS space segment and the GLONASS ground segment contributions to the performance). It can serve as a basis for certification of the GLONASS-based services and receivers incorporating GLONASS, including those used in aviation and other user domains.
The OS PS provides an overview of the GLONASS system and an overview of the GLONASS Open Service SIS. It specifies the standards for the performance characteristics of the channel of standard accuracy used to provide the Open Service, and lists the legal reference documents.
L3 CDMA. One of the most significant tasks is the harmonization of GLONASS user interfaces with respect to new L3 CDMA signals. The requirements related to the interface between the space segment of GLONASS and the navigation user segment for radio frequency links is established by the GLONASS ICDs.
The new version of ICD for CDMA L1, L2 and L3 signals to be broadcast by new-generation Glonass-K2 satellites was issued in 2016. However, the Glonass-M satellites (## 755-758) and the Glonass-K satellites currently in orbit transmit the L3 signal as per the L3 Open Access CDMA Radionavigation Signal Interface Control Document (Edition 1) of 2011.
In order to mitigate the above-mentioned discrepancies, five reference documents (Interface Control Documents for open-access signals) have been updated and prepared for publication. In addition, flight tests to verify new ionospheric and tropospheric delay models have been scheduled.
Incorporating More Data
The new ICDs for open access and authorized signals incorporate changes related to the introduction of additional data into the spare bits of the navigation message. This additional data is to be used by user receivers for better PVT solution purposes.
The updated versions of ICDs will incorporate:
The mathematical ionospheric delay model and inclusion of the model parameter into the navigation message.
The mathematical tropospheric delay model, which does not require that any specific parameters be included into the navigation message. It only employs data on the latitude of a user receiver location and the season (i.e., winter, spring, summer, and autumn).
The attribute (or flag) to inform a user that a satellite is in the turn mode and its antenna phase center behavior is different from that when a satellite is in the sun orientation mode.
Information about the types of signals broadcast on the L1, L2, and L3 frequencies; 5-bit field, in which the first three bits denote L1, L2, and L3 CDMA signals, respectively, while the 4th and the 5th bits denote L1 and L2 FDMA signals, respectively.
A 5-bit field to be used to broadcast age of data (AOD) for time offsets in addition to the similar field used to broadcast AOD for ephemerides.
Backward Compatibility. The updated CDMA and FDMA ICDs will support the backward compatibility for the uninterrupted operation of the existing envelope of user equipment and the introduction of the ionospheric and tropospheric model parameters into the message spare capacity.
Constellation Refresh
The GLONASS constellation has been replenished steadily. Since 2013, we have been launching one to two satellites a year, and this year is not an exception. The launch on May 27 and the December launch will help sustain the nominal constellation. The Glonass-M satellites demonstrate good dynamics for the average operational life. Two satellites are well beyond their 10-year design life — their operational lifetime has exceeded 12 years. As some of the Glonass-M satellites grow older, their cesium frequency standards performance in terms of daily stability improves (see Figure 1).
Glonass-K. In 2020, the launch campaign for the Glonass-M satellites will come to its end. The Glonass-K satellites will come on stage with the first launch of Glonass-K-15 scheduled for the beginning of the next year. We are fully confident that this satellite will not disappoint our users.
By Javier Benedicto
Head, Galileo Programme department,
European Space Agency
Javier Benedicto, left, accept the 2018 GPS World Satellites Leadership Award on behalf of Giuliano Gatti of the European Space Agency, from Phil Froom of Rockwell Collins. (Photo: Melanie Beus)
Since the Galileo initial services declaration in December 2016, the Galileo Program has been providing global PNT and search-and-rescue services for users worldwide. The European GNSS Agency (GSA) just issued its GNSS 2019 Market Report in October, providing a complete overview of the current status and trends of the GNSS worldwide market with focus on European GNSS (Galileo and EGNOS) applications and services.
In parallel with service provision, the Galileo Program is undertaking extensive infrastructure development and deployment activities to reach Full Operational Capability (FOC), incorporating new service capabilities, but above all aiming at increasing the robustness and resilience of the system infrastructure, operations and service provision.
Galileo’s signal-in-space quality has steadily improved over the past few years, reaching in 2019 a best signal-in-space error (SISE) of about 0.25 meters (95%, global average; Figure 1). This has been achieved through a combination of several factors, including the increased number of operational satellites, enhanced versions of the Ground Mission Segment, and higher uplink rate of the navigation message (lower age of data). This performance is well within Galileo’s initial service accuracy commitments, as defined in the public Open Service – Service Definition Document (OS SDD).
Figure 1. Long-term historical SISE plot over a 30-day sliding window, constellation averaged. (Image: ESA)
Figures 2 and 3 (see page 40) show Galileo’s timing performance as broadcast UTC offset and GGTO accuracy. The evaluation was performed with calibrated GPS/Galileo timing receivers operated in UTC(k) laboratory (PTB, INRIM). Again, the initial timing service commitments have been fully met.
Probably the most significant discriminator of Galileo compared to other GNSS is its capability to broadcast multi-frequency (E1, E6, E5) signal components on all operational satellites. The position performance of a dual-frequency user receiver on-ground is shown in Figure 4. This measurement from June 2019 demonstrates a Galileo position accuracy well below 2 m (95%).
Figure 4. Galileo position accuracy performance, dual-frequency, June 2019. (Image: ESA)
With the aim of further improving the Open Service (OS) performance, three newly introduced I/NAV message improvements on Galileo E1-B are under implementation, namely FEC2 Reed-Solomon Clock and Ephemeris (CED), Reduced CED, and Secondary Synchronization Pattern (SSP). Galileo Open Service (OS) users will benefit from improved robustness in terms of navigation data retrieval in challenging environments, in addition to facilitating a reduced time to first fix. Those I/NAV improvements on Galileo E1-B are backwards compatible with previously released OS SIS ICDs.
In addition, Galileo infrastructure is currently being upgraded to provide means for OS authentication. The protocol proposed uses the E1B External Data Broadcast Service (EDBS) to provide authentication data to the user. The OS Navigation Message Authentication (NMA) is based on an adaptation of the Timed Efficient Stream Loss-tolerant Authentication (TESLA) protocol.
Beyond the OS, the Galileo system has been designed to allow for the dissemination of value-added data, such as high accuracy and authentication, in the E6B signal component. The component has been designed to broadcast the Galileo High Accuracy Service based on the provision of accurate satellite data (clocks, orbits and biases) and atmospheric data (mainly ionospheric corrections) to enable multi-frequency multi-constellation PPP with correction data transmitted through an open format in the Galileo E6B signal.
The introduction in early 2020 of the automatic acknowledgment of the SAR/Galileo Return Link Message (RLM) as part of the Cospas-Sarsat system will enable space assets to be used for search and rescue — persons in distress will get swift acknowledgement that their alert has been detected and located. The Return Link is the means to interact with a SAR beacon, improving the effectiveness of SAR operations. Extensive testing has demonstrated that the median latency for the reception of a return link message on the ground is 14.2 seconds, while 99% of messages are received within 57 seconds, after the request for the RLM transmission is delivered to Galileo (from Cospas-Sarsat to the RLSP). At the same time, the measured rate of reception was 100%, considering line-of-sight availability, thanks to the very robust Galileo navigation data link. This performance has been demonstrated to be uniform across the globe, as shown in Figure 5.
Figure 5. Beacon activation map and RLM delivery latency through the Galileo system. (Image: ESA)
Following the re-profiling of the Galileo Safety-of-Life (SoL) service, Galileo is meant to be exploited through dual-frequency multi-constellation (DFMC) SBAS and will support the provision of integrity through the concept of Horizontal Advanced Receiver Autonomous Integrity Monitoring (H-ARAIM). To allow the exploitation of Galileo for these SoL applications, a thorough analysis of the actual signal-in-space (SiS) performance and of potential feared events critical for SoL users is key. In this context, the Galileo Integrity Failure Mode and Effect Analysis (IFMEA) process is implemented through measurements and review of the system design, including feared-events characterization.
Ground Segment Brings Robustness
Galileo telemetry and telecommand ground station. (Photo: ESA)
Galileo’s Ground Segment is being upgraded to fully redundant control centers. These include processing and storage, monitoring and control facilities, and security monitoring centers. A worldwide network of Galileo Sensor Stations (GSS) allows monitoring and measuring of satellite signals; uplink stations allow dissemination of the navigation message to users through Galileo satellites; and telemetry, tracking and control (TTC) stations allow monitoring and control of the satellites.
Ground segment upgrades under production by Thales Alenia Space France (in charge of the ground mission segment and security monitoring) and GMV Spain (in charge of the ground control segment) are addressing increased service robustness, through the introduction of a more flexible infrastructure with a significant technology refresh, improved security, service continuity, enhanced service performances, and enhanced operability features.
One important objective of the ongoing upgrades is to implement a modern infrastructure, based on leading virtualization technologies. This modernized infrastructure will make it possible to easily accommodate hardware and software changes without requiring significant redesign or requalification, and will minimize the impact to Galileo service operations — under responsibility of Spaceopal GmbH — during future deployment activities.
Batch 3, Ariane 6 Under Production
Ariane 6 on the launchpad. (Artist’s concept: ESA)
The production of Batch 3 of 12 additional Galileo FOC satellites is proceeding, aiming at readiness for launch by the end of 2020 onward. The satellite design includes a selected number of improvements compared to the 22 FOC satellites launched previously and built by the same satellite manufacturer OHB Systems.
The different stages of assembly, integration and initial test phase in the OHB production plant in Bremen have already started, before shipment to ESA-ESTEC in the Netherlands for the environmental test campaign consisting of thermal vacuum, mechanical tests, interface verification with the launcher and system end-to-end performance tests with the elements of the Galileo ground segment.
Following the phasing out of the Ariane 5 SE launcher, the third batch of Galileo satellites will be progressively launched with the new Ariane 62 launcher vehicle, the two solid-booster variant of Ariane 6 now in the final stages of development.
Evolution to Meet User Needs
The Galileo Second Generation roadmap has achieved maturity in 2019 and is now entering the preliminary design and implementation phase. Based on the EU’s H2020 Galileo Second Generation activities managed by ESA, and the GSA prospective market analysis, the European Commission, in close consultation with EU member states, has agreed on an ambitious set of long-term PNT goals for the future European GNSS infrastructures.
Technology pre-developments, critical engineering activities and synergic design activities between space and ground infrastructure are being conducted. This will translate into the progressive deployment of a complete set of space/ground infrastructure that is tailored to satisfy the diversified user needs in four main dimensions:
Satellite and ground segment infrastructure with capabilities that can dynamically adapt to current and future user needs. Key drivers are flexibility and robustness, ensuring fast time to market to meet user needs.
Full synergy between GNSS and SBAS systems infrastructure, to complement and enhance the service portfolio. This will allow segmentation and complementarity of safety-critical services and extension to all new PNT services available today, including high-accuracy positioning integrity.
Enhanced integration with terrestrial systems — 5G/6G, signals of opportunity (SOOP), terrestrial beacon systems (TBS). ESA and GSA have been actively leading the 5G positioning standardization worldwide in collaboration with public and private institutions inside 3GPP and will soon move toward the start of standardization of 6G terrestrial positioning and GNSS interconnection technologies.
Full complementarity with external sensors (such as INS, barometer and lidar) and application environments (low-power devices and internet of things) so that the Galileo Second Generation Infrastructure enhances and complements the capabilities provided by these external means.
A key pillar for this long-term strategy is the Galileo transition satellites. The competitive procurement procedure for the first batch of transition satellites is coming in 2020. The flexibility and robustness of these satellites will allow the European PNT infrastructure to satisfy all the different user needs in the next decade. This procurement — together with others at system, ground segment and technology level — will enable the start of the in-orbit validation of second-generation capabilities from 2025 onward.
Additional ground and test infrastructure are in early engineering analysis, design and technology development, in order to proceed with additional procurements for experimental and operational usage, starting early in the 2020s.
The Air Force has issued a Federal Register Notice regarding an upcoming Public Interface Control Working Group (ICWG) meeting, set for September 24-25. Here is the notice:
Public ICWG Announcement—2013
This notice informs the public that the Global Positioning Systems (GPS) Directorate will be hosting a Public Interface Control Working Group (ICWG) meeting for the NAVSTAR GPS public signals in space (SiS) documents and ICD-GPS-870; IS-GPS-200 (Navigation User Interfaces), IS-GPS-705 (User Segment L5 Interfaces), IS-GPS-800 (User Segment L1C Interface), and the Navstar Next Generation GPS Operational Control Segment (OCX) to User Support Community Interfaces (ICD-GPS-870). Dates and times can be found below.
The purpose of this meeting will be twofold: (1) To resolve the comments against the public signals-in-space (SiS) documents with respect to the six issues outlined below, and (2) to collect issues/comments outside the scope of the issues outlined below for analysis and possible integration into the following release. The ICWG is open to the general public. For those who would like to attend and participate in this ICWG meeting, we request that you register no later than August 6, 2013. Please send the registration to [email protected] or [email protected] and provide your name, organization, telephone number, address, and country of citizenship.
Please note that the Directorate’s primary focus will be the disposition of the comments against the following GPS related topics:
1. L1C Week Number of Operation (WNOP)
2. Removal of Obsolete Information from the Public Signals-in-Space (SiS) Documents
3. CNAV Reference Times
4. PRN Mission Assignments 211-1023
5. CNAV Broadcast Intervals
6. Document Baseline for User Community & Zero AOD User Interfaces
All comments must be submitted in Comments Resolution Matrix (CRM) form. These forms along with the Was/Is Matrix, current versions of the documents, and the official meeting notice will be posted at http://www.gps.gov/technical/icwg/.
Comments outside the scope of the above issues will be collected, catalogued, and discussed during the public ICWG as potential inclusions to the version following this release. If accepted, these changes will be processed through the formal Directorate change process for IS-GPS-200, IS-GPS-705, IS-GPS-800, and ICD-GPS-870.
There will also be a special topic that will be discussed at the Public ICWG.
1. Adjacent Band Compatibility (ABC) Study Group Kickoff
Please provide comments in the CRM form and submit to the SMC/GPER mailbox at [email protected] or to Mark Marquez at [email protected] by August 7, 2013.
Public Interface Control Working Group Meeting (ICWG)
Date(s) and Times: 24-25 Sep 2013 (0800-1700) (Pacific Daylight Time P.D.T)
Dial-in Information and Location: 1-800-366-7242, Code: 1528652
Address: SAIC Facility 300 North Sepulveda Blvd, 2nd Floor, Conference Room
2060 El Segundo CA 90245
* Identification will be required at the entrance of the SAIC facility (Passport, state ID, or Federal ID). SAIC Facility phone number: 310-416-8300.
A New Approach to the Design and Development of Global Navigation Satellite Systems
By Daniele Gianni, Marco Lisi, Pierluigi De Simone, Andrea D’Ambrogio, and Michele Luglio
INNOVATION INSIGHTS by Richard Langley
MY FIRST DEGREE is in applied physics from the University of Waterloo. Founded in 1957, Waterloo was one of the first universities to introduce co-operative education. Co-operative education (or “co-op” as it is commonly known) is a program that uses both classroom study and temporary jobs to provide students with practical experience. Applied Physics was a co-op program and I worked in both industry and research environments including stints at Philips Electronics and the Atomic Energy of Canada Limited’s Chalk River Laboratories.
Both on campus and on the job, I met fellow co-op students from a variety of disciplines including mathematics (computer science) and various branches of engineering. One of those was systems design engineering or systems engineering for short. At that time, I really didn’t know much about systems engineering except that it was an all-encompassing branch of engineering and the most challenging of all of the engineering programs at Waterloo — at least according to the students in the program.
Systems engineering is an interdisciplinary field of engineering focusing on the design and management of complex engineering projects. According to the International Council on Systems Engineering, systems engineers establish processes “to ensure that the customer and stakeholder’s needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system’s entire life cycle. This process is usually comprised of the following seven tasks: State the problem, Investigate alternatives, Model the system, Integrate, Launch the system, Assess performance, and Re-evaluate [or, SIMILAR, for short].”
Central to the systems engineering process and the end-product design is the generation of models. Many types of system models are used, including physical analogs, analytical equations, state machines, block diagrams, functional flow diagrams, object-oriented models, computer simulations, and even mental models. (If you want to learn a bit about mental and other kinds of models, including how to fix radios by thinking, you could do no better than to look at some of Richard Feynman’s writings including the eminently readable “Surely You’re Joking, Mr. Feynman!”: Adventures of a Curious Character.)
As aids to the modeling process, systems engineers have developed specialized modeling languages including the Unified Modeling Language (UML) and the Systems Modeling Language (SysML). These are graphical-based languages that can be used to express information or knowledge about systems in a structure that is defined by a consistent set of rules. Both UML and SysML are widely used in systems engineering. However, both are limited when it comes to representing the signal-in-space (SIS) interfaces for global navigation satellite systems.
In this month’s column, a team of authors affiliated with the Galileo project discusses the Interface Communication Modeling Language, an extension of UML that allows engineers to clearly represent SIS interfaces, critical for the design of GNSS receivers.
“Innovation” is a regular feature that discusses advances in GPS technology andits applications as well as the fundamentals of GPS positioning. The column is coordinated by Richard Langley of the Department of Geodesy and Geomatics Engineering, University of New Brunswick. He welcomes comments and topic ideas. To contact him, see the “Contributing Editors” section on page 4.
In this article, we present the results of ongoing research on the use of a modeling language, namely Interface Communication Modeling Language (ICML), for signal-in-space (SIS) interface specification of global navigation satellite systems (GNSS). Specifications based on modeling languages (also known as model-based specifications) have proven to offer a wide range of benefits to systems engineering activities, for supporting system interoperability, reducing design risk, automating software development, and so on. We argue that similar benefits can be obtained for satellite navigation systems and receivers, if a model-based approach is used for defining and expressing the SIS interface specification. In particular, we outline how a model-based SIS interface specification can support the identification of solutions to two key issues: GNSS interoperability and the design of GNSS receivers, particularly Galileo receivers. Both issues are becoming increasingly central to the Galileo program since it entered the In-Orbit-Validation (IOV) phase and is steadily approaching the 2014 milestone, when the first early services — the Open Service (OS) and the Search and Rescue Service — will be provided to users.
GNSS interoperability concerns the integration of different GNSS with the purpose of being used together, along with regional positioning systems, to provide a seamless navigation capability and improved services in terms of availability, continuity, accuracy, and integrity, for example. GNSS interoperability should be addressed in terms of intra-GNSS interoperability and GNSS-receiver interoperability. The intra-GNSS interoperability concerns the data exchanged among the GNSS, including coordination to guarantee data coherence and consistency over time. For example, GNSS may need to share terrestrial reference frames and constantly synchronize their global time references. On the other hand, GNSS-receiver interoperability concerns the capability of the receiver to use independent GNSS signals for the computation of positions globally. This capability implicitly requires that the receiver computations are decoupled from the SIS interface of any particular GNSS. A key condition to achieve this decoupling is that the SIS interface specification is available in a consistent, unambiguous, and possibly standard format, which can support engineers to more effectively design interoperable receivers. A model-based SIS interface specification would considerably facilitate this as it enables designers to use the processing capabilities of a computer system for the verification of the specification consistency and completeness, for example. Moreover, a model-based SIS interface specification would ease the visual and electronic inspection of the data messages, therefore facilitating the automatic identification of different data representations for the same orbital and temporal parameters.
The design of GNSS receivers, and particularly those for Galileo, is increasingly of interest, and a model-based SIS interface specification can similarly support the definition of future solutions. For Galileo, specifically, the receiver design is critical to support the marketing strategies that are promoting the use of Galileo services. Key issues underlying any marketing strategy concern the Galileo receiver market appealing from a cost-to-performance ratio point of view. As Galileo receivers may require new design and adaptation of existing software (SW) or hardware (HW), as well as new production chains, higher costs — in particular non-recurring ones — are likely to occur for the production of the Galileo receivers with respect to the well-established GPS receivers. As a consequence, limitations may be experienced in market penetration and in the growth velocity of Galileo receivers’ share of the receiver market. In turn, this may hinder the estimated economic return for the Galileo project.
Preventing and counteracting this possibility is therefore a critical issue if we aim to achieve the widest possible success of the Galileo project. Market barriers inherently originate from the following needs:
Designing new SW and HW solutions for Galileo receivers;
Reusing existing SW and HW for GPS receivers;
Converting existing production chains to the new Galileo-specific SW and HW solutions.
GNSS receivers often use established mathematical models that can determine the receiver position from a fundamental set of parameters, such as satellite orbit and system time. As a consequence, the intrinsic representation of the parameter set is a major factor in the adaptation of the existing design and implementation of SW and HW solutions.
To reduce the impact of the above needs, a model-based SIS interface specification may play a pivotal role in several ways, such as:
reducing ambiguities in the Galileo SIS interface specification;
enhancing the communication with the involved stakeholders;
linking the SIS interface specification to the design schemas of GNSS receivers — particularly Galileo ones — for tracing the interface elements onto the receiver functional and physical schema, thereby supporting the reuse and adaptation of existing HW and SW solutions;
supporting the model-based design of security solutions for blocking, jamming, and spoofing.
Galileo Project
In October 2012, the final two IOV satellites were launched into orbit, completing the designed configuration for the Galileo IOV phase — the initial stage of the Galileo constellation development. In this phase, preliminary validation tests will be performed and the initial navigation message will be broadcast to the Galileo ground segment for further validation. Shortly after the conclusion of this phase, a series of launches will take place to gradually deploy the remaining 26 satellites that will form the Galileo Full Operational Capability (FOC) configuration. Currently, the Galileo Early Open Service (EOS) is expected to be available by the end of 2014. The EOS will provide ranging capabilities and will enable receiver manufacturers to begin to design and test their technological solutions for Galileo receivers and Galileo overlay services, such as search and rescue.
In the meantime, the European GNSS Agency has been established and assigned the governance of the Galileo sub-systems, including activities such as:
initiating and monitoring the implementation of security procedures and performing system security audits;
system infrastructure management, maintenance, improvement, certification, and standardization, and service provision;
development and deployment of activities for the evolution and future generations of the systems, including procurement activities;
contributing to the exploitation of the systems, including the marketing and promotion of applications and services, including market analysis.
With the now-rapid development of the Galileo project, it becomes increasingly important to support the receiver manufacturers in the design and implementation of global navigation solutions based on the Galileo services. This is necessary to guarantee the widespread use of the Galileo services, particularly in an increasingly crowded GNSS panorama.
Model-Based Systems Engineering
Model-based systems engineering (MBSE) is predicated on the notion that a system is developed by use of a set of system models that evolve throughout the development lifecycle, from abstract models at the early stages down to the operational system. A visual presentation is provided by FIGURE 1, which shows the roles of MBSE approaches within the systems engineering V-shaped process. Specifically, the MBSE approaches enable the designer to effectively trace the requirements and design alternatives on the descending branch of the “V.” For the same characteristics, MBSE facilitates the verification through a model repository that interconnects not only the design products, but also the stakeholders involved in the entire process. In addition, MBSE approaches support the automatic generation of the documentation and of other artifacts, particularly software. All of these capabilities eventually enable the validation of the implementation activities on the ascending branch of the V-process. Also, in this case, MBSE and the model repository play a major role in connecting design to implementation, and users and designers to developers.
FIGURE 1. Systems engineering V-process supported by an model-based systems engineering with model repository (courtesy of the INCOSE Survey).
Main Concepts. MBSE approaches are gaining increasing popularity with the widespread adoption of standard modeling languages, such as Unified Modeling Language (UML) and Systems Modeling Language (SysML).
UML is a formally defined general-purpose graphical language and is mainly used in the context of software systems development. It has been developed and is being managed by the Object Management Group and is the core standard of the Model Driven Architecture (MDA) effort, which provides a set of standards to shift from code-centric to model-driven software development. By use of an MDA-based approach, a software system is built by specifying and executing a set of automated model transformations.
SysML is defined as an extension of UML and provides a general-purpose modeling language for systems engineering applications (See FIGURE 2). SysML supports MBSE approaches in the development of complex systems that include hardware, software, information, processes, personnel, and facilities.
FIGURE 2. UML-SysML relationships. (UML 2 is the second generation version of UML introduced in 2005.)
Advantages. With respect to the conventional document-based approaches, MBSE approaches present the following advantages:
Conformance to standard specifications and availability of development tools;
Increased level of automation due to the formal specification and execution of model transformations that take as input a model at a given level of abstraction and yield as output a refined model at a lower level of abstraction;
Better understanding of the system in its operational context;
Support for simulation activities at different levels of detail and at different development stages, from concept exploration to dynamic system optimization;
Support for the coherent extension of standard modeling languages to adapt them to a specific target or domain.
These capabilities have motivated and have been sustaining an increasing trend of moving from document-centric to model-centric systems engineering.
ICML Language
UML and SysML are widely used languages for MBSE. A plethora of tools and technologies are available to compose models, transform models into documents, derive software products from models, and share and reuse models by means of repositories. However, neither of these languages offers capabilities for the representation of SIS interfaces, which are the critical interfaces for the design of Galileo receivers. For this reason, we have introduced ICML: a modeling language that can enable a full MBSE approach for the design of Galileo receivers. Moreover, ICML extends UML, and therefore it can integrate with system specifications based on compliant technologies as well as be used within standard tools.
Layout of Interface Specification. The typical layout of ICML-based interface specification is shown in FIGURE 3. The specification covers the definition of both the message structure and conversion processes. The message structure consists of five abstraction levels, and describes how the data is structured within the message. The conversion processes describe how the data values are transformed between adjacent levels of the message specification.
FIGURE 3. Layout of ICML-based interface specifications.
The message structure is defined at five levels: Data Definition, (Logical) Binary Coding, Logical Binary Structure, Physical Binary Coding, and Physical Signal, each covering specific aspects of the SIS interface specification.
For example, the Data Definition level covers the specification of the logical data structure, which includes the data items composing the message information. A data item is either of application or control type. An application data item represents a domain-specific concept that conveys the information expected by the message recipient. On the other hand, a control data item represents a domain-independent concept that can support the correctness and integrity verification of the associated application data items. A data item can also be associated with semantic and pragmatic definitions. The former specifies the meaning of the data item and the latter specifies the contextual interpretation for the semantic definition.
Analogously, the Binary Coding level covers the specification of the binary coding for each of the data items defined at the above level. For a data item, the binary coding is represented as a binary sequence and it includes at least a sequence identifier, the semantic definition, and the pragmatic definitions. Similarly to the above level, the semantic and pragmatic definitions enrich the interface specification, conveying an accurate representation of the binary coding.
The conversion processes describe the activities to be performed for deriving message values between adjacent levels of the above structural specification. As shown in Figure 3, eight processes should be defined to specify all the conversions between adjacent levels. For example, the DataDefinition2BinaryCoding process defines the activities to be performed for the derivation of the logical binary sequences representing data values. Similarly, the LogicalBinary2PhysicalBinary process defines the activities for the implementation of convolution or encryption algorithms on the logical binary sequence. However, these processes do not always need to be explicitly defined. In particular, if the implementation of a process is trivial or standard, a textual note referring to an external document may suffice for the specification purposes.
The first prototypal version of ICML has been implemented and can be used within the open source TopCased tool. The prototypal version is available under the GNU General Public License (GPL) v3.0 from the ICML project website. We applied the profile and developed the example ICML-based specification given below.
Galileo-Like Specification. An ICML-based specification of a Galileo-like OS interface, concerning only the above-defined level 3, would display as shown in FIGURE 4. This figure specifically details a part of a reduced F/NAV (the freely accessible navigation message provided by the E5a signal for the Galileo OS) structure consisting of one data frame made up of two F/NAV subframes.
FIGURE 4. Example of ICML-based specification of an F/NAV-like message structure at the Logical Binary Coding level.
Benefits. ICML can bring the above-mentioned MBSE benefits to support GNSS interoperability and to GNSS and Galileo receiver design. For example, ICML can:
provide a reference guideline for structuring the specification data and thus facilitating the communication between the Galileo SIS designers and the receiver producers;
ease visual inspection of the specification for verification purposes and for the identification of data incompatibilities of two GNSS systems;
convey the data semantics as well as the measurement units, to guarantee that the binary data from different GNSS are correctly decoded and interpreted;
support syntactical model validation using existing tools;
provide support for future advance exploitation by means of a machine-readable data format.
In particular, the availability of a machine-readable format is also the basis for advanced use cases that can exploit the capabilities of modern computer technologies.
Advanced Future Use Cases. In line with the above-mentioned MBSE model exploitations, we foresee a number of possible exploitation cases:
Automatic generation of the interface specification documents;
Collaborative development of the interface specification;
Automatic completeness and consistency checking of the interface specification;
Integration of SIS specifications with model-driven simulation engineering approaches for the simulation of single- and multi-GNSS receivers;
Integration of SIS specifications with receiver design models in SysML, for requirements traceability and reuse of existing GNSS solutions.
The automatic generation of interface specification documents can be an important capability during the lifecycle of a specification. For example, the specification may be updated several times during the interface design, and the textual documentation may need to be produced several times. Using a model-based approach, it is possible to automate the error-prone activities related to the document writing as well as other important functions such as specification versioning.
Complex system specifications are often the product of collaborating teams, which may occasionally be geographically dispersed. Using a model-based approach, the interface specification can be stored within a version control system that can be concurrently accessed by team members.
Completeness and consistency checking is also a manual activity, which demands a high degree of mental attention, and it is consequently highly error prone. Once the specification is available in a machine-readable format, the checking can be easily automated by specifying the verification rules that the interface model must satisfy.
Existing technologies support the simulation of single- and multi-GNSS receivers. As the SIS specification has a major impact on the internal structure of the receiver, the interface specification is a key input for developing GNSS simulators as well as for determining the boundary properties of the input signal into the receiver, including the admitted analog signal and the format of the digital data.
Moreover, the model-based interface specification can be integrated with a receiver design schema in SysML. This would be important to provide traceability between the interface requirements and the receiver’s functional and physical components. In the following section, we provide an outline for a preliminary integration between the interface specification and the receiver design.
Designing Galileo Receivers
Model-based interface specifications can support the design of Galileo receivers in several ways. For example, a specification can provide a link between Galileo requirements down to the Galileo receiver specifications, as shown in FIGURE 5.
FIGURE 5. Links between ICML and SysML specifications.
This capability may be useful in several scenarios. In particular, we have identified three scenarios. Scenario 1 consists of the identification of the receiver requirements that are introduced or modified by the Galileo OS SIS, with respect to existing GPS receivers. Scenario 2 concerns the linking between the ICML specification and the receiver functional schema to identify how a Galileo receiver will differ from existing GPS solutions. Scenario 3 is a development of Scenario 1 and Scenario 2, in which the physical schema definition and the physical components identification (HW and SW) may further exploit the ICML-based approach for supporting the reuse of existing GPS components.
Below, we detail Scenario 2, introducing a simplified receiver functional schema in SysML and linking the above ICML example to the schema.
Example Functional Schema. In this section, we illustrate a preliminary SysML representation for a simplified GNSS receiver. However, the figures are meant for exemplification purposes only and are not to be considered fully realistic and detailed for real GNSS receivers. Nevertheless, the SysML hierarchical modeling capabilities can be used to further refine the model, up to a potentially infinitesimal level of detail.
A GNSS receiver functional schema has been derived from A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach (see Further Reading) and its equivalent SysML internal block diagram (IBD) is shown in FIGURE 6.
In particular, the IBD illustrates the functional blocks (instances and types) and connections among these blocks that define the GNSS receiver. In particular, each of these block types is also described in other diagrams, in which the designers can specify the operations performed by the block, the attributes of the block, the referred properties, and the defined values, for example.
In this short article, we have particularly focused on the navigation data decoder. The data decoder is defined by a Block Definition Diagram (BDD) and an IBD, which are shown in FIGURES 7 and 8, respectively.
FIGURE 7. Navigation data decoder block definition diagram.FIGURE 8. Navigation data decoder internal block diagram.
In particular, the BDD indicates that the navigation data decoder is composed of four types of blocks: shift buffer, parity checker, binary adder, and data item retriever. The shift buffer receives the incoming physical sequence of bits, which is subsequently verified by the parity checker. The verified sequence is then processed to retrieve the standard binary format from the SIS-specific logical coding for the data item. This function is guided by the data item retriever, which stores the defined properties of each incoming data item, in the form of a physical sequence of bits (level 1). As a consequence, the navigation data decoder is involved with data defined at several of the above-defined ICML levels. From this description, it is also possible to sketch the preliminary IBD diagram of Figure 8.
Using a model-based approach, it becomes easier to establish links between interface elements and the functional blocks in the receiver schema.
Moreover, these links can also be decorated with a number of properties that can be used to further describe the type of the relationship between the interface element and the functional block. The link identification is important to the receiver design in several ways. For example, linking the interface elements to the receiver functional blocks, it becomes easier to identify which functional blocks are affected by each element of the SIS interface. Moreover, the tracing can be transitively extended to the physical schema, enabling the receiver designers to more immediately identify which physical components can be reused and which ones must be replaced in existing GNSS solutions.
We exemplify the tracing of interface elements on the above data decoding functional schema in FIGURE 9. This figure shows the navigation data decoder’s BDD in conjunction with ICML level 3 elements (with a white background). As in Figure 7, the relationships are drawn in red, including a richer set of relationship qualifiers. For example, the <<use>> qualifier indicates that the originating block uses the data specified in the connected ICML element. Similarly, the <<consumes>> qualifier indicates that the originating block takes in input instances of the ICML element. ICML level 4 elements are also relevant to this BDD; however, they are not shown for the sake of conciseness.
FIGURE 9. Linking level 3 elements to the navigation data decoder block definition.
Conclusions
Galileo receivers may face market barriers that are inherently raised by the costs linked with the introduction of new technologies with respect to the existing GPS ones. In this article, we have advocated that a model-based SIS interface specification can help mitigate possible extra costs in several ways. For example, the model-based interface specification can ease the communication among stakeholders, promote the reuse and adaptation of existing GPS software and chipsets, and support the implementation of receiver-side multi-GNSS interoperability. With the objective of supporting model-based interface specifications, we have designed ICML, which has been provided with a UML profile implementation in an open-source modeling tool. We have also shown an excerpt of a possible model-based specification for a simplified Galileo OS interface. Moreover, we have outlined how the model-based specification can integrate with SysML models of GNSS receivers and support the reuse and adaptation of existing solutions. A preliminary identification of potential exploitations and further benefits is also included. Further research is ongoing to generalize the existing ICML language to more complex types of SIS interfaces.
Acknowledgments
The authors would like to thank the students Serena Annarilli and Carlo Di Bartolomei (University of Rome Tor Vergata) for implementing the first prototype version of the ICML profile. The authors would also like to thank Marco Porretta, European Space Agency (ESA) / European Space Research and Technology Centre (ESTEC), for the suggestions of the GNSS example. The ICML project has been partially sponsored by the ESA Summer of Code in Space Initiative, edition 2012. No endorsement is made for the use of ICML for the official Galileo SIS interface specification.
DANIELE GIANNI is currently a requirement engineering consultant at EUMETSAT in Germany. EUMETSAT is the European operational satellite agency for monitoring weather, climate and the environment. Gianni received a Ph.D. in computer and control engineering from University of Rome Tor Vergata (Italy), in the field of modeling and simulation, in 2007. He has previously held research appointments at ESA, Imperial College, and Oxford University.
MARCO LISI is currently GNSS services engineering manager at ESA’s Directorate of Galileo Programme and Navigation- Related Activities at ESTEC in Noordwijk, The Netherlands. He was previously responsible for system engineering, operations, and security activities in the Galileo project. He is also a special advisor to the European Commission on European space policies. Lisi has over thirty years of working experience in the aerospace and telecommunication sectors, holding management positions in R&D, and being directly involved in a number of major satellite programs, including Artemis, Meteosat Operational, Meteosat Second Generation, Globalstar, Cosmo-Skymed, and more recently Galileo.
PIERLUIGI DE SIMONE is currently working on system assembly, integration, and verification for the Galileo mission in ESA. He has worked on many software developments in the fields of graphics, safe mode software, and visual programming. He has worked on many space missions including Helios, Meteosat, Metop, Cosmo-Skymed, and Galileo. His main interests are in modeling paradigms and cryptography and he holds a master’s degree in physics from University of Rome Tor Vergata.
ANDREA D’AMBROGIO is associate professor of computer science at the University of Rome Tor Vergata. He has formerly been a research associate at the Concurrent Engineering Research Center of West Virginia University in Morgantown, West Virginia. His research interests are in the areas of engineering and validation of system performance and dependability, model-driven systems and software engineering, and distributed simulation.
MICHELE LUGLIO is associate professor of telecommunication at University of Rome Tor Vergata. He works on designing satellite systems for multimedia services both mobile and fixed. He received the Ph.D. degree in telecommunications in 1994.
FURTHER READING
• Interface Communication Modeling Language (ICML)
“A Modeling Language to Support the Interoperability of Global Navigation Satellite Systems” by D. Gianni, J. Fuchs, P. De Simone, and M. Lisi in GPS Solutions, Vol. 17, No. 2, 2013, pp. 175–198, doi: 10.1007/s10291-012-0270-z.
• Use of ICML for GNSS Signal-in-Space Interface Specification
“A Model-based Signal-In-Space Interface Specification to Support the Design of Galileo Receivers” by D. Gianni, M. Lisi, P. De Simone, A. D’Ambrogio, and M. Luglio in Proceedings of the 6th ESA Workshop on Satellite Navigation Technologies and European Workshop on GNSS Signals and Signal Processing (NAVITEC), Noordwijk, The Netherlands, December 5–7, 2012, 8 pp., doi: 10.1109/NAVITEC.2012.6423066.
“A Model-Based Approach to Signal-in-Space Specifications for Designing GNSS Receivers” by D. Gianni, J. Fuchs, P. De Simone, and M. Lisi in Inside GNSS, Vol. 6, No. 1, January/February 2011, pp. 32–39.
• Related Modeling Languages
The Unified Modeling Language Reference Manual, 2nd edition, by G. Booch, J. Rumbaugh, and I. Jacobson, published by Addison-Wesley Professional, an imprint of Pearson Education, Inc., Upper Saddle River, New Jersey, 2005.
A Practical Guide to SysML: The Systems Modeling Language, 2nd edition, by S. Friedenthal, A. Moore, and R. Steiner, published by Morgan Kaufman and the Object Management Group Press, an imprint of Elsevier Inc., Waltham, Massachusetts, 2012.
• Systems Engineering
Systems Engineering: Principles and Practice, 2nd edition, by A. Kossiakoff, W.N. Sweet, S.J. Seymour, and S.M. Biemer, published by John Wiley & Sons, Inc., Hoboken, New Jersey, 2011.
A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach by K. Borre, D.M. Akos, N. Bertelsen, P. Rinder, and S.H. Jensen, published by Birkhäuser Boston, Cambridge, Massachusetts, 2007.
• Galileo Status and Plans
“Status of Galileo” (Galileo System Workshop) by H. Tork in the Proceedings of ION GNSS 2012, the 25th International Technical Meeting of the Satellite Division of The Institute of Navigation, Nashville, Tennessee, September 17–21, 2012, pp. 2474–2502.
“Galileo Integrated Approach to Services Provision” (Galileo System Workshop) by M. Lisi in the Proceedings of ION GNSS 2012, the 25th International Technical Meeting of the Satellite Division of The Institute of Navigation, Nashville, Tennessee, September 17–21, 2012, pp. 2572–2596.
