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

 



Forgot your password?
typodupeerror

NASA Avoids "Happy New Year" On Shuttle 181

Posted by CmdrTaco
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 :)
This discussion has been archived. No new comments can be posted.

NASA Avoids "Happy New Year" On Shuttle

Comments Filter:
  • So.... (Score:4, Funny)

    by Anonymous Coward on Sunday November 12, 2006 @09:22AM (#16813382)
    they have a Y2* bug?

    Thank you, thank you, I will be here all week. Be sure to check out our Safari bingo!
    • It's too bad they didn't think to just set the clocks back a couple months ;-)

      But then when they surf to a website on the shuttle, it might tell them that the cookie has expired.

      It's a problem they should fix, so that they can actually launch in an "emergency" situation.
      • Re: (Score:3, Interesting)

        by kimvette (919543)
        There may be problems introduced into navigation systems by setting the clocks wrong.

        However: shouldn't they be able to test this in simulators?
    • by sam1am (753369)
      Year N+1 bug?
  • by LiquidCoooled (634315) on Sunday November 12, 2006 @09:22AM (#16813388) Homepage Journal
    In reality isn't this a design limitation rather than a bug in the implementation?
    • Re: (Score:3, Funny)

      by stunt_penguin (906223)
      Pfft, 365 days should be enough for anyone.
    • Re: (Score:3, Insightful)

      by Iron Condor (964856)

      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 spaceflight depends on reliable timekeeping. Quick: you want to talk to Houston and ... where is Houston right now? How do you have to adjust your antenna and how do you have to move it per second to create a reliable link? There's just so many things that r

  • Simple! (Score:1, Funny)

    by aerthling (796790)
    if ($day >= 365 && !$leapyear) {
    $day = 1;
    }
    • Re:Simple! (Score:4, Insightful)

      by LiquidCoooled (634315) on Sunday November 12, 2006 @09:26AM (#16813424) Homepage Journal
      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: (Score:2, Informative)

        by Doc Ri (900300)
        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! (Score:5, Insightful)

        by hotdiggitydawg (881316) on Sunday November 12, 2006 @10:23AM (#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.
        • n 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.

          Actually - they aren't. The Shuttle software has no conception of anything but $DaysSinceLastNewYear and $SecondsOfFlight. (Used mostly to support navigation and guidance functions.)

          C'mon, this is NASA and it's not the 1970's any more.

          Guess when the ba

          • Hard, yes. Impossible, no. NASA have a huge budget, and enjoy the reputation of being the best and brightest. They've conquered problems of the most amazing difficulty. Not being able to fly because their systems can't cope with the year changing a digit sounds like a truly pathetic excuse in that context.
            • by jlarocco (851450)

              Hard, yes. Impossible, no. NASA have a huge budget, and enjoy the reputation of being the best and brightest. They've conquered problems of the most amazing difficulty. Not being able to fly because their systems can't cope with the year changing a digit sounds like a truly pathetic excuse in that context.

              NASA's budget isn't infinite. They'd have to find all the affected code, change it, document it, then regression test everything. That would be incredibly expensive.

              The alternative is to simply av

            • Not being able to fly because their systems can't cope with the year changing a digit sounds like a truly pathetic excuse in that context.

              If it were that simple - you'd have a point. But as I pointed out in the message you replied to - the Shuttle doesn't even know what year it is. You can imagine how highly I rate someones opinion of NASA who has the lack of reading comprehension you display.
      • Timestamps (Score:3, Insightful)

        by RAMMS+EIN (578166)
        ``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! (Score:4, Insightful)

        by @madeus (24818) <slashdot_24818@mac.com> on Sunday November 12, 2006 @11:13AM (#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).

        • Oh its a far greater problem than you or I could have imagined. NASA is also afraid of Fridays that are the 13th day in the month, and is afraid of Dec 24th. You never know when the Grinch might steal Christmas.
      • 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?

        The purpose of a space shuttle is to flip out and burn people. These rockets are so crazy and awesome that they flip out ALL the time and don't even think twice about it.
    • by Splab (574204)

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

      Hope you guys never program anything I drive/fly!

    • Re: (Score:2, Insightful)

      by evilbessie (873633)
      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...
    • by Flying pig (925874) on Sunday November 12, 2006 @10:37AM (#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 (Score:5, Informative)

        by Flying pig (925874) on Sunday November 12, 2006 @10:53AM (#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.
      • by RAMMS+EIN (578166)
        ``Progress is systems design is so rapid that stuff from the 70s and 80s is like something from another world''

        You'd be surprised. Unix and C are from the 1970s. X11 and C++ are from the 1980s. Douglas Engelbart gave a demo in 1968 ("The Mother of All Demos") that features a mouse, hypertext, videoconferencing, an IDE, and more. IP, TCP, FTP, SMTP, and POP3 are all from the 1980s. Many features of "modern" programming languages, such as garbage collection, object orientation, and reflection had also been in
    • by Detritus (11846)
      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.
    • by hey (83763)
      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 (Score:5, Insightful)

    by suv4x4 (956391) on Sunday November 12, 2006 @09:23AM (#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 (Score:5, Funny)

      by antifoidulus (807088) on Sunday November 12, 2006 @09:40AM (#16813494) Homepage Journal
      Shhhh!! You will destroy our smug sense of superiority with your facts!
    • "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?

      • 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.
      • 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 (Score:4, Insightful)

        by Z34107 (925136) on Sunday November 12, 2006 @11:02AM (#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: (Score:3, Interesting)

          if (GetTickCount() > dwOldTickCount + 50) { //do something, wait 50 milliseconds, do it again dwOldTickCount = GetTickCount(); } You found the slashdot comments overflow bug!
    • http://flightlinux.gsfc.nasa.gov/ [nasa.gov] It seems indicated that they do indeed run Linux.
      • by Detritus (11846)
        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.
    • The shuttles were designed 20 years ago, based on technology from 10 years prior to that. I think they should be a perfect fit.
    • Re: (Score:3, Funny)

      by antifoidulus (807088)
      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 (Score:1, Insightful)

    by TodMinuit (1026042)
    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.
    • by wasted (94866)
      ...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.
    • by ceejayoz (567949)
      Even more unbelievable: they can't just set the Shuttle computers' date forward to 31 December 2006 and see what happens.
      • by bentcd (690786)
        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.
    • by gad_zuki! (70830)
      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.'
  • What a great chance to find out. Go on... give it a go.
    • 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.

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

    • by HaloZero (610207)
      Freakin, spin the clock ahead to Dec 31, 2999 and see what happens.
    • by eldavojohn (898314) * <eldavojohn@nOsPam.gmail.com> on Sunday November 12, 2006 @09:31AM (#16813440) Journal
      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).
      • by espo812 (261758)

        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 sp

      • by turgid (580780)

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

        What? On triple time?

    • by Barnoid (263111)
      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.
    • by Rostin (691447) on Sunday November 12, 2006 @10:03AM (#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.
      • 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 t

      • by Kjella (173770)
        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 in
    • 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.
    • because it's too damned hard to it in one on the ground and have it turned on that night.

      Oh, it's trivially easy to have one on the ground (in the OPF or the VAB) and turned on that night - but that wouldn't prove anything. The problem is in the interface between the ground software and the shuttle software, and sitting in the OPF or VAB, the shuttle can't be hooked up to the computers in Mission Control. (I.E. the problem isn't that the shuttle computers will crash - but that they will start rejecting

  • 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 t
    • 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.
      • by hitmark (640295)
        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
    • 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.

    • 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
    • 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.
    • 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 netwo
    • 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
  • When am I? (Score:4, Funny)

    by Manchot (847225) on Sunday November 12, 2006 @09:32AM (#16813448)
    1999 called, and it wants its computer problems back.
    • Re: (Score:3, Funny)

      by Manchot (847225)
      1995 called, and it wants its slang back.
    • The Y2K Bug had very little to do with "saving RAM", or whatever. It was just plain laziness and psychological conditioning. Somewhere along the line it became acceptable to write down two digits for a year. How many forms would a person come across last century that had "19__ " preprinted in the year field: License renewal forms, credit card receipts, dry cleaning tickets, medical history forms, etc.? I still come across the occasional form like that and it's 2006 for Pete's sake! Not storing the cen
  • ... 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?
  • 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.
    • by Detritus (11846)
      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.
    • It was a deliberate decision, and part of the design specs for the shuttle. "The shuttle computers were never envisioned to fly through a year-end changeover," space shuttle program manager Wayne Hale told a briefing.
    • by JetScootr (319545)
      Yes, we have. I've worked at NASA's training simulators since the ALT (Approach and Landing Tests) of Enterprise. I speak for myself, not for NASA or my employer.
      A human-rated system's safety is based on this primary rule:
      Don't prove it's unsafe - prove that it's safe.
      A good gov't management system's economics are based on this rule:
      Don't prove it'll work - prove that we MUST do it in order to achieve the mission.
      The shuttle is interfaced to the whole fricken universe in a way the PC in yer mom's basement
  • I dub thee the "Y++ bug", sir software defect.
  • by dgm3574 (153548) on Sunday November 12, 2006 @10:38AM (#16813814) Homepage
    ...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]

    • It seems you're reading the NASA budget request wrong. The total NASA request for 2007 is 16.356 billion dollars [whitehouse.gov], nearly eight times as much as the $2.156 billion requested [nps.gov] by the National Park Service. You may have reached the wrong conclusion by reading the requests made by the individual "Themes", of which NASA has several. For instance, the Earth-Sun system theme, which is under the Science Mission Directorate, is requesting $2.210.6 billion alone, more than the NPS's total budget.

      I'll avoid any com

  • Not again... (Score:5, Interesting)

    by denttford (579202) on Sunday November 12, 2006 @10:44AM (#16813846) Homepage
    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?
    • Thanks! You got to it before I did :) Here's some more items:

      1) NASA has known about this at least as early as 1980, *before* the first shuttle flew. The computers onboard the shuttle are IBM AP101Ss with 64K of RAM and capable of a blindingly fast 1.2 million operations per second. Remember overlays from your DOS days? They are used extensively (major mission modes). Every *bit* of RAM is accounted for.

      2) I haven't seen any FMEA/FMECA (Failure Modes Effects Criticality Analysis) posts here on Sl
  • 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.
    • Yes it does. The day of year (day 273 for instance) is used extensively throughout the infrastructure (Kennedy, Johnson, various monitoring stations) that support the shuttle missions. Yes, it probably would screw up the accuracy of the logs (real-time databases) and no, you can't throw a sed script at it. Shuttle Engineers live and die by the accuracy of their logs. In addition there are possible side affects, such as ground-based commands being discarded by the shuttle since they are now "stale".
  • Say What?! (Score:4, Insightful)

    by thethibs (882667) on Sunday November 12, 2006 @11:01AM (#16813968) Homepage

    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.

  • Do they have an issue with Day Light Savings changes as well?

    It would be like an episode of the Twilight Zone where an astronaut goes into space and somehow finds himself in the past or the future, only this time it would be only by an hour... :-P
  • It seems to me that both shuttle disasters were in part caused by cold weather. With the Challenger it was brittle O-Rings and with the Columbia it was iced-up chunks of insulation. Perhaps there should be a mandate that the shuttle can launch only if the area's temperature has been above, say, 55 degrees F for 48 hours?
  • by hurfy (735314)
    They don't have one they can turn on for new years?

    One would think just for curiousities sake someone would have tried it by now. Does the simulator go to a blue screen if ya play on new years?

    hmm, perhaps they know it doesn't work well :(

    PS. The calender on my 70's computer is complete to 2030. A tad optimistic on Wang's part perhaps :)
  • If they wanted to disguise the site maybe they shouldn't have had the results page look just like Google.com with a different header. You'd think they'd at least make the link colors match the color scheme of the rest of the site.
  • Remember - the shuttle talks to satellites, to ground radios, to MCC, to the ISS and Russian communications networks.
    All of the communications networks have to know exactly where two parties are when talking, and where the Earth itself is in its orbit around the sun. Doppler shift must be taken into account when radioing between all of these.
    Sure, year-end rollover is about 1-5 lines of code; how many places need that fix?
    This is just one example of why NASA decided it was easier to just wait a few days ra

Old programmers never die, they just branch to a new address.

Working...