Scientists in Hanoi, Vietnam, send word that on March 27 the four Galileo in-orbit validation satellites were visible at the same time in the sky over that Southeast Asian country for nearly two hours (from 2:15 to 4:00 GMT) while transmitting a valid navigation message.The research team of the NAVIS Centre at Hanoi University of Science and Technology (HUST) successfully computed what they claim is the first Galileo-only position fix in Asia.
Figure 1 depicts the obtained positions are depicted on top of the roof of the NAVIS Centre, where the antenna used to receive the signals is located (latitude = 21°00’16.69” N, Longitude = 105°50’37.90” E, height = 35,2 meters).
Figure 1. Positions obtained by only Galileo E1 Open Service (the antenna is located at the roof of the Ta Quang Buu library building inside HUST campus)
Figure 2 shows the positions of the four Galileo satellites and of 12 GPS satellites at time of acquisition, while Figure 3 reports the acquisition results of the four Galileo IOV satellites.
Figure 2. Skyplot of the satellites of the GPS and Galileo systems at the time of the campaign. The Galileo satellites are PFM (PRN11), FM2 (PRN12), FM3 (PRN19), and FM4 (PRN20).Figure 3. Acquisition results of the four Galileo IOV satellites: PRN 11.Figure 3. Acquisition results of the four Galileo IOV satellites: PRN12.Figure 3. Acquisition results of the four Galileo IOV satellites: PRN19.Figure 3. Acquisition results of the four Galileo IOV satellites: PRN20.
Comparison of the position computed using only Galileo, only GPS or both systems together is also presented in Figure 4. It should be noted that during the campaign, the data demodulation process reports that the Galileo system announces the “navigation data valid” status for PFM and FM3, meanwhile the “working without guarantee” for FM2 and FM4.
Figure 4. Position computed when using GPS only, Galileo only, or GPS+Galileo
The NAVIS Centre, located at the Hanoi University of Science and Technology in Hanoi, Vietnam, was established with a project co-funded by the European Union and collaborates with European and Asian partners on research and development of satellite navigation technology in Southeast Asia. This report was made by Dr. Ta Hai Tung, director of the NAVIS Centre, and Prof. Gustavo Belforte, co-director.
It’s been a long time coming. With the capability to make a position fix from four signal-broadcasting satellites, we can now say that Galileo has truly arrived. Of course, this is only one of many milestones (excuse me, kilometer markers) along the way, a trajectory that could be bounded at 23 years and counting, or possibly longer. Let’s not forget, GPS had an extended gestation period of its own, as did GLONASS; BeiDou appears to be maturing a bit faster.
My acquaintance with the system began in July 2000, when I joined the staff of GPS World and received my first assignment, editing an article about GPS-bearing carrier pigeons in the sister publication Galileo’s World, from founding editor Glen Gibbons. We published Galileo’s World quarterly from 2000 to 2002, chronicling the ups and downs, forward steps and back, of the European GNSS. Unless you counted EGNOS — really telecom satellites with a piggyback SBAS payload — Galileo had no space vehicles as yet, but did encompass plenty of political and financial maneuvering, rhetoric, market projections, international negotiations, and technical blueprints. In short, the stuff of news. For application stories in the magazine, we filled with European uses of GPS, all of which would eventually integrate Galileo as well.
In 2002, a UK-based travel agency of the same name began to assert its legal possession of the name Galileo, and sent a cease-and-desist shot across the bows to the corporate ownership of the two magazines, and to the European Union. The EU felt it had sufficient legal clout or standing of some kind, for it neither desisted nor renamed its space program. But our counsel at the time instructed us to quietly fold up our tent and steal away. The impending battle wasn’t worth our stake.
And so Galileo’s World sadly ceased publication. Not for lack of interest, or support, or commitment. But because of someone else’s greed or turf belligerence in a completely unrelated market. Such is the way of the global economy.
We have covered every step of Galileo’s way, technically, economically, and politically, in the pages of GPS World. Occasionally we ponder calling ourselves GNSS World, or even PNT World. But the brand, like the satnav system it is named after, is just so strong, it would be foolhardy to walk away from it, at this point in time at least.
We continue to support European satnav progress at each successive stage. And so we say yet again: Welcome, Galileo!
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.
OS for Improved Accuracy, EDAS for Further Enhancement, Integrity Data
EGNOS availability over Europe, as a precursor of Galileo globally, provides a guaranteed level of positioning accuracy in real time, for tracking vehicles transporting hazardous material. The EGNOS Open Service enhances position accuracy compared to GPS-only. The EGNOS Data Access Service further enhances accuracy and indicates the quality of the position data received from GPS. As a result of the SCUTUM project, EGNOS is now used in the operational transport of dangerous goods by road in Europe.
By Antonella Di Fazio, Daniele Bettinelli, and Kyle O’Keefe
The road sector is among the largest markets for GNSS applications, not only in automotive mass-market but also in professional applications such as freight transport and logistics. Carrying goods by road naturally involves the risk of traffic accidents. If the goods are dangerous, there is also the risk of incidents, such as hazardous spills, fire, explosion, chemical burn, or environmental damage. The many different kinds of authorities and operators active in the field have safety as a primary concern and make continuous efforts in this regard. To ensure that such transport continues being profitable and logistically effective, emphasis is placed on the quality and condition of infrastructure, on transport safety, and on supervision and control.
Technology’s role, particularly that of GNSS, is to provide the capability of supervision and surveillance, and thus enable better incident management and proactive prevention of accidents, while enhancing work. Use of GNSS combined with sensors and wireless devices has rapidly increased to enable continuous tracking and tracing services. GNSS-tracking devices installed on board vehicles ensure that the position, the date and time, the speed and the course, and any deviation with respect to a predefined path (coordinates and time) are transmitted automatically to a monitoring center. Combined with sensors, such devices send positioning information and the critical status parameters of the material (depending on the nature of the transported material and sensor type: identification of the goods/packaging, temperature, pressure, tampering or valve opening, and so on).
At the monitoring center, positions are displayed on digital maps, and regular data reports are processed for:
continuous tracking and tracing,
control of the shipment in a specified route (according to the plan and authorized path),
early warning/alarm when an anomaly condition is detected,
recording and logging for a regular summary of reported incidents, and
informing emergency-response forces for preparation of management arrangements and supporting emergency response plans.
These operations help reduce the possibility of human error during transport, prevent incidents, enforce regulations, and support law enforcement.
The European Geostationary Navigation Overlay Service (EGNOS), a satellite-based augmentation system (SBAS), augments the GPS signal over Europe and provides more precise positioning services. In addition, it gives users information on the reliability of the GPS signals (integrity data).
EGNOS is designed for safety-critical civil aviation operations. The characteristics of the EGNOS signal are compliant with Radio Technical Commission for Aeronautics Minimum Operational Performance Standards (RTCA MOPS) for airborne navigation equipment using the GPS augmented by SBAS. EGNOS also allows multimodal/land transport applications; however, EGNOS optimal use in these applications requires specific customizations for environments not compliant to MOPS.
The majority of receivers available on the market and integrated in operational devices are EGNOS-enabled. EGNOS provides two services suitable for multimodal/land transport applications:
EGNOS Open Service (OS) is made available to users equipped with GPS/EGNOS receivers, via the satellites’ Signal in Space (SiS).
EGNOS Data Access Service (EDAS) consists of a server that gets the data directly from EGNOS and distributes it in real time to professional users via terrestrial networks, within guaranteed delay, security, and performance.
Software solutions and technologies capable of using EDAS and able to deliver added-value services for road applications have been developed in various European projects in the past several years, have been extensively proven in real life, and are presently ready for operational use. During the last seven years, capitalizing on the efforts of national/European projects and company investments, Telespazio has developed LoCation Server (LCS) navigation software based on a patented algorithm, suitable for combined use of EGNOS OS/EDAS in road applications. LCS makes use of EDAS to augment EGNOS OS performance by:
improving the availability of EGNOS OS, since EGNOS SBAS corrections are made available to users through terrestrial networks and thus also in the cases of poor SiS visibility or complete absence;
enhancing EGNOS OS position accuracy using the patented software navigation solution to implement EGNOS SBAS corrections; and
processing EGNOS integrity information to compute the protection levels that give a qualification and a level of confidence in the position information. LCS is configured to output horizontal protection level (HPL) and vertical protection level (VPL).
Between October 2010 and November 2011, the European project SeCUring the EU GNSS adopTion in the dangeroUs Material transport (SCUTUM) conducted an extensive trial campaign in various road environments (urban and extra-urban) and real operation scenarios, to assess the performances of EGNOS OS and EDAS in comparison with GPS-only. SCUTUM trials were carried out with GPS/EGNOS receivers available on the market for automotive applications.
Analysis of the data collected during the trials shows that EGNOS OS enhances GPS position accuracy by 3 meters in road environments (see Figure 1). EDAS via LCS enables improvements over EGNOS OS by increasing the availability of SBAS corrections, further enhancing GPS position accuracy. Moreover, it affords the possibility of qualifying and guaranteeing GPS position information by exploiting EGNOS integrity and computing the protection levels.
Figure 1A. The green line indicates the reference trajectory; the position obtained by using EDAS with LCS (yellow dot) is more accurate with respect to the position obtained by using EGNOS OS (red dot) and the position obtained by using GPS only (blue dot).Figure 1B. A snapshot displaying the HPL computed by using EDAS with LCS.
SCUTUM Goods Tracking
Funded by the European Commission and managed by the European GNSS Agency (GSA), SCUTUM is the European best practice for the operational adoption of EGNOS in the transport of dangerous goods. An Italian oil company, eni, has had the opportunity to prove EGNOS added value compared to GPS alone, and to validate the relevant operational benefits in terms of higher safety and efficiency. The company adopted EGNOS to track and trace its operational fleet transporting dangerous goods throughout Europe. At the end of SCUTUM’s project timeline in November 2011, more than 300 eni tankers transporting hydrocarbon and chemical products in seven European countries were monitored with EGNOS. Today eni plans to gradually extend the use of EGNOS to the transport of chemicals and aviation products, and to further European countries.
Sensors installed on the trailer to record load status.OBU on the tanker integrating a GPS/EGNOS receiver.
The tankers (see opening photo) are equipped with GPS/EGNOS tracking devices, consisting of a set of sensors installed on the trailer to record the status of the loads. The sensors are connected to an onboard unit (OBU) installed on the truck that integrates a GPS/EGNOS receiver configured to use EGNOS OS. The OBU collects measurements from the sensors, detects information on the vehicle’s parameters, measures the GPS/EGNOS position, and sends this set of data via a GPRS link to a remote monitoring platform (the transport integrated platform, or TIP) enhanced by LCS to use EDAS. The TIP receives the data from LCS, that is, EGNOS positions (corrected by EGNOS OS if available or corrected by EDAS), the relevant HPL and VPL, and visualizes them as shown in Figure 2.
Figure 2. Operational tanker remotely monitored at the TIP by EDAS via LCS.
LCS for EDAS Services
LCS consists of several software modules, among them a module connecting to EDAS to get EGNOS data, and a module implementing the navigation solution by means of the Telespazio algorithm.
LCS makes use of EGNOS SBAS messages plus GPS ephemerides received in real time from EDAS (using Service Level 1), the positions (GPS or EGNOS OS positions when available) and time, and raw GPS measurements (code ranges) from the GPS/EGNOS receiver integrated in the OBU.
LCS calculates and returns EGNOS corrected positions (also in case of lack of SiS visibility) and the relevant protection levels obtained by processing the EGNOS integrity message. The HPL/VPL give a guarantee of the position information from the GPS/EGNOS receiver, as they qualify the reliability of position information and provide a measure of the confidence of the reliability.
If the position data from the OBU is not corrected with EGNOS OS (via the SiS), LCS uses the SBAS messages plus the GPS ephemerides, calculates and applies SBAS corrections, then calculates HPL/VPL. If the position data from the OBU is corrected with EGNOS OS (via the SiS), LCS returns only the HPL/VPL.
For remote monitoring of transported dangerous goods, the features provided by EDAS via LCS (better accuracy, higher confidence on the position, enhanced availability) are considered valuable by eni, as they enable tracking tankers more precisely and reliably along delivery routes, and also from bay to bay (Figure 3).
Figure 3. Accurate remote monitoring of a tanker in a bay area.
At the OBU, the positions are combined with other collected parameters, such as speed, engine parameters, driving parameters, loading/unloading the product on the vehicle, quantity of goods on the vehicle, product temperature and pressure, opening/closing bottom valves and manholes, opening/closing loading station. The information is sent to the TIP and visualized to the local operator, and also forwarded to the eni emergency room (shown in Figure 4) that is connected to the fire brigades and civil-protection emergency centers.
Figure 4. eni emergency room.
In an abnormal situation, such as the vehicle deviating from its planned path or being located in a dangerous/sensitive area, the local operator raises a warning and establishes a contact with the driver. If an accident occurs, an alarm is generated also at the eni emergency room responsible for emergency management and coordinating search-and-rescue operations with the proper public entities. The information is also used to keep the involved transport operator and eni’s customers informed.
Additionally, this information is stored for law enforcement and prevention purposes. Position data and parameters are analyzed to produce statistics and study cases of near-miss accidents.
Benefits generated from EGNOS lie primarily in the capability to implement more accurate risk management and to strengthen safety and prevention. The higher precision with respect to GPS alone and the location achieved by using EDAS via LCS ensure more accurate and reliable monitoring of operations in normal and critical situations, and thus are valuable for commercial purposes and safety reasons. Moreover, eni considers the position guarantee given by the protection levels useful for research on accident prevention.
Multipath-Mitigation Algorithm in LCS
SCUTUM also implemented and tested a multipath-mitigation algorithm used to enhance LCS, to further mitigate the effects of code multipath, typical of land applications. Developed in cooperation with the University of Calgary, the algorithm is based on a fault detection and exclusion (FDE) method and is designed to ensure that biased/multipath-affected observations do not contaminate the navigation solution.
As SCUTUM deals with a road transport application, the assessment targeted the HPL only. The algorithm is based on a statistical-empirical concept combining:
an FDE procedure using a statistical reliability method for the detection and removal of code-range observations corrupted by multipath; and
a field-testing procedure using the receiver under study and a geodetic-quality receiver to produce a reference trajectory.
The FDE procedure consists of sequential steps:
Computation of the navigation solution by means of a least-squares solution to obtain the calculated position, the HPL, and the residuals;
Reliability testing on the residuals, to detect the outliers (observations that contain biases and thus are considered measurements affected by multipath errors);
Exclusion of the detected outliers and re-computation of the navigation solution;
Iteration of the steps. In each iteration, the observation with the largest residual flagged as an outliner is removed.
The procedure ends once no further outliers are isolated, or the number of remaining observations is less or equal to five, or several special-case conditions occur. Outlier detection is done on the basis of a rejection threshold on the standardized residual. This rejection threshold is a parameter of the multipath-mitigation algorithm and is tuned by means of the field-test results. Additionally the multipath-mitigation algorithm behavior is a function of other parameters that depend on various factors, including satellite elevation, signal strength, and overall satellite geometry.
Field Trials
SCUTUM field trials covered several environmental conditions and LCS configurations. Tests were performed in a wide range of Italian urban and extra-urban road environments. They considered five different typical driving environments (Table 1), corresponding to different levels of GPS and EGNOS signal availability and multipath, and various vehicle speeds and dynamic characteristics, with the objective of testing the robustness of LCS’s navigation solution.
TABLE 1. SCUTUM field trials driving environments.
From a physical point of view, the presence of natural and/or artificial obstacles could lead to lack of GPS and SBAS signals, worse satellite geometry, and introduction of additional errors in the measurements due to multipath propagation effects. Urban canyons are particularly prone to such effects, although they occur also in other cases depending on the topographic characteristics of the environment. For these reasons, the trials covered all possible environments traveled by LCS users, to provide a complete technical and business analysis for each operational condition.
To accurately indentify the appropriate driving environment, trial paths were matched on clutter maps categorizing the different driving environments (as shown in Figure 5 in the example of a trial path in Rome).
Figure 5. Method for driving environment identification by means of a clutter map.
A reference trajectory, hereafter called the true path, was calculated in post-processing, through a kinematic differential GPS method, by using GPS L1 and L2 carrier-phase measurements, combined with inertial navigation system (INS) measurements.
The differential GPS L1 and L2 carrier measurements were collected with a reference receiver installed near each test location, at an inter-receiver distance not exceeding 20 kilometers. The reference receiver was geo-referenced via a dedicated GPS network solution (based on a continuous collection campaign of at least two days’ data). The combination with INS targets smooth trajectories free from jumps, even in difficult GPS environments.
The tests ran on two identical OBUs, one GPS-only and one using GPS+EGNOS. The two OBUs and the GPS/INS system were installed in a test vehicle (Figure 6) and connected to a standard GPS patch antenna for automotive applications. Two pairs of OBUs were used (Figure 7).
Figure 6. GPS/INS system installed in the vehicle.Figure 7. OBUs in test vehicle.
Test Results
The trials collected these data sets:
Raw measurements from the GPS/INS system;
Positions and raw measurements from the two OBUs, GPS and GPS+EGNOS respectively.
As mentioned, positions and raw measurements from the GPS OBU were processed by LCS’s navigation solution in three configurations:
LCS baseline, running the baseline multipath mitigation method (based on the proprietary patented algorithm);
LCS enhanced, applying the multipath-mitigation algorithm with default settings of several parameters;
LCS enhanced and tuned, applying the multipath-mitigation algorithm with tuned parameters. The tuning was obtained by applying the combined statistical-empirical concept described earlier.
Data collected during the field trials was analyzed in terms of:
average values for the horizontal navigation system error (HNSE) that is the horizontal difference of the OBU position with respect to the reference trajectory;
average values for the HPL that gives an indication of the confidence/guarantee of the position above mentioned; and
the availability of the processing of LCS’s navigation solution.
Test data was analyzed with both commercial and freely available software packages. Table 2 reports the performances of LCS in its baseline configuration for each driving environment. Table 3 reports the performances of LCS by means of the multipath-mitigation algorithm with different tunings for extra-urban and urban environments.
TABLE 2. Performances of LCS baseline for driving environments.TABLE 3. Performances of LCS enhanced by multipath mitigation algorithm with different tunings.
The results show that for the road environments tested, LCS baseline performs better than statistical FDE.
From these results, an interesting conclusion can be drawn: in the road environments tested, a traditional FDE approach is not as effective as would be expected. Specifically, the removal of observations with large residuals resulted in larger overall position errors, both before and after attempting to estimate a larger observation variance than normally used for GPS. The reason for this is that in urban environments and extra-urban road environments there is significant multipath, corrupting many observations at the same time that the number of available observations is low. The conclusion is that on average, in the environments tests, it is better to leave small, but still statistically detectable errors in the solution than to remove them and degrade the solution geometry.
The fault-detection approach will be more appropriate in a multi-constellation GNSS, and in particular in the future when Galileo satellites can be used in conjunction with GPS, resulting approximately double the satellite availability in all environments.
Table 4 summarizes average performances for GPS+EDAS using LCS baseline compared with those of the GPS-only and GPS+EGNOS.
TABLE 4. Average performances of GPS+EDAS by means of “LCS baseline” in comparison with GPS-only and GPS+EGNOS OS.
Workshop Agreement
SCUTUM also carried out a European Committee for Standardization (CEN) workshop that elaborated the CEN Workshop Agreement (CWA) 16390:2012, Interface control document for provision of EDAS-based services for tracking and tracing of the transport of goods, that is, the technical specification for development of EDAS-based products and applications.
CWA 16390 specifies:
the data (and relevant format) needed from the GPS/EGNOS receivers by the software solutions connected to EDAS, to enable the implementation of products and added value services; and
the type/format of the added value services produced by the software solutions (EDAS-based services).
The technical specification defined in CWA 16390 is architecture/technology-independent and flexible, so as to:
cope with different architectures (for example, those envisaging software solutions running in the monitoring platforms or in the OBUs); and
ensure its applicability in ITS systems and various mobility applications.
CWA 16390 was endorsed by several European stakeholders from industry, institutions, and the research sector. The Ministries of Transport in Italy and France, partners in the SCUTUM project, validated it as part of a shared vision for EGNOS adoption and exploitation. Italy’s Ministry of Transport is presently carrying out the possible evolution of CWA 16390 into an Italian standard.
Conclusions
SCUTUM represents the first step towards a larger use of EGNOS in Europe for the provision of services for road applications, and opens the market for Galileo. Its key findings are that EGNOS OS generally enhances the position measured using GPS-only in all extra-urban and urban environments. EDAS generally provides further enhancements, and also gives an indication of the quality of the position data received from the GPS.
LCS is a plug-in solution that enables easy retrofitting of existing GPS systems to use EGNOS, but optimized for road applications. By integrating it in tracking and tracing monitoring platforms and configuring the vehicle-installed OBUs, LCS enhances GPS position accuracy by approximately 4 meters and provides a level of confidence in the position information in the form of an HPL and a VPL. LCS will also improve GPS/Galileo integrated solutions when Galileo is operational. Its navigation solution will be more robust with Galileo and in general with multiple constellations, thanks to the availability of more satellites in view.
Manufacturers
A NovAtel FLEXG2-V2-L1L2 served as GPS reference with a NovAtel dual-frequency GPS-702GG antenna. An Oxford Technical Solutions RT2002 dual-frequency GPS/INS system served as rover. The two OBUs integrated a u-blox 5 GPS/EGNOS receiver. In its present configuration, LCS is connected to a dedicated GPS/EGNOS receiver, NovAtel ProPak-V3-L1 acting as EDAS back-up for robustness reasons.
Antonella Di Fazio works in the GNSS Infomobility Business Unit of Telespazio, in charge of innovative applications and services and program and technical coordinator of European R&D projects, devoted to the use of EGNOS/Galileo.
Daniele Bettinelli works in the GNSS Infomobility Business Unit of Telespazio, in charge of the specification, design and development of services based on EGNOS and EDAS, in particular for land applications.
Kyle O’Keefe is an associate professor in the Position, Location And Navigation (PLAN) group of the Department of Geomatics Engineering at the University of Calgary.
Measurements of individual Galileo horizontal position fixes performed for the first time using the four Galileo satellites in orbit plus the worldwide ground system between 1000 and 11:00 CET on Tuesday 12 March 2013, showing an overall horizontal accuracy over ESTEC in Noordwijk, the Netherlands, of 6.3 m.
Galileo Logs First Autonomous Fix; Galileo over Canada (By James T. Curran, Mark Petovello, and Gérard Lachapelle); and Indoor Nav: Early Steps towards FCC Standards
Galileo Logs First Autonomous Fix
Entitling its release “From Orbit with Love,” the European Space Agency (ESA) announced March 12 that the four current satellites of the Galileo constellation achieved their first autonomous position fix. The feat was replicated by the NavSAS group of Politecnico di Torino, by GNSS manufacturer Septentrio, and by a University of Calgrary team as the four satellites appeared over North America.
The obtained accuracy lies in the 10-meter range, according to ESA, adding that this fulfills expectations, considering the infrastructure is only partly deployed. The fix was obtained by ESA’s Netherlands navigation lab, using the four satellites, launched in October 2011 and 2012, and the Galileo programme’s ground infrastructure: control centers in Italy and Germany and a global network of ground stations.
With only four satellites for the time being, the full Galileo constellation is visible at the same time for a maximum two to three hours daily. This frequency will increase as more satellites join the constellation in orbit, along with extra ground stations coming online, for Galileo’s early services to start at the end of 2014.
With the validation testing activities under way, users might experience breaks in the content of the navigation messages being broadcast, said ESA. In the coming months the messages will be further elaborated to define the offset between Galileo System Time and Coordinated Universal Time (UTC), enabling Galileo to be relied on for precision timing applications, as well as the Galileo to GPS Time Offset, ensuring interoperability with GPS.
NavSAS Confirmation. Almost simultaneously with the ESA announcement, the NavSAS group of Politecnico di Torino and Istituto Superiore Mario Boella in Turin, Italy, also achieved a position fix using the signals of the four In-Orbit Validation satellites (PFM, FM2, FM3, FM4). NavSAS researchers computed the positions using full software receivers developed by the team.
Septentrio, Too. Septentrio became the first receiver manufacturer to report an autonomous real-time position calculation using Galileo IOV satellites with its own standard commercial receiver. The company based in Leuven, Belgium announced on March 12 that it performed standalone position calculated from in-orbit navigation messages using a standard PolaRx4 GNSS receiver equipped with commercially released firmware.
This achievement was followed by a further Septentrio release stating performance of what it believes to be the first 4-constellation PVT by a standard commercial receiver, on March 12 at approximately 10:35 UTC.
The milestone in all three accounts is that it is Galileo-only real-time positioning. Galileo positioning in post-processing mode was described by authors from the Technische Universität München and the German Space Operations Center, in a GPS World account, February 2012 issue.
Galileo over Canada
By James T. Curran, Mark Petovello, and Gérard Lachapelle
Within a day of activation over Europe, Galileo satellites were visible over North America. The PLAN Group of the University of Calgary captured and processed signals from Galileo PRN 11, 12, and 19 on E1B/C. The PLAN software GSNRx simultaneously tracked GPS L1 and GLONASS L1 for combined solutions in real time.
The Galileo navigation message on E1B stated that the satellite health status is flagged as E1BHS=3 meaning “Signal Component currently in Test” and the data validity status is flagged as E1BDVS=1 meaning “Working without guarantee.” Current Galileo-ready commercial receivers may automatically discard measurements from a satellites broadcasting such messages. Parsing the received words in the I/NAV message, more than 50 percent were of type 0, although all words (types 0 to 10) were decoded at some point during the test.
Figure 1. 2D position errors.
Data was collected using a roof-mounted NovAtel 702GG antenna and an in-house two-channel digitizing front-end clocked by a high quality OCXO, in addition to a three-channel National Instruments front-end for post-processing. The two-channel intermediate frequency data was streamed live to a laptop computer for real-time processing with GSNRx. The GPS and GLONASS signals were tracked using a Kalman-filter-based tracking strategy while the Galileo signals were tracked using a specialized data-pilot algorithm.
Pseudorange and Doppler observations were extracted from the tracking strategies at a rate of 2 Hz. Single-frequency single-point position solutions were then computed for each of the three systems, each of the three pairs of systems and for the full combined Galileo-GLONASS-GPS. In the case of the three-satellite Galileo solution, the height was held fixed. Figure 1 shows 2D position errors with respect to antenna ITRF coordinates. Departures of the solutions involving GLONASS are likely due to orbital biases, given location of Calgary with respect to GLONASS ground stations.
Figure 2. Pseudorange residuals.
Next, by fixing the known position in the solution and solving only for the three clock biases, accurate pseudorange residuals were computed and are shown Figure 2. Galileo PRN 19, launched a year later than PRN 11 and 12, exhibits larger residuals, perhaps attributable to ephemeris or orbital errors. The overall results show very good consistency of the Galileo results and the PLAN Group equipment and GSNRx receiver.
Indoor Nav: Early Steps towards FCC Standards
The Federal Communications Commission (FCC) on March 14 released two reports from its Communications Security, Reliability, and Interoperability Council (CSRIC): the “Indoor Location Test Bed Report,” and “Leveraging LBS and Emerging Location Technologies for Indoor Wireless E9-1-1.”
They report on Bay Area tests of technology from NextNav, Polaris Wireless, and Qualcomm, in four representative morphologies (dense urban, urban, suburban, rural) and various building types. They are available online, via env-gpsworld-integration.kinsta.cloud/csric, are the subject of an Expert Advice column (see page 10), and will be more fully discussed in May issue. For now, this summary from the first-named report:
“Seven location vendors/technologies began the process to demonstrate their performance indoors through the common test bed, but only three completed the process. Of these three, two technologies (AGPS/AFLT and RF Fingerprinting) are already in common use for emergency services, while the third (metropolitan beacons) is not yet commercially available. However all technologies tested demonstrated relativity high yield and various levels of accuracy in indoor environments.
“Significant standards work is required for practical implementation of many emerging location technologies for emergency services use.
“Many positioning methods require handset modifications. Integration of these modified handsets into the subscriber base, once the location technology is commercially available, will take years to complete.
“Progress has been made in the ability to achieve significantly improved search rings in both a horizontal and vertical dimension. However, even the best location technologies tested have not proven the ability to consistently identify the specific building and floor, which represents the required performance to meet Public Safety’s expressed needs. This is not likely to change over the next 12–24 months. Various technologies have projected improved performance in the future, but none of those claims have yet been proven through the test bed process. It is hoped that such technologies would be tested and validated in future test bed campaigns.”
An April 16 GPS World Webinar covers this topic with test participants. Registration is free.
ESA International Summer School on GNSS 2013 will take place this year in Davos, Switzerland, July 15-25, 2013, at the Schatzalp Snow & Mountain Resort.
Satellite navigation technology is changing all our lives — and here is your chance to gain an expert overview. This summer’s Navigation Summer School, hosted by the Swiss Space Office and the Swiss Space Center in Davos, Switzerland, will bring together top experts in the field with graduate students and young professionals. Registration is now open.
Activities equivalent to 6-7 percent of European GDP already depend on satnav services, equivalent to €800 billion in value, and Europe’s own Galileo system is anticipated to further boost satnav’s economic impact. The first four Galileo satellites are operational in orbit, with initial navigation services projected to begin at the end of next year.
But how does satellite navigation work in practice? July’s two-week International Navigation Summer School aims to give participants a comprehensive theoretical and practical overview of the field, from the basics of GNSS to signal reception and processing to determine the position-navigation-time solution.
The program is open to graduate students (with a first university degree), Ph.D. candidates, early-stage researchers and young professionals wishing to broaden their knowledge.
Lectures by internationally renowned specialists will be combined with practical exercises and lab work. Principles of project management, entrepreneurship and marketing will also be covered in detail, with the participants tasked to develop an innovation-based group project over the course of the event.
Pascal Rochat of Spectratime, CEO of the Swiss company that designed the atomic clocks at the heart of Galileo, will give the inaugural lecture.
ESA’s International GNSS Navigation Summer School takes place in cooperation with the Joint Research Center, EC, in Ispra, Stanford University, the Institut Supérieur de l’Aeronautique et de l’Espace in Toulouse, Graz University of Technology and University FAF Munich, with the support of the Swiss Space Office and the Swiss Space Center.
Bradford W. Parkinson, professor of Aeronautics and Astronautics Emeritus at Stanford University, discussed “GPS for Humanity — The Stealth Utility” at a special Smithsonian event Thursday, March 21. If you missed his talk, you can view it now on UStream.
According to the Smithsonian, for centuries, nations have invested enormous resources to determine time and place for geopolitical reasons, and their research has changed people’s view of the world. Advanced technology that was once available only to the military has become commonplace in car dashboards, cell phones and a growing number of other portable devices of daily life. The Time and Navigation exhibit explores how revolutions in timekeeping over three centuries have influenced how people find their way. It is organized into five sections: Navigating at Sea; Navigating in the Air; Navigating in Space; Inventing Satellite Navigation; and Navigation for Everyone.
Bygrave Position-Line Slide Rule.
Andrew Johnston (geographer, Center for Earth and Planetary Studies, National Air and Space Museum) gave a presentation about the exhibit at ION GNSS in Nashville, Tennessee.
In the 1970s, Parkinson was the chief architect and original program director for GPS. In his lecture, he will present the history, applications, and future of GPS and the GNSS. Central to operation of GPS is the relationship between time and navigation, and GPS will be explored in the Time and Navigation exhibit.
A Constellation of 18 by 2015, Rising to 26 by the End of That Year
An Interview with Paul Flament
Paul Flament is the European Commission Programme Manager and Head of the EU Satellite Navigation Programme Unit.
A Belgian civil engineer specialized in telecommunications, he previously worked for 11 years in the European Space Agency, for space missions control centers and for the design and development of telecommunication satellites. After obtaining a master’s degree in European Studies, he joined the European Commission in 1998.
On the occasion of this special Europe/Galileo issue of the magazine, he speaks to GPS World readers regarding the present and promising future of the European GNSS.
Alan Cameron (AC): Can you recap for us briefly the upcoming satellite launch schedule that will take Galileo to Initial and then to Full Operating Capability?
Paul Flament (PF): It’s very simple. The first two in-orbit validation satellites were launched in October 2011, the next two on October 12, 2012. Satellites 5 and 6 will be launched in September of this year, aboard a Soyuz launcher from Kourou, and numbers 7 and 8 will follow in December.
Then, in 2013 we will see three Soyuz launches of two satellites each. We do not have the precise launch dates yet, but they are likely to be in April, June, and September. In December 2014, we expect to have the first launch using the Ariane 5 launcher, which is capable of deploying four satellites in one go. This means that by the end of 2014 Galileo will have deployed 18 satellites in orbit.
In 2015, there will be two Ariane 5 launches, one in the middle of the year, one at the end, each carrying four satellites. This will bring the total number of satellites to 26 by the end of 2015.
I am doubly confident of this constellation deployment schedule. First, at the technical level: The European Commission (EC) together with the European Space Agency (ESA) is following very closely all the industrial activities. The satellites in production now are with OHB. We have people in Bremen, where the OHB facilities are located, following this very closely. If there are technical issues, we take them up straight away with those concerned, the moment they appear. We also have monthly meetings with Jean-Jacques Dordain, the director general of ESA, and we make a careful tour of all the dates and conditions.
Secondly, there are no unknowns from the budget point of view. Except for the cost of the Ariane 5 launchers, the costs of deployment are already covered. And the EU’s member states have agreed on a budget of €6.3 billion for the next seven years. Budget should not be an issue.
Just recently, on March 12 of this year, we were for the first time able to calculate positions with the four Galileo satellites already in the sky. They pass overhead every so often, depending on geometry of orbit. This is an important technical milestone, even if this does not provide you a service as such. It demonstrates that the capability is there and that the mission part of the system works.
In terms of services, we want to be able at a certain point in time to start offering a guaranteed service. Our objective is October 2014. We will then have a constellation of 14 satellites. On the basis of that constellation, taking some margins, we will guarantee a minimum service of eight operational satellites. That service, in combination with GPS and other systems like GLONASS, will be something that users can start counting on. We will guarantee that at least eight satellites will be in operation from that moment onward.
We will probably translate this number of satellites into a performance-level guarantee. But for the moment it will be based on the number of satellites.
The fact is that we are populating the constellation, and very quickly we will have 26 satellites in orbit. That leads us to the Initial Operational Capability (IOC) phase: With those 26 in the sky we will guarantee a service based on 22 operational satellites.
The target constellation is one of 30 satellites. We don’t know yet for sure when this will be achieved. That will depend on when the last batch of satellites are ordered, and we are still discussing that. But we have an obligation to have deployed 30 satellites by the end of 2020. Then we will guarantee a service based on 24 satellites, with two spares per orbital plane.
AC: What is foreseen as the market readiness to adopt and use Galileo at that time? What companies are taking the lead in designing, manufacturing, and selling combined GNSS receivers?
PF: We believe that market trends go towards multi-constellation receivers. We already see that in some iPhones with GLONASS capability. We already see in the professional market segment that there are some companies providing Galileo capabilities, taking advantage of E1 and E5 for GPS and Galileo.
In the mass market, we also believe many companies will start to build up the multi-signal capability. Companies like STMicroelectronics are working on that. I have asked the European GNSS Agency (GSA) to provide figures. Out of a list more than 60 receiver manufacturers, at least 50 percent of them have at least one product that incorporates European Geosationary Navigation Overlay Service (EGNOS) capabilities. Of those same 60 companies, 30 percent already also have products incorporating Galileo capabilities: STMicro, Septentrio, NovAtel, Leica Geosystems, IFEN, Japan Radio, and others.
We believe that it is important to have continuous interaction with receiver manufacturers so that they understand the benefits of Galileo. EC Vice President Antonio Tajani is devoting a lot of attention to that. We build Galileo, but we do it for users. We have to make sure manufacturers understand the benefits. Discussions with them started in December in London when Mr. Tajani met with a set of CEOs of receivers manufacturers. He promised to meet with them every six months. We are also meeting with them on March 19 to provide information on calendars.
AC: What other European Commission programs will rely on initial or full Galileo capability to fulfill their mission?
PF: As of today, there is no obligation to use Galileo, no mandatory regulation imposing the use of it. There are some initiatives, like the Intelligent Transport Directive, which recommend but do not impose making use of EGNOS and Galileo. Or eCall, which in case of a car accident automatically contacts the rescue services. This will be required in all new cars starting 2015. These systems rely on satellite navigation for positioning. We also have digital tachography to measure the times of driving and rest of truck drivers. This will become a requirement as from 2018, and also relies on satellite navigation.
We also see initiatives by member states to put in place GNSS-based road-pricing systems. Germany has taken a lead in this. The European Union (EU) is trying to harmonize these road-pricing systems across national borders, with programs like Eurovignette and the Interoperability Directive.
In other modes, like aviation, you already have EGNOS. With landing procedures in place based on EGNOS, the system has become a reality.
In Europe we have the common agricultural policy, providing subsidies to farmers. As these are based on field sizes and crops, they need to be controlled, and using EGNOS and Galileo will help achieve more precise measurements.
AC: The Galileo Open Service Signal In Space Interface Control Document (OS SIS ICD) Issue 1 is described as being “subject to evolution.” Can you predict when a further iteration (Issue 2) will appear, and what changes it may contain?
PF: The present version of the ICD is still applicable. It correctly reflects the structure of the messages broadcast by Galileo. The statement you quote refers to the evolution of the document because as you remember there has been a debate about a safety-of-life (SOL) service that is multi-constellation and multi-regional. Since the initial concept of SOL on Galileo was changed in the last two years, some capacity onboard the satellites has been freed. We would like to use that for something else, keeping the backward compatibility for receivers. This will allow us to put in place, for example, a mechanism to improve the tracking performance and availability. Also authentication and higher accuracy for professional markets could be implemented, while maintaining the options for future advanced receiver-autonomous integrity monitoring (RAIM). That explains why we are still working on the evolution of the document. The next version of the ICD will be published in due time.
AC: Can you talk about progress towards increasing the EU share of the GNSS global market — currently 20 percent, but with the objective to reach 33 percent, as in other high-tech sectors? How might this be done?
PF: It is important for us in building Galileo that users benefit in having a second constellation. Satisfying users is the key. It also gives us some sort of independence from GPS, which would otherwise be the sole-source GNSS in the world. We would like our European companies to be more proactive and not to be limited to 20 percent share of the market. Everyone would.
We have our traditional research programs, like the Seventh Framework Programme (FP7). The next installment of the EU’s research programs will be called Horizon 2020, and it will make available budget devoted to the development of applications, receivers, and so on. Whether that will allow European companies to gain market share will depend on their proactivity, their innovation, and market-oriented strategies. That is their responsibility.
We are also active in things like the Galileo Masters, which tries to help small-to-medium enterprises (SMEs) who have good business ideas, young entrepreneurs or scientists with good GNSS-related innovations.
On top of that, we are starting studies to see how we can secure the market uptake of Galileo, not simply to help European industries, but to see that manufacturers and downstream applications developers understand the benefits of Galileo. By the end of the year, we should have created a better understanding by manufacturers and users of the full potential of using Galileo.
AC: Are there any other issues or concerns that you would like to bring to the attention of GPS World readers and the global GNSS community?
PF: I would like to briefly focus on EGNOS. For us it is important that this service will stay for a long time. We promised this to the aviation sector. The EU is finalizing its budget for the period 2014 to 2020, and this will allow us to continue to operate and improve EGNOS. Our objective is that it will augment Galileo as well as GPS, using the dual-frequency approach. That’s a real plus at the regional level for Europe. Its main customer will remain the aviation sector, although it is also widely used in precision farming, tracking and tracing, and so on.
Secondly, we are working on the continuous evolution of the system. We all know that satnav is an evolving domain. It takes time to build satellites and to improve technology. The Mission Evolution Road map that has been developed by experts will be presented to member states later this year.
Finally, we will be organizing the annual European Space Solution conference in Munich in November this year, and in mid-2014 in Prague. We are also hosting the International Committee on GNSS (ICG), which will take place in Prague in November 2014. For us, the location in Prague is symbolic since the European GNSS Agency (GSA), which will be our exploitation entity, is also located there.
Fugro Seastar AS has been looking forward to demonstrating Real-Time Precise Point Positioning (PPP) based solely on Galileo signals since the last two satellites were launched October 12, the company said.
Those two satellites brought the constellation to a total of four satellites, the minimum required to permit calculation of a Galileo-only position. Fugro achieved this task on March 18, within a week of all four Galileo satellites being activated. Fugro is now generating Galileo orbit and clock corrections, which can be used in conjunction with the Fugro G2 decimeter-level corrections associated with its GPS/GLONASS PPP service.
The plot below shows performance of the Fugro orbit and clock service using GPS, GLONASS and Galileo satellites between 06:00 and 08:00 UTC, March 18, 2013, in Oslo, Norway. Between 07:00 and 07:30 UTC, only the four Galileo satellites were used for the solution, which achieved a similar accuracy to Fugro’s existing service, the company said.
“It is interesting that the noise level of the position is better with Galileo alone than when GPS and GLONASS satellites are also used,” Fugro said in a statement. “This is very encouraging as with only four satellites to choose from, the geometry of the Galileo-based solution is much weaker than the solutions before and after the Galileo-only period. This performance exceeds our expectations and suggests a strong future for Fugro’s Galileo PPP solution.”
A ground system aimed at enhancing the navigation precision of China’s homegrown BeiDou Navigation Satellite System (BDS) was approved in central China’s Hubei Province on Friday, according to NZWeek.
The BeiDou Ground Base Enhancement System (BGBES) is a network consisting of 30 ground base stations, an operating system and a precision positioning system. It was approved by the evaluation committee led by Sun Jiadong, an academician with the Chinese Academy of Sciences (CAS) and chief designer of the BDS.
The system is expected to improve the BDS’ positioning precision to 2 centimeters horizontally and 5 centimeters vertically via tri-band real-time precision positioning technology, and to 1.5 meters with the single-frequency differential navigation technology.
U.S. Air Force Space Command has issued a notice that CNAV capabilities on the GPS L2C and L5 signals will be tested in June. No GPS satellite outages are planned. Below is the official notice.
Notice of Test
A Notice by the Air Force Department on 03/20/2013
Action: GPS Test Notice.
Summary: The purpose of this notification is to inform users of an upcoming event related to the GPS satellite constellation. U.S. Air Force Space Command will be testing CNAV capabilities on the GPS L2C and L5 signals on 15-29 June 2013. There are no planned GPS satellite outages for this activity. The broadcast navigation messages will be in compliance with IS-GPS-200 and IS-GPS-705. L2C/L5 CNAV testing will be transparent to GPS receivers that do not process L2C or L5 CNAV. U.S. Air Force Space Command expects to conduct one to two CNAV tests per year over the next few years. These test events will provide an opportunity for civil users and manufacturers to participate in L2C/L5 evaluation and will result in enhanced provider and user readiness for L2C/L5 operations once the Next Generation GPS Operational Control System comes online in 2016.
The draft test plan is available. The draft test plan communicates details of the broadcast, data collection, and results reporting plans.
U.S. Air Force Space Command and the National Space-Based Positioning, Navigation, and Timing Systems Engineering Forum (NPEF) encourage L2C and L5 users and receiver manufacturers to review the test plan, provide comments, and participate in the evaluation process.
Any military or civil users who encounter user equipment problems during or after testing should contact the GPS Operations Center (GPSOC) (military), NAVCEN (civil, non-aviation) as soon as possible. Aviation users should file reports consistent with FAA-approved procedures.
FOR FURTHER INFORMATION CONTACT:
Send all questions or concerns regarding the CNAV Test Plan to [email protected].
Henry Williams Jr.
Acting Air Force Federal Register Liaison Officer
Dr. Bradford W. Parkinson, professor of Aeronautics and Astronautics Emeritus at Stanford University will discuss “GPS for Humanity — The Stealth Utility” at a special Smithsonian event Thursday, March 21.
In the 1970s, Parkinson was the chief architect and original program director for GPS. In his lecture, he will present the history, applications, and future of GPS and the GNSS. Central to operation of GPS is the relationship between time and navigation, and GPS will be explored in the Time and Navigation exhibit.
