Wealth, breadth, and depth. That’s what this issue brings you, in signal simulation- and testing-related content. Unfortunately, the wealth on offer has to large extent elbowed out our two news sections, The Business and The System. The former is given short shrift in this issue and the latter even shorter herewith, in pithy precis with website shortcuts. And our apologies.
Let’s all remember, brevity is the soul of wit.
GPS III Flexible Signal Generator. With completion of the Delta Preliminary Design Review for the GPS III satellites, Lockheed Martin and the U.S. Air Force announced that “an innovative new waveform generator permits the addition of new navigation signals after launch to upgrade the constellation without the need to launch new satellites.”
IGS Real-Time Service. The International GNSS Service, a worldwide federation of agencies involved in high-precision GNSS applications, announced the launch of its Real-Time Service (RTS). The RTS is a global-scale GNSS orbit and clock correction service that enables real-time precise point positioning and related applications requiring access to IGS low-latency products. The RTS is offered in beta as a GPS-only service for the development and testing of applications.
QZSS Will Grow to Four. The Japanese government has ordered three navigation satellites from Mitsubishi Electric Corp. to expand the Quasi-Zenith Satellite System, currently orbiting the sole Michibiki. QZSS augments GPS navigation signals for users in the Asia-Pacific region. NEC Corporation has been awarded a contract for the QZSS ground control segment.
Real-Time PPP with Galileo. Fugro Seastar AS achieved this task 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.
BeiDou Ground System Approved. The BeiDou Ground-Based Enhancement System (BGBES), a network of 30 ground stations, an operating system, and a precision positioning system, was approved by a Chinese government evaluation committee. The system is expected to improve BDS positioning accuracy to 2 centimeters horizontal and 5 centimeters vertical via tri-band real-time precision positioning technology, and to 1.5 meters with single-frequency differential navigation technology.
CNAV Test on GPS L2C and L5. The U.S. Air Force Space Command announced that CNAV capabilities on the GPS L2C and L5 signals will be tested in June. The civilian navigation message to be carried by modernized GPS will have similar data to the existing NAV message, but its structure will be different, with increased message bandwidth for greater information density. L2C and L5 users and receiver manufacturers are encouraged to review the test plan, provide comments, and participate in the evaluation process.
GPS at the Smithsonian. Brad Parkinson’s presentation, “GPS for Humanity — The Stealth Utility,” is now available as video on UStream.The talk helped introduce the new Smithsonian National Air and Space Museum exhibit, “Time and Navigation: The Untold Story of Getting from Here to There,” which is now open and free to the public in Washington, D.C.
Europe’s four Galileo satellites are now working as clocks accurate to a few billionths of a second, disseminating the exact time through their signals expressed as the UTC Universal Coordinated Time global standard, reports the European Space Agency.
“A billionth of a second equals a nanosecond, a time interval far beyond our own human capacity of appreciation,” explains Marco Falcone, ESA’s Galileo System Manager.
The prediction error for the offset between Galileo System Time and UTC, expressed in nanoseconds. The UTC value available to the user via Galileo is expected to be accurate within 26 nanoseconds, but in spring 2013 it has been even better, with a prediction error in the last two months of less than five nanoseconds.
“A single lightning flash across the sky during a thunderstorm lasts about ten milliseconds, which is already 10 000 000 nanoseconds. But for high-tech applications, as well as navigation services, nanosecond accuracy is essential.”
The replacement for Greenwich Mean Time, UTC is part of all our daily lives: it is the timing used for Internet, banking and aviation standards as well as precise scientific experiments, maintained by the Paris-based Bureau International de Poids et Mesures (BIPM).
The BIPM computes UTC based on inputs from collections of atomic clocks maintained by institutions around the world, including ESA’s ESTEC technical centre in Noordwijk, the Netherlands.
‘Galileo time’ is derived independently of UTC but is being kept close to it, with a precise ‘offset’ between the two values being calculated continuously and then disseminated through Galileo’s navigation message.
Galileo, like all other satellite navigation systems, is based on the highly precise measurement of time. A receiver on the ground pinpoints its position by calculating how long signals from satellites in orbit take to reach it.
Matching the receiver and satellite clocks then multiplying the time taken by the speed of light gives the range between user and satellite, allowing the receiver to fix its own location relative to four or more satellites.
“Each navigation system has its internal reference system time used to synchronise all system clocks and maintain overall coherence,” adds Marco.
Galileo’s navigation message embedded in its signals include precise timings based on Galileo System Time, kept close to global time standard UTC with a precise offset given, accurate to at least 26 nanoseconds.
“Galileo runs on Galileo System Time, GST, which is fixed on the ground at the Galileo Control Centre in Fucino, Italy, by the Precise Timing Facility, based on the average of different atomic clocks.
“Strictly speaking, for navigation purposes alone this internal reference system time does not need to be in agreement with UTC at the highest level of accuracy but with this agreement being the case, it is therefore possible to immediately disseminate UTC to the users to the best accuracy and this is the aim of Galileo.”
The offset between GST and UTC is currently estimated in Turin, Italy, by the Istituto Nazionale di Ricerca Metrologica (INRIM), where time measurements are performed every day with the most precise techniques available to check GST status.
INRIM has been supporting ESA’s Galileo development since the early phases of the project. More recently INRIM has overseen the creation of a ‘Time Validation Facility’ for Galileo in collaboration with five other European time-measurement institutions: the Physikalisch Technische Bundesanstalt in Germany, the National Physics Laboratory in the UK, the Systeme de References Temps Espace/Observatoire de Paris in France, the Real Instituto y Observatorio de la Armada in Spain and Observatoire Royale de Belgique.
Galileo’s Ground Control Segment (GCS) in the Fucino Control Centre in Italy oversees Galileo navigation services and satellite payload operations.
Each day, the most precise European clocks and national time scales are compared to GST and the offset compared to UTC is estimated and provided to the Galileo Control Centre. This offset is then uploaded to the Galileo satellites for transmission in the navigation message available to users.
As explained by Patrizia Tavella from INRIM, “The UTC value available to the user via Galileo is expected to be accurate within 26 nanoseconds, but in the last two months it was even better, with a prediction error in the last two months of less than five nanoseconds.”
The European Space Agency’s (ESA’s) retired GIOVE-A navigation mission has become the first civilian satellite to perform GPS position fixes from high orbit. Its results demonstrate that current satnav signals could guide missions much further away in space, up to geostationary orbit or even as far as the Moon.
GIOVE-A has been able to fix its position, velocity and time from GPS signals, despite orbiting more than 1000 km above the downward-pointing U.S. satellites.
“Satellite navigation has become almost as indispensable for most low-orbiting satellites as it is for car drivers and other terrestrial users,” said ESA’s Steeve Kowaltschek. “Satellites equipped with satnav receivers can continuously monitor their orbit in space, enabling largely autonomous operations with limited ground intervention. GIOVE-A’s three months of data show that future geostationary satellites could operate in the same way, bringing real competitive advantage to the multi-billion-euro telecommunications satellite market.”
Launched in 2005 to claim radio frequencies and test hardware for Europe’s Galileo satnav constellation, the Galileo In-Orbit Validation Element-A, or GIOVE-A, mission far outlasted its original two-year design life. It was formally decommissioned by ESA in the middle of last year, once the first Galileo satellites completed their orbital commissioning. Having been moved into a graveyard orbit about 100 km above Galileo’s orbital altitude of 23 222 km, control was passed to its prime contractor Surrey Satellite Technology Ltd. of Guildford, UK.
ESA had originally worked with SSTL to customize one of the company’s existing satnav receivers for testing on GIOVE-A, an activity supported through ESA’s Advanced Research in Telecommunications Systems (ARTES) program. In the event, the satnav receiver was activated for only 90 minutes during the very beginning of the satellite’s seven-year operational life, with GIOVE-A’s main tasks given priority. Once the formal mission was over, ESA and SSTL took the opportunity to switch the receiver on again.
“We have been really encouraged by the initial results from our receiver,” said Martin Unwin at SSTL. “Our patience has finally been rewarded, and we would like to make the best of this unique opportunity.”
SSTL is able to upload new software to the receiver in orbit, and has been able to apply sophisticated software algorithms to help detect faint satnav signals. Further work is planned to refine operation through the use of an accurate onboard clock and orbit-estimating algorithms.
GIOVE-A has been able to make use of signals emitted sideways from GPS antennas, within what is known as side lobes.
GPS Side Lobes. GPS satellites — like those of Galileo, Russia’s Glonass or their Japanese, Chinese and Indian counterparts — aim their antennas directly at Earth. Any satellite orbiting above the GPS constellation can only hope to detect signals from over Earth’s far side, but the majority are blocked by the planet. For a position fix, a satnav receiver requires a minimum of four satellites to be visible, but this is most of the time not possible if based solely on front-facing signals.
Instead, GIOVE-A makes use of signals emitted sideways from GPS antennas, within what is known as side lobes. Just like a flashlight, radio antennas shine energy to the side as well as directly forward.
“These side lobes are not typically well measured because this is energy that doesn’t reach users on Earth,” explained Kowaltschek. “Antenna designers seek to minimize them, but the laws of physics mean they will always be present in some form. Measuring these GPS side lobes has shown them to be stronger than anticipated, and the combination of side lobes and signals spilling over from the other side of Earth mean that a position fix can be maintained throughout GIOVE-A’s orbit.”
The satellite has also acquired detailed profiles of the signal side-lobe characteristics of the various GPS design blocks.
Geostationary satellites reside in set orbital slots, some 80-km across, up in the 36,000-km-altitude belt. Chemical thruster firings are needed every fortnight or so to correct for drift, checked against radio ranging from the ground.
Harnessing satnav would be a way of automating station-keeping functions. It also meshes with the current move to all-electric comsat designs, such as ESA’s Electra. Electric propulsion would do the job of conventional chemical thrusters, delivering more compact satellites capable of flying on cheaper launch vehicles while offering longer mission lifetimes. But electric propulsion provides lower thrust and therefore requires almost permanent ground ranging. Continuous position fixes via satnav could perform this task onboard, maintaining the orbit position with better accuracy.
SmallGEO. (Image: ESA)
In addition, constant orbit determination and close-to-perfect time knowledge also improves pointing accuracy on comsats that use startrackers as their main attitude sensor.
All-electric comsats using satnav could gradually steer themselves up to geostationary orbit following launch, further slashing the required launcher size, onboard fuel and ground support.
“We envisage a future satnav receiver that can track not only GPS, but also Galileo and Glonass signals at high altitudes, meaning a near-continuous availability of accurate position and time for geostationary and other satellites,” says Martin.
As a next step, a receiver will be flown on ESA’s SmallGEO telecom mission, due for launch in 2014. Building on the positive results of the GIOVE-A experiments, SmallGEO will be the first civilian mission to use satnav in geostationary orbit.
The radio spectrum is about to get even busier, as Europe’s Galileo satnav system starts services, at the same time the European Space Agency (ESA) tests novel satellite-based telecommunication services. Supporting these developments from the ground, ESA’s new custom-built Telecommunications and Navigation Testbed Vehicle will measure the resulting signals from all over Europe.
Adapted from a Mercedes Benz Sprinter van, this unique measurement vehicle has been delivered to ESTEC by Austria’s Joanneum Research institute. “This is a dual-purpose vehicle, suitable for both telecommunications and navigation system testing,” explained Simon Johns of ESA’s Radionavigation Systems and Techniques Section.
“For navigation, we have the Galileo constellation coming on stream, as well as the stepping up of ESA’s GNSS Evolution programme — designing what comes next after Galileo’s first generation.”
The four wheel-drive vehicle can host a three-person team, and is crammed with dedicated navigation and telecommunication monitoring equipment.
Testbed vehicle screen.
“One of the main goals driving the design was to have an ‘easy to adapt’ test platform suitable to set up test campaigns for different mobile satellite systems and standards that would require different types of antennas and specific receiver/transmit equipment,” explained Olivier Smeyers of ESA’s Communication-TT&C Systems and Techniques Section.
“On the telecommunications side, there is a continuous effort to enhance current and create new mobile satellite-based broadcast and interactive services via the evolution of current systems or developing new standards,” Smeyers said. “Testing in the field is an essential element for validating and eventually establishing evolved or new standards. The vehicle has built-in multimedia equipment, including storage and control computers, multimedia gateway, passenger LCD screens, cameras and microphones, to serve this purpose.”
The vehicle features include two removable roof plates to mount specialized antennas (one currently hosts the antenna of a Broadband Global Area Network satellite terminal for Internet connectivity and multimedia and data streaming), an 8-meter-high telescopic mast capable of carrying 25 kilograms, a rubidium atomic clock synchronized to GPS time with nanosecond accuracy, a high-end spectrum analyzer and oscilloscope for signal measurements, and mobile temperature sensors to monitor the rack equipment.
A fish-eye video camera incorporating onscreen GPS timing and positioning performs continuous recording of its surroundings — to throw light on high buildings, trees, or other factors that might affect results.
Internal and external generators yield up to 5 kilowatts to keep everything running — sufficient power to supply two typical European households.
“The challenge was to fit in all the equipment and provide the necessary power and air conditioning, while still weighing less than 3.5 tonnes,” said Thomas Prechtl of Joanneum Research. “Exceeding this weight would have meant drivers would have needed a special license, and potentially limited its operations in some European nations.”
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.
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.
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.”
Satellites expected to be launched in support of various Global Navigation Satellite Systems are the following:
GPS
May 15: Block IIF-4, SVN66, launch window: 17:39-17:58 UTC
November: Block IIF-5
GLONASS
April 26: Single GLONASS-M or -K satellite from Plesetsk
June 28: Three GLONASS-M satellites from Baikonur
Galileo
October: FOC-1 launch (two satellites)
Indian Regional Navigation Satellite System (IRNSS) June (This is the first launch for an expected constellation of seven satellites, some of which will be geostationary. The constellation will provide continuous regional coverage for positioning, navigation and timing services.)
by James T. Curran, Mark Petovello, and Gérard Lachapelle
Within a day of their initial activation over central Europe on March 12, Galileo satellites were visible over North America. The PLAN Group of the University of Calgary was successful in capturing and processing the signals from these satellites as they emerged. Galileo PRN 11, 12, and 19 were found and tracked on E1B/C. The PLAN software GSNRx was also able to track simultaneously GPS L1 and GLONASS L1 and produce combined position solutions.
Examining the Galileo navigation message transmitted on the E1B signal, it was found 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, it was noted that more 50 percent of them were of type 0, although all words (types 0 to 10) were decoded at some point during the test.
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 and also 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. Two RF channels were processed, the first centered at 1574.0 MHz with an IF bandwidth of 10.0 MHz, for the GPS L1 C/A and Galileo E1B/C signals and the second centered at 1602.0 MHz again with a bandwidth of 10.0 MHz, for the GLONASS L1 OF signals. 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.
Figure 1. Scatter plot of the north and east position
Pseudorange and Doppler observations were extracted from the tracking strategies at a rate of 2 Hz. A 2D horizontal plot of the combined GPS & GLONASS and the combined Galileo, GLONASS & GPS single-frequency single-point solutions is presented in Figure 1.
Figure 2: Skyplot of the Galileo satellites.
The pseudorange residuals are plotted against time for each PRN tracked from each of the three systems in Figure 3. It is apparent that the addition of the three Galileo observations contributes to a reduction in bias and standard deviation in the horizontal directions, showing an excellent functioning of the Galileo satellites and PLAN Group equipment and software.
Figure 3. Pseudorange residuals are plotted against time for each PRN tracked from each of the three systems.Figure 4. A screenshot of the receiver processing the data.
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 a first autonomous real-time Galileo position, velocity, and timing (PVT) calculation, based on live Interface Control Document (ICD)-compliant Galileo messages from the four Galileo in-orbit validation (IOV) satellites.
The standalone position was calculated from in-orbit navigation messages using a standard PolaRx4 GNSS receiver equipped with commercially released firmware.
This achievement followed another recent Septentrio milestone; the announcement of a first GPS+Glonass+BeiDou PVT less than two weeks after the BeiDou2 ICD publication in December — and it was itself followed by a Septentrio release stating performance of what it believes to be the first 4-constellation PVT performed by a standard commercial receiver.
“On Tuesday 12-Mar-2013 at approximately 10:35 UTC we included three Galileo IOV satellites (E12, E19 & E20) in a multi-constellation PVT. The 3D-position fix happened shortly after it was brought to Septentrio’s attention that the Galileo IOV satellites were transmitting, for the first time ever, a fully usable navigation message as part of an ESA experiment.
“This ability to rapidly incorporate new constellations demonstrates the flexibility of the architecture of Septentrio receivers,” the company statement continued.
“We are delighted that Septentrio receivers are amongst the first to witness the readiness of the Galileo navigation message to perform a position fix from in orbit signals,” commented Peter Grognard, Septentrio’s founder and CEO. “Septentrio has been involved since 2003 in all major milestones that pave the way for the European constellation genesis.”
