NASA Avoids "Happy New Year" On Shuttle

ClickOnThis noted that NASA is actually avoiding a Shuttle in Space over New Years. It says "The worry is that shuttle computers aren't designed to make the change from the 365th day of the old year to the first day of the new year while in flight. NASA has never had a shuttle in space December 31 or January 1. 'We've just never had the computers up and going when we've transitioned from one year to another,' said Discovery astronaut Joan Higginbotham. 'We're not really sure how they're going to operate.'" You may notice some deja vu while reading this story. Sorry. Not much happens on Sundays :)

Comments

because it's too damned hard to ....

[Lumpy]

...sit in one on the ground and have it turned on that night. What the hell is wrong with NASA? They dont have any shuttles sitting where they can have some CS guys sitting in it over the new years event to see what happens?

That is absolutely insane that they do not know what will happen, so they have not bothered to take a few moments and find out over the past 18 years.

Re:because it's too damned hard to ....

[eldavojohn]

sit in one on the ground and have it turned on that night.

I agree with you but it's not even that hard to do. I mean, they should have test cases and simulation already to test the software, you'd think they could devote some of their time to have someone simply set all the clocks on all the hardware for the time of that night's transition ... or point the software at an NTP server and set that to the time it transitions.

No need to make some poor souls work on New Years ...

You really shouldn't even need to sit one on the ground given you've got thorough enough testing and integration set up. I would certainly hope they do. If there's ever been a time to actually follow the book on testing, it's when human lives hang in the balance while the software's in action (pacemakers, nuclear power plants, etc).

I've worked for NASA...

[dgm3574]

...and I can tell you NASA is far from perfect. This is no different from any other organization, governmental or otherwise. I do have a certain empathy for them now though, because working there does give you a certain insight into why they do things the way they do. Given their limited resources, it's amazing how successful they are, most of the time.

Considering that we give NASA less than we give the National Park Service, it's utterly dumbfoundingly breathtaking what they are able to accomplish.

It also doesn't hurt that the shuttle software engineers are a totally different breed. Or more to the point, the way they write software is totally different. This is a good writeup about why.

Not again...

[denttford]

To paraphrase the a late Romulan Senator...

It's a DUUUUPE.

So, to forestall any of the previous idiotic comments;

• yes, NASA has known of this for a while;
• it's considered a limitation, not a bug;
• no, none of your two second psuedo code hacks are of any value or insight,
• because the ~450,000 lines of operational software is written for 0 bugs and in HAL/S (so thanks for the quick C++ hacks, they are useless),
• calendar math is trickier than it looks; many date libs are replete with hacks and magic numbers
• you are not a better programmer than the guys and gals who write this stuff, and Lockheed has quite a bit of experience in doing this stuff.

Oh, and for the most ridiculous of stuff: Linux is not an option for critical shuttle systems; it is not a reliable RTOS - when you are orbiting at 18,000mph, a 1 second error puts you miles off course, though Debian was used at least once in monitoring an onboard experiment.

Can we all move on?

Re:Structured code

[Harmonious Botch]

if (GetTickCount() > dwOldTickCount + 50) { //do something, wait 50 milliseconds, do it again dwOldTickCount = GetTickCount(); } You found the slashdot comments overflow bug!

Re:So....

[kimvette]

There may be problems introduced into navigation systems by setting the clocks wrong.

However: shouldn't they be able to test this in simulators?