
Multiple Boeing 787s in China experienced GPS 20 years rollover issue - jcfrei
https://twitter.com/ChinaAvReview/status/1114802018919411712
======
AnssiH
Someone on reddit said yesterday a KLM flight (apparently B777) was grounded
because of incorrect date (in some Honeywell equipment?):
[https://www.reddit.com/r/sysadmin/comments/babyvv/anyone_hit...](https://www.reddit.com/r/sysadmin/comments/babyvv/anyone_hit_by_the_gps_rollover_event_today/ekb3ev3/)

~~~
Aromasin
We had some Honeywell engineers at my workplace for a system integration
meeting. Over lunch I got the opportunity to talk with them. This came up in
conversation. Apparently it's very much all-hands-on-deck at the moment -
almost every system they've currently got on-board Boeing aircraft is being
assessed, and they're in all hours of the day to get new revisions through. I
do not envy them right now.

~~~
mehrdadn
Is it because they didn't see the GPS rollover coming up (it was in the news
though)? Or did they not think their products would be affected?

~~~
Aromasin
Partly that (I think there were some legacy systems that were missed), partly
that every minor clerical and drawing error that got passed through because of
how insignificant it was (nothing that would affect the integrity of the
aircraft I should add) has been flagged by Boeing. They want to look proactive
to their customers and shareholders I suppose. That means lots of tiny,
insignificant changes to hundreds of drawings. It's nothing technically
challenging for the most part - just lots and lots of paperwork.

------
petee
I don't get how some planes were affected, but not all; Every 787 in China
should be running the same software version, let alone the world, no?

Are there any reasons a fleet plane might be using a different version? I'm
coming up short on reasons, other than language, or maybe special hardware
modifications?

~~~
j16sdiz
They have regular software updates. Just like Windows update, nobody do that
regularly

~~~
petee
Haha, that's surprising though, since these are important systems, if there is
an update, doesn't it mean something really needs to fixed, i.e, gps rollover?
Any bug left unpatched seems unacceptable

Maybe I have more faith in the 'system' than I should...

~~~
kijin
We're talking about the same manufacturer that's responsible for the 737 MAX
fiasco. I'm not sure how much trust I would want to place in their software.

~~~
icebraining
You're putting trust in their software whether you upgrade it or not.

~~~
sslayer
You forget that Boeing doesn't own these planes. These aren't Tesla's. We are
currently in an era were it seems to be expected that the manufacturer
automatically update their software without the end user intervention, ie
Tesla, Windows, Apple, etc... Thats not how it was done in the past,
particularly when the bandwidth didn't exist.

~~~
icebraining
I don't see how this changes what I wrote.

------
PaulHoule
Funny I got an old Tom Tom for $10 a few weeks ago, too old to get software
updates, and I was pleased to see that it worked just fine after the rollover.

~~~
labster
At the [dead] commenter: Timekeeping is an integral part of how the Global
Positioning System works, to the extent that relativistic time dilation is a
factor. You simply cannot use a GPS receiver with a broken time
implementation, at least not without significant accuracy issues.

~~~
myself248
But internal time is not the same as display time.

Internally, the week counter just rolled over. That's fine; all the almanac
data is handled in that same format internally. Some receivers may need a
reset when this counter rolls, and may need to relearn the almanac/ephemeris
from the sky, but once that's done, Sunday of week 0 is just the same as any
other Sunday of any other week 0.

Navigation works just fine because it's all internally consistent.

But display time, ahh, now that's where things get interesting. Sunday of week
0 could be displayed as 2019 April 7, or it could be displayed as 1999 August
22, or it could be displayed as 1980 January 6.

Knowing which epoch you're in is actually considerably trickier than working
consistently internally, since there's no information in the satellite signal
to tell you this, by design. It comes from applying an external offset.
Receivers have lots of ways to do this, and quite a few simply have it baked
in and cannot handle a rollover, so as far as they're concerned, week 0 is in
1999, period. They'll navigate just fine but they'll display the date wrong,
because they're applying the wrong offset.

~~~
joelhaasnoot
The easiest way of doing this is to assume time will never travel and store
the latest computed date right? If you've seen 2001, it's never going to be
1999 again, so it must be 2019.

I understand that will require either flash or battery backed RAM, etc to keep
this stored, but seems relatively trivial in most applications... (side effect
would be that if the backup battery is dead or all batteries are disconnected,
you would revert to 1999)

