Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

NASA Avoids "Happy New Year" On Shuttle

CmdrTaco posted more than 7 years ago | from the also-booze-is-heavy dept.

181

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 :)

cancel ×

181 comments

Sorry! There are no comments related to the filter you selected.

So.... (4, Funny)

Anonymous Coward | more than 7 years ago | (#16813382)

they have a Y2* bug?

Thank you, thank you, I will be here all week. Be sure to check out our Safari bingo!

Re:So.... (1)

Wiarumas (919682) | more than 7 years ago | (#16814646)

Beware of Y27.

Nasa shuttle software designed by Taco ;) (5, Insightful)

LiquidCoooled (634315) | more than 7 years ago | (#16813388)

In reality isn't this a design limitation rather than a bug in the implementation?

Re:Nasa shuttle software designed by Taco ;) (1)

sentientbeing (688713) | more than 7 years ago | (#16814022)

I never thought space flight was so complicated.

Nasa is right. Maybe we should all just stay here on the ground.

Re:Nasa shuttle software designed by Taco ;) (2, Funny)

stunt_penguin (906223) | more than 7 years ago | (#16814118)

Pfft, 365 days should be enough for anyone.

Simple! (1, Funny)

aerthling (796790) | more than 7 years ago | (#16813392)

if ($day >= 365 && !$leapyear) {
$day = 1;
}

Re:Simple! (4, Insightful)

LiquidCoooled (634315) | more than 7 years ago | (#16813424)

How many places would you have to put that code in and could you be sure it will work?
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:Simple! (2, Informative)

Doc Ri (900300) | more than 7 years ago | (#16813600)

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?
I do not know, but I would assume the mission time is always the same time zone. Possibly GMT.

Re:Simple! (1)

gsonic (885510) | more than 7 years ago | (#16813638)

Can't they just change the date and fucking test the whole thing in advance???

Re:Simple! (1)

LiquidCoooled (634315) | more than 7 years ago | (#16813682)

I would say no, they would have to run everything through in realtime.
If you just jump into code without the stack in the correct state you will get invalid results.
Try it sometime by just jumping into some random working code and see how many things fuck up.

Re:Simple! (4, Insightful)

hotdiggitydawg (881316) | more than 7 years ago | (#16813726)

if ($day >= 365 && !$leapyear) {
$day = 1;
}
 

How do you know the leapyear code works?

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 (2, Insightful)

RAMMS+EIN (578166) | more than 7 years ago | (#16813770)

``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?''

They could just use timestamps. Something simple, that just increases at a fixed rate. Then convert it to a date when necessary (rarely, probably).

Re:Simple! (3, Insightful)

@madeus (24818) | more than 7 years ago | (#16814056)

Too many factors, nasa is right at the moment.

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).

Re:Simple! (1)

Splab (574204) | more than 7 years ago | (#16813466)

Just like this quick fix [slashdot.org] huh?

Hope you guys never program anything I drive/fly!

Re:Simple! (1)

Almighty Tallest (933831) | more than 7 years ago | (#16813626)

Yeah, this is a multi-milllion dollar vehicle that hurls humans into space, and is supposed to bring them back again. Not something you can just slap a fix on and test in a live environment.

Re:Simple! (2, Insightful)

evilbessie (873633) | more than 7 years ago | (#16813624)

actually not that simple more like if ($day > 365 && $leapyear = 0){ $thisday = $day - 365 }elsif($day > 366 && $leapyear = 1){ $thisday = $day - 366 }else{ $thisday = $day } Your code has every day of any year that is not the first (and december 31 of the first year as you used >= 365) as day 1...

Re:Simple! (1)

aerthling (796790) | more than 7 years ago | (#16813720)

Yeah, I know.. my code sample does completely suck. However, since Slashdot's fancy new Web 2.0 redesign doesn't include any comment-modification capabilities, I'm holding them partially responsible.


;)

Re:Simple! (1)

cyber-vandal (148830) | more than 7 years ago | (#16814016)

You should really have known better than to post a hastily thought out code snippet in this nest of pedants.

Re:Simple! (0)

Anonymous Coward | more than 7 years ago | (#16813696)

"$day >= 365" ???
Greater than or equal?

So the last day of the year is skipped?

I sure hope you don't get a job as a NASA programmer.

Although I'm sure php-skills isn't really required programming shuttle software.

Re:Simple! (1)

LindseyJ (983603) | more than 7 years ago | (#16814076)

Although I'm sure php-skills isn't really required programming shuttle software.

But the ability to speak and write proper English just may be.

Re:Simple! (1)

cucucu (953756) | more than 7 years ago | (#16813788)

Your code is to risky. You have to maintain it, write unit tests, use test coverages suites, check the code is being covered.

A better risk containment policy is to synchronize all on board clocks to January 1st 1970 before takeoff.

Now try that in assembler (4, Insightful)

Flying pig (925874) | more than 7 years ago | (#16813804)

Given the vintage of the Shuttle computers I suspect that they are programmed in assembler. There are all kinds of possible issues; what makes you think that the internal representation of time is anything that involves days, or how dates received from outside are translated?

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 (4, Informative)

Flying pig (925874) | more than 7 years ago | (#16813898)

Sorry about that stupid post. Yes of course the Shuttle computers are programmed in HAL and in fact I knew that, if I only had woken up my older brain cells.

Re:Now try that in assembler (0)

Anonymous Coward | more than 7 years ago | (#16814368)

We could probably, without too much trouble, crew and maintain an 18th century ship.

Ah, you must mean Old Ironsides. [wikipedia.org]

I heard Bush and the Democrats are thinking about deploying her to help out with a duty station in the Gulf.

Re:Simple! (1)

john83 (923470) | more than 7 years ago | (#16813904)

Oh, sure. Then
air_remaining = total_air - air_const*(today-start_day);
if (air_remaining < 0.1*total_air) sound_alarm();

Good luck with that.

Re:Simple! (1)

Detritus (11846) | more than 7 years ago | (#16814130)

Your code can fail in various unpleasant ways if it is preempted by an interrupt or task switch, or runs on a multi-processor system.

Re:Simple! (1)

hey (83763) | more than 7 years ago | (#16814652)

Beside the comments that you have a bug in non-leap years (ie most years) this might have
a problem because some function might compare days and would be confused if time started to back up.
So it would be better to never move it backwards. ie allow day 366, 367, ...

Dupe (4, Insightful)

suv4x4 (956391) | more than 7 years ago | (#16813396)

Verdict from last time:

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 (5, Funny)

antifoidulus (807088) | more than 7 years ago | (#16813494)

Shhhh!! You will destroy our smug sense of superiority with your facts!

Structured code (1)

Harmonious Botch (921977) | more than 7 years ago | (#16813524)

"And no, it's not easy to fix bugs in a piece of software like this."

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 program. We learned things like this in undergrad compsci. Why can't NASA get it right?

Re:Structured code (1)

TorKlingberg (599697) | more than 7 years ago | (#16813710)

I guess the problem is not changing the clock, but that something might go wrong if they do.

I don't thing all the software on the shuttle is one piece of code anyway.

Re:Structured code (1)

John Courtland (585609) | more than 7 years ago | (#16813978)

What if some other piece of the code has a dependency on the way this code works now? You go and change it and it breaks something else. Even if the fix is simple, there's not a chance in hell it will pass NASA's QA before Dec 31.

Re:Structured code (3, Insightful)

Z34107 (925136) | more than 7 years ago | (#16813984)

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:

if (GetTickCount() > dwOldTickCount + 50) {

//do something, wait 50 milliseconds, do it again

dwOldTickCount = GetTickCount();

}

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:Dupe (1)

the linux geek (799780) | more than 7 years ago | (#16813542)

http://flightlinux.gsfc.nasa.gov/ [nasa.gov] It seems indicated that they do indeed run Linux.

Re:Dupe (1)

Ulky (199350) | more than 7 years ago | (#16813562)

I thought they ran something which used the QNX RTOS kernal?

Re:Dupe (1)

Detritus (11846) | more than 7 years ago | (#16814050)

No. They run a custom software package that is known as PASS (Primary Avionics Software System) or PFS (Primary Flight System). It's a real-time system that was written for NASA by IBM.

Subscribe to Slashdot and see the next dupe early! (1)

jginspace (678908) | more than 7 years ago | (#16813402)

Computer Date Glitch May Limit Next Shuttle Launch [slashdot.org] - exchange Reuters article for CNN article.

Re:Subscribe to Slashdot and see the next dupe ear (2, Funny)

antifoidulus (807088) | more than 7 years ago | (#16813598)

I thought the "computer date glitch" was when you meet some hot little 20-something on match.com but she turns out to be an overweight 45 year old named "Bruno"

Riiight (1, Insightful)

TodMinuit (1026042) | more than 7 years ago | (#16813410)

You have got to be kidding me. You can fling a rover somewhere in the direction of Mars and somehow hit it, model how the sun works, and take pictures of the center of the galaxy, but we don't know what will happen when the shuttle moves from one year to the next?

This has to be a cover up of some kind.

Well, We DO Know... (2, Insightful)

wasted (94866) | more than 7 years ago | (#16813640)

...what would happen if the Shuttle is aloft during the year change. A lot of NASA employees have to work the normal shuttle work schedule, and miss their New Years parties, having probably just missed Christmas with their families.

Re:Riiight (1)

ceejayoz (567949) | more than 7 years ago | (#16813688)

Even more unbelievable: they can't just set the Shuttle computers' date forward to 31 December 2006 and see what happens.

Re:Riiight (1)

bentcd (690786) | more than 7 years ago | (#16814106)

Well, it's one thing to record what happens when the shuttle sits snugly on the ground. I expect it's another thing entirely what happens when the shuttle is in orbit, busy calculating trajectories, and firing alignment boosters when the date suddenly flips (or not).
I expect they'd have to run a relatively expensive simulation to find out how, exactly, the shuttle would perform in actual operating conditions in this case.

Re:Riiight (1)

gad_zuki! (70830) | more than 7 years ago | (#16814170)

None of those things means failure = human death. Testing something that people fly in is a lot more complex than 'set the clock to midnight and see what happens.'

Test case (1)

Petronius.Scribe (1020097) | more than 7 years ago | (#16813414)

What a great chance to find out. Go on... give it a go.

Re:Test case (1)

pedantic bore (740196) | more than 7 years ago | (#16814040)

Indeed. They don't even need to launch the thing in order to find out. They just need to leave the computer running. Given the way they test these things, I'm sure they don't need to actually light the rockets in order to simulate a launch.

Maybe the hard part is finding a NASA engineer with nothing better to do on New Years Eve than see whether some counters roll over or not.

because it's too damned hard to .... (2, Interesting)

Lumpy (12016) | more than 7 years ago | (#16813418)

...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 .... (1)

HaloZero (610207) | more than 7 years ago | (#16813430)

Freakin, spin the clock ahead to Dec 31, 2999 and see what happens.

Re:because it's too damned hard to .... (3, Interesting)

eldavojohn (898314) | more than 7 years ago | (#16813440)

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).

Re:because it's too damned hard to .... (2)

espo812 (261758) | more than 7 years ago | (#16813966)

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
This requires resources (time, money, and effort.) A lot of federal agencies, NASA included, don't have a whole lot of resources so they have to prioritize work for the most bang for the buck. This activity probably hasn't made the cut.
or point the software at an NTP server and set that to the time it transitions.
First RFC on NTP: 18 April 1981 [ietf.org] . First space shuttle flight: 12 April 1981 [nasa.gov] . NTP wasn't invented (or at least standardized) when the shuttle was designed or even built. I'm guessing it isn't implemented on the shuttle.

Re:because it's too damned hard to .... (1)

Barnoid (263111) | more than 7 years ago | (#16813456)

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?


consider that they don't even have to have a guy sitting in over the new years...it shouldn't be too hard to set the date to Dec 30 on a normal Monday morning and watch the transition the next day.

Re:because it's too damned hard to .... (0)

ZeroExistenZ (721849) | more than 7 years ago | (#16813582)

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.

They're afraid of undocumented features, fe. the firework-mode.

Re:because it's too damned hard to .... (4, Insightful)

Rostin (691447) | more than 7 years ago | (#16813612)

It's probably a little harder than you think. If the space shuttle were MS Notepad, your idea would probably work without a hitch. We'd start it up, wait for the new year to roll over, and then test to see if we could still type and a save and open documents. Test done.

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:because it's too damned hard to .... (1)

daemonburrito (1026186) | more than 7 years ago | (#16814312)

Overall, I think your point is correct. But I think you may have some misconceptions about the shuttle. The operating software is amazingly compact (700k I think) and written in a high-level language. The total memory available is just 1 megabyte. While it's true that there are multiple computers, the reasoning behind this is redundancy (there are five, are think, that check eachother out for reliability). So in reality - tiny software environment (loaded from tapes!), 1 MB total system memory, and one kind of wimpy (but EXTREMELY simple and reliable) computer.

For whatever it's worth, here's some wikipedia [wikipedia.org] .

Re:because it's too damned hard to .... (1)

eldavojohn (898314) | more than 7 years ago | (#16814338)

The space shuttle is monumentally complicated.
You're right, it is. However, there must be some mechanism in there that keeps everything synced. Since the time that various controllers & components execute is most likely of critical importance, don't you think they would have a scheme such that one component controlled the time?

It would probably be necessary only to make modifications to the component that controls the relative time and accounts for network drift. I don't know first hand that they have a scheme that works this way but I would almost wager they would have to have something like this in effect.

It's controlled by multiple computers. Test cases aren't just typing some stuff in and clicking on a few menus.
You're right, but we're talking about an agency that put a man on the moon in 1969. To say that today they lack the creative imagination to test a set of computers and electronics for a date-time problem is pretty much a slap in the face.

Test cases aren't just typing some stuff in and clicking on a few menus.
Then perhaps it's time they rewrote the test cases & the software that executes the test cases if they want to be using this in the future and at the risk of human lives?

Re:because it's too damned hard to .... (1)

Kjella (173770) | more than 7 years ago | (#16814360)

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.

I assume they would already have such a setup, for whole system integration test. I'd be damn scared if they sent it up without testing everything together at once. And then the only input you'd need to change were the clocks onboard (CPU, atomic etc.) and rerun with the same sensor data.

I'm not sure how they'd screw this up anyway, the change of year is usually a completely insignificant number for computers, except when stored in human-readable format (which was the whole y2k-hysteria). Computers that operate on time_t or similar won't crash - at least not on January 1st. I suppose it's in theory possible if someone somewhere is converting just the date part to some internal buffer, but there's no space to save compared to time_t since it won't fit in anything less than 32 bits anyway. Msybr if they're using sub-second precision and threw out the year for a tighter fit, I don't know. It sounds to me like an awfully strange practise at least.

Re:because it's too damned hard to .... (1)

TorKlingberg (599697) | more than 7 years ago | (#16813738)

I don't think it's as simple as the whole system crashing when passing new year. More like if some course correction rocket is fired a millisecond before midnight, and is never turned off.

Re:because it's too damned hard to .... (1)

TorKlingberg (599697) | more than 7 years ago | (#16813786)

"course correction rocket"

That would be a maneuvering thruster. Sorry for sloppy writing.

Like, shouldn't they have tested this years ago? (1)

TomTraynor (82129) | more than 7 years ago | (#16813420)

What would it have taken them to run on the ground with the computer set to December 31st and see what happens?

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 let it cycle through operations until January 1st.

I know it is obvious, but, what happened to them trying this out? I do this on programs where we depend on dates and it is part of our normal unit test if we touch the date logic. The client then verifies this on their validation test runs.

Re:Like, shouldn't they have tested this years ago (3, Insightful)

LiquidCoooled (634315) | more than 7 years ago | (#16813436)

My guess is the systems are based upon days - ie the mission is 14 days long, if the day counter rolls backwards as others have suggested passing a negative delta into certain functions could fuck it up and just testing one day either side would not necessarily test it properly.

Re:Like, shouldn't they have tested this years ago (1)

ST47 (965252) | more than 7 years ago | (#16813500)

if it is based upon days, then why would they need to worry about whether day 1 was in the same year as day 14 or not? just tell it to do this on day 14

Re:Like, shouldn't they have tested this years ago (1)

hitmark (640295) | more than 7 years ago | (#16814100)

so your basically saying that the shuttle computer counts down from the day of launch, and when passing the new year "line" suddenly the day of launch is ahead of the present day, not behind?

sounds a bit silly as i don't see why they would even bother to have it calculate dates if they used in that way. that is unless it counts dates but not years. and that brings it above and beyond the y2k "bug" imo...

but then one should take into consideration that the shuttle computers are seriously old! something tells me the designs was done the way it was to save space in the ram.

ugh, i just hope that whatever replace the shuttle is built so that it can be upgraded in modules later on...

Re:Like, shouldn't they have tested this years ago (1)

wpanderson (67273) | more than 7 years ago | (#16813502)

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 (1)

jackb_guppy (204733) | more than 7 years ago | (#16813540)

Actaully they should have just done this as Day 1, Day 2, Day 3... Since a shuttle mission is ALWAYS less than 1 year. Then a simple offset from base date is all that was needed.

That is 70's tech, when the shuttle's code was written in the first place. Shoot, I did this '83 to get around our 5 digit Julain date system to support a 232 year "centry" date system, so we could cross '99-'00 without a hitch. Yes, we did Y2k in 1983.

This is evne the system Unix uses to calculate dates. Though they are using a finer resolution counter.

Re:Like, shouldn't they have tested this years ago (1)

machine of god (569301) | more than 7 years ago | (#16813636)

It's not like they even have to wait for new years. I mean, they can set the date on the thing right? They could go find out right now.

Re:Like, shouldn't they have tested this years ago (1)

hey! (33014) | more than 7 years ago | (#16813902)

I'm sure they have. What they haven't done and can't do is test every possible combination of inputs and outputs of the system in ground testing. In the words of Mr. Rumsfeld, it isn't the known knowns, or the known unknowns, but the unknown unknowns that we have to worry about.

I was in college when the Shuttle first flew. In fact I had a couple of friends over and we got up early to watch the very first launch -- we were among the last of the diehards to religiously watch space launches carried on network TV.. If you recall, the first launch was delayed two days because of a computer glitch. There was fourfold redudancy in the computer systems, and a slight timing skew caused the computers to shut each other off. One of my friends had a father who worked on the system. He had been against the idea of having five computers, on the grounds that for the same cost they could make one, better computer whose overall chance of failing was less. It turned out he was right, and in fact this criticism forshadowed other problems in the Space Shuttle.

The bottom line is that the Shuttle's systems are too complex to test except in real use, and then it is probably imposisble to predict what they will do in unusual situations.

what would happen if you set the clock forward .. (1)

rs232 (849320) | more than 7 years ago | (#16814390)

What would it have taken them to run on the ground with the computer set to December 31st and see what happens?

HAL would think the mission was over and try and a runway landing from top of the launch pad. As someone else here has already pointed out you count the time in integers from a base year eg Feb 08 1828 and count up.

was Re:Like, shouldn't they have tested this years ago

Being an editor is hard (0, Flamebait)

svunt (916464) | more than 7 years ago | (#16813422)

Quality control is THIS [slashdot.org] difficult.

Well done, guys.

Re:Being an editor is hard (1)

jginspace (678908) | more than 7 years ago | (#16813470)

"Quality control is THIS difficult."

You're less scrupulously cynical than I am. I wouldn't have assumed they'd be consistent in putting Shuttle stories under science.slashdot.org ... but it appears they were [slashdot.org] after all.

When am I? (3, Funny)

Manchot (847225) | more than 7 years ago | (#16813448)

1999 called, and it wants its computer problems back.

Re:When am I? (2, Funny)

Manchot (847225) | more than 7 years ago | (#16813704)

1995 called, and it wants its slang back.

Better safe.. (1)

Ma8thew (861741) | more than 7 years ago | (#16813472)

Better safe than sorry. It would probably work fine, but why risk human lives when you can put off the launch for a few days.

Re:Better safe.. (1)

solevita (967690) | more than 7 years ago | (#16813608)

And get a decent holiday too. Flying the Shuttle around the earth must be fun, but through the festive season? I'd use any excuse I could to stay at home getting drunk and eating too much!

Re:Better safe.. (0)

Anonymous Coward | more than 7 years ago | (#16813848)

Nonsense. That's why they're astronauts, and it would do a good solid boost to the space program if we had Bruce Willis or Ben Affleck (in case Bruce's schedule doesn't permit) fly it on that day. Then Buscemi puts in the patch to the code while everything is falling apart, but he just about loses it right there...

Wait, whatdya mean they're not real astronauts? I want my money back!!

And to the /. eds, thanks for reposting. Sunday is perfect for articles like this.

They can't set the clock to do the test (0)

Anonymous Coward | more than 7 years ago | (#16813478)

Don't you know, it reads the time/date directly from the fabric of space-time!

Paranoid or Bunch of Jokers (1)

davro (539320) | more than 7 years ago | (#16813488)

Surly NASA are just being paranoid.
If they have no way of testing or simulating this test case then NASA have fallen seriously in my opinion.
Makes sense i suppose NASA are still building there shuttles out of sticky back plastic and foam.

NASA will be placed in my "Bunch of Jokers" category if this is for real.

Re:Paranoid or Bunch of Jokers (0, Troll)

heinousjay (683506) | more than 7 years ago | (#16813508)

Nothing like criticizing a situation you don't understand. Shows you're a real man. Or woman, I suppose.

Re:Paranoid or Bunch of Jokers (1)

davro (539320) | more than 7 years ago | (#16813680)

So the definition of a Real Woman or Man, is not criticizing a situation you understand ??

Re:Paranoid or Bunch of Jokers (1)

jimbo3123 (320148) | more than 7 years ago | (#16814172)

Yeah, who are we to criticize.

It's not like we're the ones paying for it....

Simulators? (1)

WED Fan (911325) | more than 7 years ago | (#16813506)

Do they not have a full mock up with computers? They can test and find...wait, I'm a government contractor, I should realize how the government works. Sorry, my mistake. Carry on.

Wait, so this means that... (1)

Channard (693317) | more than 7 years ago | (#16813528)

... if you've got one of those pens that work in space, you can't use them to write any time on New Years Day?

What? (1)

whitespiral (941984) | more than 7 years ago | (#16813532)

Is this the NASA what everyones quotes or references, as if they were always perfect, precise, infallible? Hahahaha...

Re:What? (1)

Albert Sandberg (315235) | more than 7 years ago | (#16814384)

NASA = Never Absolutely Sure of Anything.... right?

Scrap it (1)

WilyCoder (736280) | more than 7 years ago | (#16813564)

All the more reason to scrap the shuttle project and come up with a more efficient way to put people in space. NASA has a date/time bug? Come on!!!

Re:Scrap it (1)

RAMMS+EIN (578166) | more than 7 years ago | (#16813784)

``NASA has a date/time bug?''

No. They're just not assuming they don't.

party in a space shuttle? (1)

NRISecretAgent (982853) | more than 7 years ago | (#16813584)

yeah, put someone in the shuttle over New Years Eve and let the guy throw a party. Who wouldn't want to have a New Years party in a space shuttle? =)

Maybe test it? (1)

Bing Tsher E (943915) | more than 7 years ago | (#16813596)

If NASA hasn't tested such scenarios by 'setting the clock' and seeing how systems react, they are not texting their systems adequately.

This so often comes up with year-change issues. People get all sweaty like the 'realtime-clock' module can't be changed to simulate the conditions and see what will happen.

In 25 years of Shuttle Operations (1)

iendedi (687301) | more than 7 years ago | (#16813604)

In 25 years of Shuttle Operations, NASA has never had a real shuttle computer or simulator run over the transition to a New Year? Is this a Government beuracracy thing (e.g. Everyone on Holiday?).

I find this particularly difficult to believe.

Re:In 25 years of Shuttle Operations (1)

Detritus (11846) | more than 7 years ago | (#16814090)

Actually, yes. The ranges effectively shut down at the end of the year so that people can take vacations and time off for the holidays. You don't schedule stuff for late December unless you have no other choice. This isn't that unusual. Many large industrial operations have scheduled annual down-time. It's also an opportunity to sneak in maintenance activities that would otherwise disrupt normal operations.

Fp troolkOre (-1, Redundant)

Anonymous Coward | more than 7 years ago | (#16813610)

The mundane chores live and a job to replresents the

I dub thee... (1)

Chairboy (88841) | more than 7 years ago | (#16813642)

I dub thee the "Y++ bug", sir software defect.

who cares? (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#16813660)

its just a date. are the engines linked to what year it is? come on, what could possibly go wrong if the date is wrong? seriously.

I've worked for NASA... (3, Interesting)

dgm3574 (153548) | more than 7 years ago | (#16813814)

...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 [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]

Duck and cover (1)

Stumbles (602007) | more than 7 years ago | (#16813832)

Um, well if that is really an issue with NASA I'd have to say they have some under performing programmers or the ones they outsource with. I know the article talks about the shuttle and a complected piece of machinery it is. But all the satellites circling over head don't seem to have this "problem". Maybe NASA should hire those programmers.

Not again... (5, Interesting)

denttford (579202) | more than 7 years ago | (#16813846)

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 [fastcompany.com] , and Lockheed has quite a bit of experience [wikipedia.org] 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?

Does the date really matter? (1)

failure-man (870605) | more than 7 years ago | (#16813882)

Set the computers on the shuttle and on the ground for like, May. I can't imagine why they would need the actual date as long as they agree on what it is.
 
Logs will be screwey? Try sed.

Failure of Programmer(s) (0)

Anonymous Coward | more than 7 years ago | (#16813906)

It never ceases to amaze me how many bugs are the result of needless corner-cutting and/or a failure to consider even basic scenarios that might occur with the use of one's software. Neither the head of the project that created this software, or the engineers themselves didn't even think to themselves, "Hmmm, I wonder what will happen when our mission day counter flips around to zero"???? WTF? That's the first thing that would pop into my head. Anytime I am writing code with a hard limit in it my first thought is to consider how to deal with the case when that hard limit is reached or exceeded. NEVER assume that it won't be.

Of course you can't think of all scenarios, but this and Y2K were caused by a failure to simply ask one's self what the consequences to a particular programming decision would be.

CMM level 5 eh? (0)

Anonymous Coward | more than 7 years ago | (#16813934)

So much for a PROVED design system :)

Say What?! (4, Insightful)

thethibs (882667) | more than 7 years ago | (#16813968)

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.

As someone who grew up with NASA (1)

p51d007 (656414) | more than 7 years ago | (#16814176)

It saddens me to see how screwed up they have become over the last 30 years. I grew up with the achievements of NASA in its early days...Sheppard, Grissom, Glenn, landing on the moon. Now, we have a overly bloated NASA, which, mirrors the government...they have so many suits that have no clue what is going on, over/mis-managed etc. NASA programs computers, used on something that goes into space, without even thinking that it might be up there at the end of the year? How stupid is that? Personally, I'd like to see NASA broke up, and let private industry run the space program. They have too much "go fever". Screw safety, just get the d**n thing in the air. So far, we've lost 2 crews to the shuttle, something that shouldn't have been built in its present form. The original design didn't have SRB's, but an air breathing launch vehicle, but budget cuts after Apollo canceled that. The biggest mistake, IMO, was the cancellation of the Apollo program. The Saturn V launch vehicle had a 100% launch rate (don't confuse the Saturn V with the Command/Service vehicle). Had further research with the Saturn V continued, just think where we could have been. Instead of the crappy shuttle, held together with chewing gum and tin foil, we could have a better launch vehicle. Is it any wonder that now we are going back to the future with the new heavy launch vehicle?

Ummm, aren't these NASA people paid to figur (1)

Dark Leaper (989158) | more than 7 years ago | (#16814188)

Ummm, aren't these NASA people paid to figure this shit out? I mean, sweet Jesus, if they can't figure out a clock glitch, who knows what kind of impending Armageddon they overlooked.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>