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."
How Many Times? (Score:2, Interesting)
Uhm...and? (Score:2, Interesting)
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)
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)
If it ain't broke (Score:4, Interesting)
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)
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)
{
$year++;
$day -= 365;
}
Re:wtf? (Score:4, Interesting)
Here is a decent source of HAL/S examples:
http://www.hq.nasa.gov/office/pao/History/compute
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)
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:lame (Score:3, Interesting)
They write the right stuff [fastcompany.com]
???
This story is obviously bogus... (Score:3, Interesting)
Re:wtf? (Score:2, Interesting)
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.
Date is Critical for the Shuttle (Score:2, Interesting)
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.
Not to nit-pick, but... (Score:4, Interesting)
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 [wikipedia.org] 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.
Actually, based on the IBM 360 mainframe standard (Score:2, Interesting)
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)
Space shuttle's a little different:
http://www.fastcompany.com/online/06/writestuff.h
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)
http://java.sun.com/javase/technologies/realtime.
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.