Slashdot Log In
NASA Avoids "Happy New Year" On Shuttle
Posted by
CmdrTaco
on Sun Nov 12, 2006 09:20 AM
from the also-booze-is-heavy dept.
from the also-booze-is-heavy dept.
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 :)
Related Stories
[+]
Computer Date Glitch May Limit Next Shuttle Launch 354 comments
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.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
So.... (Score:4, Funny)
Thank you, thank you, I will be here all week. Be sure to check out our Safari bingo!
Re: (Score:3, Interesting)
However: shouldn't they be able to test this in simulators?
Nasa shuttle software designed by Taco ;) (Score:5, Insightful)
Re: (Score:3, Funny)
Re: (Score:3, Insightful)
In reality isn't this a design limitation rather than a bug in the implementation?
It is. It was a deliberate choice to do things this way when the system was conceived of. Ignore the retards who keep calling this a "bug".
Every last little detail of sp
Dupe (Score:5, Insightful)
No they can't run linux, linux is not something you use to fly a shuttle with people in it, can't support the hardware and it was written 30 years ago.
And no, it's not easy to fix bugs in a piece of software like this.
Re:Dupe (Score:5, Funny)
Structured code (Score:2)
It is if the code is structured properly. All clock changing routine should be in one chunk, so that only one change need be make, and if you make one change, it affects the entire pr
Re: (Score:2)
I don't thing all the software on the shuttle is one piece of code anyway.
Re: (Score:2)
Re:Structured code (Score:4, Insightful)
The problem has nothing to do with how the code is structured.
In fact, they're not sure there's a problem changinge the date at all.
They're worried that something might happen. Some Windows programs, for example, use the function GetTickCount() for timing - menu delays, simple animation, etc. GetTickCount() returns a DWORD value representing the number of milliseconds since the system was booted, and a common usage is:
However, if GetTickCount() overflows and wraps to 0 (how quickly this happens depends on the processor architecture), it could be another month (32-bit DWORDS means 2^32 milliseconds is ~ 49.7 days) before GetTickCount() is "more" than dwOldTickCount again. Your event that was supposed to happen every 50 milliseconds is on indefefinate hiatus.
Granted, there are many better and different ways to write event code in Windows - it's kinda what the API was made for - and the space shuttle sure as hell doesn't use the Windows API, but that's not the point. It's little timing bugs like these that could pop up even in code that's been reused and debugged since God knows when.
So, since there's no reason whatsoever that they have to fly on New Year's, why risk the lives of astronauts and an expensive shuttle? I wouldn't have that much faith in some '70s programms usage of the carry flag.
It's not a problem that the "clock changing routine" that is probably some trivial count-on-one-hand number of machine language instructions is spread all over creation like a clown guts over the walls of my living room - it's that NASA doesn't want any glitches to happen in any procedure that uses the system clock like the Windows API example above. Which I'm guessing is pretty close to 99 and a half point two percent of their code.
Re: (Score:3, Interesting)
Re: (Score:2)
Subscribe to Slashdot and see the next dupe early! (Score:2)
Re: (Score:3, Funny)
because it's too damned hard to .... (Score:2, Interesting)
That is absolutely insane that
Re: (Score:2)
Re:because it's too damned hard to .... (Score:4, Interesting)
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).
Re: (Score:3)
Re:because it's too damned hard to .... (Score:5, Insightful)
The space shuttle is monumentally complicated. It's controlled by multiple computers. Test cases aren't just typing some stuff in and clicking on a few menus. The computers are hooked up to instruments and relays and motor controllers, and all of that would probably have to be convincingly "faked" for the test to be rigorous.
Re: (Score:2)
Re: (Score:2)
That would be a maneuvering thruster. Sorry for sloppy writing.
Like, shouldn't they have tested this years ago? (Score:2)
The second test would be for a leap year. February 29
The last test for December 31st on a leap year. Set the clock to December 30th and then le
Re:Like, shouldn't they have tested this years ago (Score:3, Insightful)
Re:Like, shouldn't they have tested this years ago (Score:2)
They could have tested this on the ground, but then again the /. editors could have checked that this news story hadn't already been posted about. I mean cut them some slack, they're only human.
Re:Like, shouldn't they have tested this years ago (Score:2)
That is 70's tech, when the shuttle's code was written in the first place.
Re:Like, shouldn't they have tested this years ago (Score:2)
Re:Like, shouldn't they have tested this years ago (Score:2)
When am I? (Score:4, Funny)
Re: (Score:3, Funny)
Wait, so this means that... (Score:2)
In 25 years of Shuttle Operations (Score:2)
I find this particularly difficult to believe.
I dub thee... (Score:2)
I've worked for NASA... (Score:3, Interesting)
Considering that we give NASA less [nasa.gov] than we give the National Park Service [nps.gov], 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. [fastcompany.com]
Not again... (Score:5, Interesting)
It's a DUUUUPE.
So, to forestall any of the previous idiotic comments;
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?
Does the date really matter? (Score:2)
Logs will be screwey? Try sed.
Say What?! (Score:4, Insightful)
When not designed by an idiot, a system clock is a linear device that measures the elapsed time since some reference "moment in time". It doesn't know that it's Thanksgiving, New Years, or any other socially significant but otherwise irrelevant date. It has sufficient resolution to measure the smallest interval of interest and sufficient range to outlive the system.
If the shuttle system clocks use year, month, day, etc., there's a lot that should be done, not the least of which is finding whoever made the design decision and take him out to a public place where thousands of engineers and programmers will point at him and laugh.
Re:Simple! (Score:4, Insightful)
How do you know the leapyear code works?
Wouldn't your code have to do a year++ line?
Does it matter which direction they are travelling, is it not possible to technically flipflop between one year and the next based on where you are flying over?
What will happen to systems if the day variable is less than the previously stored one, will it cause the ship to flip out and attempt a burn?
Too many factors, nasa is right at the moment.
Re: (Score:2, Informative)
Re:Simple! (Score:5, Insightful)
It doesn't, in the sample provided anyway. If $leapyear is true, $day never gets set back to one...
In any case, they already need to contend with uneven numbers of days in each of the various months anyway, and have to contend with leapyears every February 29th. So they're already (successfully) dealing with incrementing days, and months. I fail to see how they can't cope with years as well... C'mon, this is NASA and it's not the 1970's any more.
Once space travel approaches the speed of light I'll start to buy excuses about the difficulties of tracking time. Until then, sorry - No Sale.
Timestamps (Score:3, Insightful)
What will happen to systems if the day variable is less than the previously stored one, will i
Re:Simple! (Score:4, Insightful)
I am concerned that you think this issue is really a big problem. I am very worried if NASA thinks this is a big problem too - especially after all these years. While you don't want to underestimate potential problems like this, handling something as trivial as a date change is hardly 'rocket science' by NASA standards. Banks, financial institutions, air traffic control and military and emergency services systems handle this sort of thing just fine.
The reality is that decent testing procedures make issues like this routine to handle, and of course you set out a documented roll back procedure if something goes wrong (and list post-change checks to perform to see if something did go wrong or not). NASA have the ability to easily replicate the conditions for a test like this on the ground. If you didn't test a scenario like this on the ground and it was really a problem, there is no reason why it couldn't just as easily seem to work fine, but then only cause problems once the systems were up in the air.
I really can't believe the justification for not doing missions over Christmas and New Year is fear of a potential technical problem, even if it is a quote from Joan Higginbotham (who is evidently very experienced and ought to know a lot more about than this than I do). I can't see any reason why they couldn't easily have tested this on the ground (and would be surprised if they hadn't tested this sort of thing as part of Y2K compliance evaluations).
I am inclined to think the real reason they don't like doing missions over the Christmas period has a lot more to with culture and staffing issues (what with everyone bound to want time off), rather than them being worried their code is that much shonkier than the software that powers our electricity grids, phone lines, air traffic control and avionics systems that all run happily over the New Year period.
I suppose another possibility is that NASA is tangled up in bureaucracy and is so risk averse now that they feel they can't do something like this without a great deal of highly formalized testing - which they don't have the budget to do.
I once had the honour of speaking briefly to an astronaut from space on Skylab 4 (he is one of NASA's ASF speakers I think, I have is details somewhere - I think it was either Gerald Carr or Edward Gibson but I couldn't be 100% certain) and I ask him a question relating to when, in his opinion, we might realistically expect to see a manned mission to Mars and where, back in the 70's, he had expected us to be now in 2001 (this was in the November after 9/11).
As I recall, he said he had expected us be on Mars already and he seemed almost annoyed and was just barely perceptibly emotional that this wasn't the case (I got the impression he response made the NASA PR representative near by unconformable because they started fidgeting). While trying to avoid being insensitive I asked him why he thought we weren't there yet, and - after pausing briefly - he said the primary reason was a lack of investment and a lack of political will, he was quite emphatic on insisting that he thought we absolutely had the ability to undertake a manned mission, if their was enough political will and sufficient investment was made.
I'd never really thought about it before, but the state of the current current space programme must be a big disappointment for those who did so much pioneering work in the 60's and 70's. We have greatly superior technology and there is plenty of money flowing around elsewhere but NASA only seem to be able to scrape by, keeping things ticking over (not that they arn't trying - stuff like the SRB separation video, the NASA TV podcast and the website are all good things IMO).
Isn't that their purpose? (Score:3, Funny)
The purpose of a space shuttle is to flip out and burn people. These rockets are so crazy and awesome that they f
Re: (Score:2)
Just like this quick fix [slashdot.org] huh?
Hope you guys never program anything I drive/fly!
Re: (Score:2, Insightful)
Now try that in assembler (Score:5, Insightful)
All right, I realise you were trying to be funny but it is a serious point. Progress is systems design is so rapid that stuff from the 70s and 80s is like something from another world - when the Shuttle software was being written, I was working on a reasonably state of the art system in which every critical function had to be written in assembler and the compiler output had to be hand edited - even after we had upgraded the CPU specification to the point that the EMP people were complaining that the only components on the CPU board that they had in their library were the resistors.
Getting really philosophical for a moment, how about this for a sobering thought? We still have the materials and skills to maintain medieval cathedrals. We could probably, without too much trouble, crew and maintain an 18th century ship. We can easily maintain a 19th century railroad engine. We still have early 20th century motor ships in service. We can (with difficulty) keep aircraft from WW2 flying. But keeping a 1980s reusable spacecraft going is extremely difficult, and a 10 year old mobile phone is about as much use as a chocolate teapot.
Stupid post (Score:5, Informative)
Well, We DO Know... (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
No. They're just not assuming they don't.