Computer Date Glitch May Limit Next Shuttle Launch

n3hat writes "Reuters reports that the next Space Shuttle mission may have to be deferred if it gets too close to the New Year because the onboard computers do not handle the changing of the date in the same way as the ground computers. From the article: '"The shuttle computers were never envisioned to fly through a year-end changeover," space shuttle program manager Wayne Hale told a briefing. The problem, according to Hale, is that the shuttle's computers do not reset to day one, as ground-based systems that support shuttle navigation do. Instead, after December 31, the 365th day of the year, shuttle computers figure January 1 is just day 366."

Comments

Re:wtf?

[tverbeek]

Is there a reason these aren't built on standard parts and operating systems? If they ran their shuttles on something like Debian stable it would be a rock solid platform and probably end up saving them lots of money. Or am I missing something here.

Yeah, you're missing something. Such as the fact that the Shuttle was designed a quarter century ago, when Debian was so far from a stable release that Ian hadn't gotten the hange of long division yet, and still believed that Deb had cooties. "Standard parts" meant 8-bit CPUs with 64KB address spaces, and "standard operating systems" included CP/M, 4BSD, VMS, and an upstart known as PC-DOS. I can't really blame them for building something in-house instead.

Re:wtf?

[Anonymous Coward]

You neglect the fact that military/gov't programming languages at this time included HAL/S, Jovial, NELIAC, &c. (Yes I know that Jovial is still in use for the Navy's ITS 8/16bit muControllers). I've used XPL (the language that the HAL/S compiler was written in) & HAL/S; It was basically the predecessor to Ada/SPARK's 'provability' & 'stability'.
Here is a decent source of HAL/S examples:
http://www.hq.nasa.gov/office/pao/History/computer s/Appendix-II.html

Now, look at the procedure called 'read_accel', about 1/4 down the page.
Midway through, there is a ton of gunk. That's the HAL/S maths for you:
the program is allowed to use three lines to express mathematical code, to 'mimic' math
in code. Now, this is the '70s; it's of little wonder that they weren't worried about the
date switch so much as making sure that:
1) the compiler produced code that could be checked & double checked to be '100%' failure proof and at least be resilient to problems.
2) It had to deal with the beast of being machine independent & easily understandable to the PL/I & FORTRAN programmers of the day
3) It also had to make sure that tasks were scheduled properly & run when specific interrupts happened. This is the Norm for Ada/SPARK now, but HAL/S was pretty much the pioneer here within the Aerospace field.

Re:wtf?

[E-Lad]

You're indeed missing something here.

While I'm not thoroughly educated on this particular subject, I would say that it's a pretty good chance that the flight computers on the shuttles are based on technology that's at least 15 years old (all shuttles underwent a "glass cockpit" update in the mid-late 90s). You don't see NASA cutting a purchase order to cdwg.com when the newest AMD or Intel offering is announced and stuffing that into the shuttles. This stuff is designed, planned, coded for and integrated over a number of years and is very static. No changes. If there has to be changes, they're done under a quality control methods so strict that, yes, Duke Nukem 3D might see the light of day first.

And that's just the hardware part.

On the software side, I'd say you're probably looking at stuff written in any assortment of "classic" languages such as ADA, COBOL, or worse. Due to the nature of the metric f*k ton of sensors, mechanical servos, data inputs, and other such esoteric (and dated) hardware on the shuttles, the software must control, query, parse and monitor, the software is pretty darn married to the platform it runs on.

So, before blurting "D0odz, just instahl leenux n yr shuttlz (deeban stble rox wif glox!)" Give it some deeper thought. There's likely a darn good reason why things are they way they are (bugs not withstanding) when it comes to large flying contraptions that are designed to safely get 7 people 300 miles up, keep them there for a week (or two) and get them home. Sometimes simple things (to you and I) such as a year roll-over are outside the scope when it comes to designing systems to do what the shuttle does.

Re:How Many Times?

[Draknor]

I thought five 9's was the standard for uptime/availability. And you don't achieve that by having 1 server that has five 9's, you achieve that by having a group of servers, so when one goes down, your service is still up.

Space shuttle's a little different:

http://www.fastcompany.com/online/06/writestuff.ht ml

Here we're talking *six* 9s of *bug-free code* (1 error in 420,000 lines of code in the previous version). Not uptime -- bugs. Mistakes. For the simple reason that if you make a mistake on the Shuttle, people die.

You won't get a Java implementation that bug-free without a crack team of developers working for decades, by which point Java will be just as outdated then as the Shuttle code is now.

Remember -- if it ain't broke, don't fix it!