spirent.com

A Lesson from the Galileo Clock Failures: GNSS Systems Need More Rigorous Testing

Nine clocks on-board Galileo satellites have failed. Here’s what this means for the GNSS community – and why we all need to test more thoroughly.

Galileo satellite

The European Space Agency (ESA) launched four brand new satellites last November as part of the Galileo Global Navigation Satellite System (GNSS). This put enough satellites in the sky to begin Galileo's initial service, making headlines across both GNSS-focussed and national outlets.

It is rightly being hailed as a major success story for Europe; Commissioner Elżbieta Bieńkowska, stated in December: "Galileo offering initial services is a major achievement for Europe and a first delivery of our recent Space Strategy. This is the result of a concerted effort to design and build the most accurate satellite navigation system in the world. It demonstrates the technological excellence of Europe, its know-how and its commitment to delivering space-based services and applications. No single European country could have done it alone."

But Galileo is suddenly making headlines once again, and this time not for the right reasons. It was reported on January 18th that several of the atomic clocks responsible for the satellites' ability to calculate precise time have failed.

Why have the clocks failed?

Each Galileo satellite is equipped with four clocks. Two are Rubidium Atomic Frequency Standard (RAFS) clocks like those found in GPS and GLONASS satellites. The other two are the more accurate (and much more complex) Passive Hydrogen Maser (PHM) clocks that offer the Galileo constellation increased timing accuracy.

The six PHM clocks that failed are almost exclusively on the In Orbit Validation satellites. The European Space Agency (ESA) suggested the failure was "related to the fact that when some healthy [hydrogen maser] clocks are turned off for long periods, they do not restart due to a change in clock characteristics".

The ESA has since been able to remotely restart one of the failed PHM clocks, leaving only five PHM clocks offline.

Meanwhile four RAFS clocks have failed – all of them on Full Operational Capability satellites. According to a statement from the ESA the rubidium-based clock failures "all seem to have a consistent signature, linked to probable short circuits, and possibly a particular test procedure performed on the ground".

It's worth noting that the RAFS clocks are also used by India's space agency, but at the time of writing they haven't reported any similar issues.

What does the clock failure mean?

While a total of nine clocks have failed, so far, no more than two have failed in a single satellite. Providing each satellite has at least one clock remaining, they can continue to function as normal. For now then, these clock failures won't have a direct impact on the performance or stability of Galileo.

That said, the clock failures highlight a concern that all members of the GNSS community should share: failure can happen at any stage of a GNSS system – from the satellite level, right down to the device or chipset firmware layer. Those involved in GNSS receiver design and integration need to be prepared for these kinds of errors.

Beyond Galileo

I've focused on Galileo here due to how recently these clock failures happened, but no GNSS system is free from errors of this kind.

I've written previously about how errors occurred with the GPS and GLONASS systems. An attempt to remove an older GPS satellite from service in 2016 resulted in inaccurate timing data being sent from the constellation. Meanwhile, a software update in 2014 took the entire GLONASS system offline for ten hours.

Preparing for errors

The moral of the story is that no GNSS system is immune to software or hardware failures. Manufacturers of GNSS chipsets and location-aware devices need to know how their equipment will respond if they are sent a faulty signal by a satellite suffering from a software or hardware error.

If a receiver is unable to detect the difference between healthy and unhealthy satellite signals, it could appear to be operating as normal. But all the while it would be producing misleading positioning and timing data that could compromise business operations – and in extreme cases even be hazardous to the end user.

Simulating this kind of satellite hardware failure isn't easy. But they aren't the sole problem. Satellite failures like this are just another class of error that GNSS systems will encounter (and must be equipped to deal with).

It is possible to simulate a variety of real-life hardware and software failure scenarios, provided you make the most of modern GNSS simulation equipment and rigorous test plans. With these in place, you can start to better understand how your receiver will react to errors from all components of a GNSS system, and see the potential issues before they impact the user experience.

For more updates on risks to GNSS-reliant devices, you may also like to join the GNSS Vulnerabilities LinkedIn Group to stay up to date with current risks and regulations.

If you'd like to speak to Spirent about GNSS testing, get in touch now
comments powered by Disqus
× Spirent.com uses cookies to enhance and streamline your experience. By continuing to browse our site, you are agreeing to the use of cookies.