~~~
inferiorhuman
Unless someone manually sets the date incorrectly or gets the timezone wrong
(assuming the date isn't stored as UTC).

~~~
joelhaasnoot
Yeah, you can only use the GPS source for that flag.

------
mschuetz
What's the reasoning for the current GPS time format and it's resulting
issues? Can't we just use a 64bit integer timestamp? That would give us
roughly 580 years in nanosecond resolution?

~~~
michaelt
GPS was designed a long time ago, and the data rate for ephemeris and almanac
data is.... 50 bits per second.

That's not an exaggeration for comic effect. There's _literally_ 50 bits per
second from each satellite. 6.25 bytes.

So the navigation messages are packed extremely densely. To the point that
plenty of numbers don't even start on byte boundaries.

~~~
leecb
The age isn't the only explanation for the low data rate- it's not simply low
tech.

GPS relies on receiving extremely weak signals, often with a very limited
receive antenna. This means there's a real trade off- you can send a limited
amount of data over a given communication channel. Increasing the data rate
might require increasing the transmit power / antenna gain of the GPS
satellites, or requiring bigger / better receive antennas on GPS receivers.

Here are the parameters involved:
[https://en.wikipedia.org/wiki/Shannon%E2%80%93Hartley_theore...](https://en.wikipedia.org/wiki/Shannon%E2%80%93Hartley_theorem)

~~~
caf
When you consider that you're listening to a ~500W EIRP transmitter that's
>20,000km away, with a handheld receiver that usually has a pretty
omnidirectional antenna... 50 bps starts to sound quite impressive!

~~~
jacquesm
More so when you realize the signal level is under the noisefloor!

------
js2
Related discussion which explains the rollover issue:

[https://news.ycombinator.com/item?id=19593227](https://news.ycombinator.com/item?id=19593227)

------
gwbas1c
Dumb question: What is the rollover issue?

~~~
Someone1234
Not a dumb question at all.

GPS used ten bits for datetime. With a week counter and seconds into that week
since 6th of January, 1980. After 1024 weeks it resets back to 0. This has
happened once already on 21st of August, 1999. This is the second
rollover/reset of the week counter on 6th of April, 2019.

Newer versions of GPS messages use thirteen digits instead of ten digits
allowing for a larger week counter (granting 8,192 weeks), causing the first
rollover not to occur until the year 2137.

[https://en.wikipedia.org/wiki/Global_Positioning_System#Time...](https://en.wikipedia.org/wiki/Global_Positioning_System#Timekeeping)

~~~
kevhito
Instead of adding 3 bits, maybe they should have dropped 3 bits. A rollover
every ~20 years is just asking for latent buts to blow up. A rollover every
~2.5 years is just business as usual. Go big or go small. Don't design things
to break just after you retire but before your coworkers do.

~~~
Rebelgecko
OTOH, with the current setup a receiver will know the correct date as long as
it is turned on at least once every 1024 weeks, since it can detect the
rollover. More frequent rollovers might cause issues with timing on devices
that are infrequently turned on. It's sort of a moot point for most of us once
there's greater adoption of the L2 and L5 CNAV signals— those use a week
counter that won't roll over until most if not all of us are dead. Then it can
be someone else's problem :)

~~~
throw0101a
> OTOH, with the current setup a receiver will know the correct date as long
> as it is turned on at least once every 1024 weeks, since it can detect the
> rollover

Actually, probably every 512 weeks, as it needs to know (or assume) with side
of the +/\- it is on:

* [https://en.wikipedia.org/wiki/Serial_number_arithmetic](https://en.wikipedia.org/wiki/Serial_number_arithmetic)

* [https://en.wikipedia.org/wiki/Date_windowing](https://en.wikipedia.org/wiki/Date_windowing)

* [https://docs.ntpsec.org/latest/rollover.html#ntp_pivots](https://docs.ntpsec.org/latest/rollover.html#ntp_pivots)

------
userbinator
The 787 didn't even exist when the GPS time last rolled over, so it's quite
unusual to see it have this problem --- unless Boeing reused the software from
a previous version, which is not surprising given the regulations of the
industry, but that would imply other older models also have the problem.

~~~
acqq
> The 787 didn't even exist when the GPS time last rolled over, so it's quite
> unusual to see it have this problem

It's not as unusual as you'd think:

[https://blog.fosketts.net/2019/04/06/gps-time-rollover-
failu...](https://blog.fosketts.net/2019/04/06/gps-time-rollover-failures-
keep-happening-but-theyre-almost-done/)

There you see a nice summary of the problem and an example a Mercedes car
from, if I understood, 2008 experiencing the same type of problems. Also
discussed on HN:

[https://news.ycombinator.com/item?id=19593227](https://news.ycombinator.com/item?id=19593227)

It's like having a Y2K bug software and saying "but that software didn't exist
before 1900." It doesn't matter when the "epochs" are, it's just about what
the design covered or didn't.

I've personally fixed the trading software which failed to correctly implement
the correct rollover of the _decades_ (i.e. the transition from year 9 to year
0 in the names), not to mention Y2K. It was simply tested before only "in the
same decade."

It's definitely a failure in the development process, for the software that is
supposed to work in some bigger time frame, and not only shortly.

~~~
syockit
I'm rather interested in what kind of software developed after Y2K still
exhibiting Y2K bug, and how it affects the usage. Is it made with the
assumption that it's going to record only post-Y2K dates, and somehow user
manages to input pre-Y2K date?

~~~
avar
A lot of software was never fixed for the Y2K problem. People just went from
e.g. entering a date of 99 to 00 as the new millennium rolled around, and
dealt with the pain of any time offset calculations being incorrect and
needing to be manually fixed for a few months.

Some of it's doubtless still in use and people are entering "19" as the year
today, and if it's still in use in 2099 we'll have the exact same problem all
over again with the exact same software.

That may seem crazy today, but people in the 1950s would have thought you were
crazy if you said B-52s were still going to be flying in 2020.

There's doubtless going to be people still running Windows 95 on some emulator
in 2100 to use some legacy application that keeps chugging along. Some
software we use today might be in use for thousands of years or more, unlike
airframes it isn't subject to any natural decay or wear.

------
Thermolabile
Can someone give me a source of it?

