Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Computer Date Glitch May Limit Next Shuttle Launch 354

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."
This discussion has been archived. No new comments can be posted.

Computer Date Glitch May Limit Next Shuttle Launch

Comments Filter:
  • How Many Times? (Score:2, Interesting)

    by Anonymous Coward on Monday November 06, 2006 @11:32PM (#16747157)
    How many times is this going to bite us in the ass? Ada solves all these sorts of problems, and soooo many of my tax dollars went into its creation? I understand that the space shuttle is a limited platform, but why aren't any of the lessons learned in Ada being applied?
  • Uhm...and? (Score:2, Interesting)

    by QuantaStarFire ( 902219 ) * <> on Monday November 06, 2006 @11:40PM (#16747233)

    Pardon my ignorance, but is this really serious enough that it should actually cause a delay? I mean, if it's simply a matter of figuring out what the date is, I'm sure that the astronauts and engineers involved in the project know at LEAST basic mathematics, and can determine that if it's, say, Day 367 on the shuttle computer, then 367-365 = 2, AKA January 2nd, 2007.

    I'd say the article missed something; the whole concept sounds far too ridiculous to stand on its own.

  • Bites me (Score:2, Interesting)

    by William Robinson ( 875390 ) on Monday November 06, 2006 @11:41PM (#16747249)
    The shuttle computers were never envisioned to fly through a year-end changeover

    Sorry to sonud so skeptical....but am I the only one who is worried about capability of missiles (and other defence systems) to handle war through a year-end changeover?

  • Re:wtf? (Score:5, Interesting)

    by tverbeek ( 457094 ) * on Monday November 06, 2006 @11:49PM (#16747337) Homepage
    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.
  • If it ain't broke (Score:4, Interesting)

    by GreggBz ( 777373 ) on Tuesday November 07, 2006 @12:12AM (#16747571) Homepage
    So, they made the software so it does not kill anyone. Who needs fancy features like precise yearly timing?

    Seriously, though, it's worked fine. The software has not killed anyone. They can either fix it and modify a very critical system on an enormously complex vehicle, or they can move the launch date around a few days, which they seem to do for every launch anyway. B is probably safer and more predictable.

  • Re:wtf? (Score:3, Interesting)

    by Firehed ( 942385 ) on Tuesday November 07, 2006 @12:13AM (#16747575) Homepage
    Or just let the thing call Jan 1 '07 'day 366, 2006' and have the boys in the funny suits wear watches.

    You'd think someone at NASA could just do the five-second fix and be done with it though. It's, what, three lines of code?

    Big hint, NASA:
    while ($day >= 366)
      $day -= 365;
  • Re:wtf? (Score:4, Interesting)

    by Anonymous Coward on Tuesday November 07, 2006 @12:15AM (#16747579)
    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: 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? (Score:5, Interesting)

    by E-Lad ( 1262 ) on Tuesday November 07, 2006 @12:25AM (#16747671)
    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 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:lame (Score:3, Interesting)

    by BoomerSooner ( 308737 ) on Tuesday November 07, 2006 @12:28AM (#16747691) Homepage Journal
    Apparently the below article was full of shit:
    They write the right stuff []

  • by drooling-dog ( 189103 ) on Tuesday November 07, 2006 @12:49AM (#16747857)
    ...and I'm surprised that so many of the techie gurus around here are buying it.
  • Re:wtf? (Score:2, Interesting)

    by Digicrat ( 973598 ) on Tuesday November 07, 2006 @01:35AM (#16748163)
    Even if it is a simple bug fix, if they just identified it now, it definetly would not be "flight ready" by the end of the year.

    Any code to be used on a spacecraft must be thoroughly tested and certified (by the developers and a seperate team of testers) before it can be uploaded to the craft. That process can easily take several months to complete. This is the procedure for unmanned spacecraft, I'm sure the procedure for the Space Shuttle is even more stringent.

    My guess is they're writing a solution now that will be ready to prevent this issue next year or afterwards, but it definetly won't be ready for the next launch. I'm sure somebody's probably hitting themself on the head at not noticing this synchronization problem before.
  • by ryanisflyboy ( 202507 ) on Tuesday November 07, 2006 @03:16AM (#16748653) Homepage Journal
    Why is the date critical to the operation of the shuttle? Do the astronauts forget what day they are supposed to land or something? If the day flips to 366 - so what? Now, do not get me wrong. I'm sure there is a *good* reason why a date rollover to a non-existing day would cause a problem, but I can't seem to find out what that problem would be. Does the computer lock up? Does it loose it's ability to navigate? Does the life support system shut off? Do they even know? Maybe it is a case of 'we don't know what would happen, so rather than find out let's just not do it.'

    Also, from what I understand, there are 4 computers aboard the craft. So, why not reboot one computer at a time to update the date until all are updated?

    I want the cowboy astronauts back. The boys that few Apollo 13 and duct-taped their space craft together and rode it home. I think they are more scientist than hot-shot now-a-days. Kind of a shame, it was the ego driven pilot that sorta made it all romantic in a way, now we send accountants in to space that get freaked out over a little date change procedure.
  • by Inoshiro ( 71693 ) on Tuesday November 07, 2006 @03:51AM (#16748815) Homepage
    "Yeah, you're missing something. Such as the fact that the Shuttle was designed a quarter century ago, "

    I can't believe this was moderated as +5, Insightful.

    The shuttle was designed WELL OVER a quarter century ago. A quarter century ago, they had done some much design and testing, they were able to have the maiden flight (STS-1, Columbia launched in April 1981). Shuttle design and specification requirements analysis began in October of 1968. VMS, CP/M, PC-DOS, and 4BSD did not exist when the Shuttle was designed.

    You must be thinking of Multics, which was the closest thing to a modern operating system that existed in the 1960s.

    Seriously, you have no idea how old the Shuttle design is. I have no idea why they keep using it after the great work done 20 years ago by Richard Feynman [] who showed that NASA's shuttle design was about 1/100 flights unreliable. For the record, we've sent up 200 missions and had 2 shuttles blown up. The Space Shuttle is a piece of garbage, and NASA has wasted billions exploring low Earth orbit, rather than do something more useful.
  • by Rexifer ( 81021 ) on Tuesday November 07, 2006 @11:01AM (#16751371)
    If I recall, the shuttle computers were originally based on the IBM 360 (or maybe 370) mainframe architecture standard. The 360 series was the first real effort at standardization of components and instruction set so that upgrading your machine does not mean upgrading your software or peripheral equipment. And like the IBM PC after it, this bit IBM on the ass by allowing an open market to emerge where clones (Amdahl Computers, Hitachi) and third party peripheral manufactures to compete against IBM. (This is where the term FUD originates... Amdahl, one of the original 360 architects who left to found a clone manufacturer, created the term FUD to describe aggressive IBM sales tactics to discredit third parties and intimidate customers into staying with IBM.)

    I have no idea if the flight computers are still the same or not, but NASA long ago ditched their 360 complex for flight operations. (I think it was in use roughly until the mid 80s? Maybe early 90s?)

  • Re:How Many Times? (Score:5, Interesting)

    by Draknor ( 745036 ) on Tuesday November 07, 2006 @11:01AM (#16751377) Homepage
    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: 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!
  • Re:How Many Times? (Score:3, Interesting)

    by metamatic ( 202216 ) on Tuesday November 07, 2006 @01:49PM (#16753971) Homepage Journal
    There's RTSJ and a special version of Java, but they're brand new this year. sp []

    Real time Java also requires a dual UltraSPARC system running Solaris, which is a bit impractical for a Space Shuttle, and it certainly won't run on a gumstix or other embedded platform as was suggested.

    And regular/embedded Java remains definitely unsuitable for real time.

Radioactive cats have 18 half-lives.