Posted on 05/06/2015 7:28:17 AM PDT by BenLurkin
Such glitches emerge with surprising frequency. It’s suspected that the reason why Nasa lost contact with the Deep Impact space probe in 2013 was an integer limit being reached.
And just last week it was reported that Boeing 787 aircraft may suffer from a similar issue. The control unit managing the delivery of power to the plane’s engines will automatically enter a failsafe mode – and shut down the engines – if it has been left on for over 248 days. Hypothetically, the engines could suddenly halt even in mid-flight. The Federal Aviation Administration’s directive on the matter states that a counter in the control unit’s software will “overflow” after this specific period of time, causing an error. Although scant details have been released – the FAA and Boeing declined to comment for this article – some amateur observers have pointed out that 248 days (when counted in 100ths of a second) is equal to the number 2,147,483,647 – which is significant.
How so? It just so happens that 2,147,483,647 is the maximum positive value that can be stored by a “32-bit signed register”, commonly installed on many computer systems. On Ariane, by comparison, the software was using a "16-bit" space, which is much smaller and only capable of storing a maximum value of 32,767.
(Excerpt) Read more at bbc.com ...
In 22 years, any unix/linux platform still using 32-bit timestamps will overflow:
From Wiki:
At 06:28:16 UTC on 7 Feb 2036, Network Time Protocol will loop over to the next epoch, as the 32-bit time stamp value used in NTP will overflow.
At 03:14:08 UTC on 19 January 2038, 32-bit versions of the Unix time stamp will cease to work, as it will overflow the largest value that can be held in a signed 32-bit number (7FFFFFFF16 or 2,147,483,647). Before this moment, software using 32-bit time stamps will need to adopt a new convention for time stamps,[19] and file formats using 32-bit time stamps will need to be changed to support larger time stamps or a different epoch.
At 06:28:15 UTC on Sun, 7 February 2106, the Unix time will reach FFFFFFFF16 or 4,294,967,295 seconds which, for systems that hold the time on 32 bit unsigned numbers, is the maximum attainable. For these systems, the next second will be incorrectly interpreted as 00:00:00 1 January 1970 UTC.
ping
Time keeping on a stand alone real time system is always a problem that has to be managed. Remember that a one in a million calculation issue can occur every few seconds.
There is something unsettling about having to “re-boot” the airplane
Nobody will be alive in 2 years time, so no need to worry.
At some point, I predict it will just be cheaper to change our calendars to match whatever date the computers think it is, than to replace/patch all the computers :)
From what I’ve read, this software issue only applies to 25 planes assembled. Boeing has said all the newer 787’s don’t have this issue.
Sounds like sloppy programming to me... And poor QA/QC processes. You should always check for these sorts of errors, grab them, and act accordingly. You just don’t let the program die or freeze up on these sorts of systems.
Whew! Thanks what a relief. I was worried for a moment about this time stamp thing.
I read the article and nothing was said about if this was a cumulative counter or a re-settable counter. First of all, no plane flies for 248 consecutive days and secondly, there are multiple service time maintenance requirements for transportation aircraft. So, for me, not flying a 787 for this reason is nonsensical.
What the real import of this issue is comes from guarding against a single-point failure that generates a fatal situation. For the 787 example this could be as simple as checking airspeed before engine shut-down. The obvious problem is the number of such potential failures grows as our software becomes increasingly useful. CATCH-22 in real life!
And then the grand master plan of all abused computers everywhere will be complete. The date will be what THEY say it is, not what we say
I for one welcome our new computer overlords.
I can’t imagine engines being on continuously for 248 days.
I wonder if that's going to be a problem...NAH, I'm sure the government has it all under control!
Great article. I wish the author had mentioned the mother of all computer overloads, which happened during the decent of Apollo 11 to the lunar surface:
https://www.hq.nasa.gov/alsj/a11/a11.1201-fm.html
Of course. But the control unit managing the delivery of power to the plane’s engines could easily be left to run that long. Just because the engines are not running doesn't mean the APUs or other control infrastructure are not.
Simply fascinating story. I’d heard it before but never heard or read about the efforts after the landing. great stuff.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.