Slashdot Mirror
Computer Date Glitch May Limit Next Shuttle Launch
n3hat writes "Reuters reports that the next Space Shuttle mission may have to be deferred if it gets too close to the New Year because the onboard computers do not handle the changing of the date in the same way as the ground computers. From the article: '"The shuttle computers were never envisioned to fly through a year-end changeover," space shuttle program manager Wayne Hale told a briefing. The problem, according to Hale, is that the shuttle's computers do not reset to day one, as ground-based systems that support shuttle navigation do. Instead, after December 31, the 365th day of the year, shuttle computers figure January 1 is just day 366."
How many times is this going to bite us in the ass? Ada solves all these sorts of problems, and soooo many of my tax dollars went into its creation? I understand that the space shuttle is a limited platform, but why aren't any of the lessons learned in Ada being applied?
How lame is that? Millions of dollars put into a shuttle and it can't even interpret the date correctly. Might as well just plug in my cell phone.
Is there a reason these aren't built on standard parts and operating systems? If they ran their shuttles on something like Debian stable it would be a rock solid platform and probably end up saving them lots of money. Or am I missing something here.
*ducks and runs for cover*
Seriously though- they never "envisioned" a mission occuring over the end-of-year? Let me guess: a defense (space) contractor designed the systems.
Please help metamoderate.
A computer dating error will affect the shuttle launch? I thought astronauts could get babes without resorting to computer dating...
The real problem is that the shuttle isn't y2k compliant, and their "workaround" was to reset the year to 1999 before each launch.
Pardon my ignorance, but is this really serious enough that it should actually cause a delay? I mean, if it's simply a matter of figuring out what the date is, I'm sure that the astronauts and engineers involved in the project know at LEAST basic mathematics, and can determine that if it's, say, Day 367 on the shuttle computer, then 367-365 = 2, AKA January 2nd, 2007.
I'd say the article missed something; the whole concept sounds far too ridiculous to stand on its own.
So we've been flying the space shuttle for almost 30 years and this was never viewed as a problem before? And we're trusting NASA to send astronauts to the moon and beyond over the next 20 years?
Crack - Free with every butt and set of boobs
it is. In fact, telltale sideburns show that some shuttles are still in the seventies...
I spend most of my time in bed, darling.
Sorry to sonud so skeptical....but am I the only one who is worried about capability of missiles (and other defence systems) to handle war through a year-end changeover?
hilarious
Just goes to show how going for the lowest bid on a contract screws everything up.
That's barely ten lines of code no matter what language you want it in...
Sloppy, dreadful, and as I like to say, "You get what you pay for"...
(Does anyone remember the multi thousand dollar toilet seat for the US Navy ?)
In this case, a setback sending 1970's technology into space......
About time the new vehicle gets rolled out.
Maybe we can get Timex to code it in...
Cheers
End of Line.
So far, there have been a bunch of comments on why this shouldn't have happened. Great, whatever. It is what it is.
So the question is, why does it matter? Day 1 or 366, it shouldn't matter, right? Unless they both didn't make it loop around and used functions heavily based on the date (not terribly likely), then what difference does it make? It's just December 31+1, so day-of-week, etc. should all remain correct.
It's not like NASA would just make a probably-multi-million-dollar-a-day wait because they felt like it. Obviously there's something up, so perhaps someone who knows could enlighten us?
Three cheers for the Y0.001K problem!
I have discovered a truly remarkable
Buck Rogers.
So, did they have to specially program the ground computers to act like all the rest on the planet, or did they leave out the few bytes this would have taken on the Shuttle to save some space?
The shuttle runs on three modified IBM 360 systems. Were pushing 35, almost 40 year old systems here.
Do you know how many eligible 35 year old computer bachelors there are out there? Ill tell you: none. Of course the shuttle computers can't get a date.
I used to write this kind of glitch into my kludgy Commodore BASIC Vic20 programs when I was a kid. I never thought I was good enough to be a professional though. Seems like maybe there's a chance for me after this? I reckon the shuttle could run with BASIC if sensible line numbers were used. And GOSUBs for that professional touch.
spoonerize "magic trackpad"
http://www.fastcompany.com/online/06/writestuff.ht ml..is [fastcompany.com] this the same team from Lockheed that coded the "Right" stuff ??
I read it quickly and thought it said, "The shuttle computers were never envisioned to fly through a year-end hangover".
I couldn't figure out for the life of me why they'd let mission critical crew drink bubbly in space... or why the computer would give a damn.
You can't win, Darth. If you mod me down, I shall become more powerful than you could possibly imagine.
Well it sounds like they should have used a different computer dating service for that New Year's date. Maybe LavaLamp. Or eHarmony. That one costs serious money, but I hear the screening's a lot better. I mean sure you can get a date on Craigslist for free, but you get what you pay for, basically.
The phrase "good enough for government work" comes to mind. This kind of crap really does (and should) irk every single tax-paying American. Shoddy design work like this should shame the contractor that billed the gov't for it.
I know it will not make the astronauts say much publicly about how they really feel to fly on the shuttle when this kind of news comes out, but I'm sure it makes the spouses and families of the astronauts have many sleepless nights.
Kind of makes me imagine what the space program would be if we combined common sense with the intelligence from those rocket scientists. Hmmmmm.
Artifical Intelligience is no match for natural stupidity.
Granted, the work they do is very impressive and the process is very exacting. But come on...they haven't been able to fix a simple year rollover event in 30 years?!?
From the Fast Company article:
I would say that requiring a reboot every year on December 31 is a pretty huge error. In this case, it is forcing NASA to launch earlier than they otherwise would wish. And this isn't the first time this type of problem has caused problems. The New Scientist has a similar article that goes into more detail:
That's the kind of lame bug we used to joke about the Soviet Union equipment designing.
--
make install -not war
So, they made the software so it does not kill anyone. Who needs fancy features like precise yearly timing?
Seriously, though, it's worked fine. The software has not killed anyone. They can either fix it and modify a very critical system on an enormously complex vehicle, or they can move the launch date around a few days, which they seem to do for every launch anyway. B is probably safer and more predictable.
The problem seems obvious. If the shuttle computer is allowed to think it is the 366th day of the year, it will obviously turn evil and try to destroy the earth using the vast orbiting nuclear arsenal, while we sit helpless on the surface. We can't allow this to happen.
After all NASA has done to put satellites into the drink, endanger astronauts, and soak money like LA uses water, you'd think there'd be no embarrassing bugs like this one. Someone needs to be looking for a job flipping burgers.
I can buy no excuse for something as inane as this. No one takes responsibility any more. There's a project manager that needs to fall on his sword. Or get pushed.
---- Teach Peace. It's Cheaper Than War.
The end-of-year rollover depends on the leap year and leap second (if any), and has traditionally been a source of problems.
Mea navis aericumbens anguillis abundat
Could it simply be that the date is a hard concept? You've got months with uneven number of days in them, including one month that can have an extra day added to it based on a somewhat complex concept (every 4 years, except if it's divisible by 100, UNLESS that year also happens to be divisible by 400). Calculating how many days there are between now and some future date, without using magic numbers? Heck, even software in the 90's couldn't get it right that there was a Feb 29, 2000.
Every date math equation I've seen has all sorts of wierd magic numbers in them where it isn't clear how those numbers were obtained. This may work just fine in day to day computations, but oddball bugs in date calculations can lead to some very wierd errors. Look at the C library sometime for the date functions. It's quite impressive.
Perhaps when the shuttles were designed, the inability to schedule across the new year was acceptable to avoid introducing odd bugs in the program to keep the software provably correct. Ground systems, which can be repaired in the middle of a mission easily, can be a little less bug-free, since a miscalculation won't cause the Earth to suddenly veer off course.
I think it would take rocket science to figure out the notion of year, say for example, on moon or mars - so I guess there is reason for 1st Jan being considered as the 366th day.
...and I'm surprised that so many of the techie gurus around here are buying it.
Ahem.
You must be new around here.
Ba-da-bonk.
I work with military navigation software, and that is sorta remotely applicable to this. Here's my thoughts:
You people with your "WTF NASA SUXORS THIS IS EASY FIX!!!11!!1!one!!" need to stop and think for a second. This is a space application that carries HUMAN BEINGS! Think about how hard it will be to get this "easy fix" qualified, proven, documented, etc. Its not an easy task. A formal qualification test on the systems I work on (military land- and air-, but not space-based navigation software) can take months, and require all sorts of tests and documentation. Anything that isn't formally tested (i.e. run in a van, on a plane, etc) must be shown to not fail in any way; all exceptions handled, no bad data can cause an undesireable state, etc. I would hate to see the type of scrutiny that the Shuttle software goes through (although I could probably call somebody in our Space division across the street and find out).
Second, I don't know exact specifics, but based on the information provided, I think this "glitch" will have to do with the data/time difference between ground stations and the Shuttle computers. Things like message time stamping between the Earth and the Shuttle, etc, will be wrong, and things could be garbled or just dropped all together. The navigation systems themselves should not be terribly impacted since the date will just roll to the next day. Inertial instrument samples will continue to flow in and be correctly time stamped, be it the 366th or 400th or 500th day.
There are only 10 kinds of people in this world... those who understand binary and those who don't
So, NASA is partying like it's 1999 huh?
I have a hard time finding (if date > 365 then date = date - 365) that difficult of a concept.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
CMMI Level 5 Waterfall at its finest. Every jot and tittle accounted for, except for the things that were missed.
Why does the onboard computer need to know the date? To send greeting cards on the astronauts' birthdays? Does a date even make sense when you orbit the Earth several times each day?
A D365 bug?
now we need to go OSS in diesel cars
I caused quite an uproar with a post to The DailyWTF where I proposed that dates like “September 31, 2005” could be considered the same as “October 1, 2005”. The responses are varied and some of them insightful. Worth a read if this stuff interests you.
Why bother.
This time. It's personal.
Support Liberty, Support Ron Paul
Who's going to tell the 7 astronauts strapping themselves to 7 tons of jet fuel waiting for software to "light the match" that Billy Joe jumped into the code real quick to fix the end of year date problem that's been buggin' us since the 70's? Seriously, those of you who think this is an easy fix and a "couple lines of code" are extremely mistaken.
It helps to know where other gravity wells are centered.
Yes, I am a Rocket Scientist (though, granted, my area is avionics, not GNC).
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
What prevents them from just saying it's Day 1? If the computers already save the number as an integer, surely they don't need to know the exact date. So just lie to the computer. Why not?
Was Julian Day not around when the space shuttles were built? Basically, its just a day counter from a fixed point in time. Fractional representations handle hours, minutes, seconds, etc. Modified Julian Day subtracts out a fixed quantity, which allows for smaller storage if you're only dealing with modern dates.
Hell, most ephemeris calculations require you input to be JD/MJD already. This whole year roll over mess would have been averted.
...which is more than many software development processes would reveal. Chances are that this known restriction is on a check-list which every shuttle mission has to be checked against, and the list would exist precisely because the software development and verification process is so solid and conservative.
Opinions vary, but I don't think I'd ever recommend working to the same standards, unless the customer actually had good reason to require it. (NASA does.) Even aside from your own code, doing it properly would require an extensive understanding of any and every third party library and system the code interacts with, which could add orders of magnitude to the development time and cost, even if it's open source and open hardware. I don't like hacks and yucky untested code any more than most people, but at some point it can just make sense to avoid extensive and pedantic formal development processes in favour of just getting it to work.
A lot of development processes (perhaps most) wouldn't have stopped the shuttle launching, even if this were reported as a bug. Chances are that it'd be forgotten about (if not fixed straight away), and someone would stumble on it again accidentally. Many bugs aren't even reported until someone's stumbled on them at least once. This is fine in most situations. Once it becomes a problem again, you can go and look it up, quickly find out everything that's known about it from before, apply any known workarounds, and spend time to fix it if necessary. The point, though, is that many systems wouldn't be sure to keep you informed about the restriction in a way that actively prevents someone stumbling on it later.
I still agree that it seems a little strange that this problem wasn't fixed ages ago. Realistically, though, the Shuttle was never expected to fly this long. It sounds a lot like a compromise that was made in the earlier days when computers were more limited, probably even moreso for the restricted range of systems that are certified to work under such conditions. Any update is likely to be very expensive and time consuming, simply because the software development and verification process is so solid and reliable.
From the article you quoted, it sounds more like they dropped a spacewalk (for Hubble maintenance, probably not safety-critical) so they could return sooner and avoid encountering the bug. To me it sounds like they did what they should have done, with safety as a priority.
Launching spacecraft is an industry in which the stakeholders usually prepare for possible or likely delays. NASA has to delay launches all the time for all sorts of reasons. I'm not sure why a possible software problem would be treated any differently. If the problem is with the managers dangerously forcing early launches, NASA should really be fixing their managers as a priority over fixing a known bug with a known workaround. Weighing it out, it's probably a lot cheaper, easier and safer to simply delay the occasional launch for a few more days, especially given that the Shuttle's remaining days are limited. Why risk the safety of future launches by making changes that will soon become obsolete?
Anyway, those are just my own thoughts. I don't work in software development where the process is quite so strict, but I'm sure they know what they're doing when they don't fix something like this.
The shuttle software development process is actually famous. A textbook case of good software engineering. At least a decade ago, it spent the most per line of code of any government software contract. The development documents take up several shelfs of large binders. And it was noted for being almost entirely bug free. I doubt its a hodgepodge of different languages, though it might be I suppose. ...its amazes me that with all their planning they didn't think about a year change.
*Scientists Tensely Updating Date Software
**Happy On Reaching New Years
In other news: a computer glitch may elect a President.
A very inexperienced coworker of mine created a similar bug in a SQL Server 2000 application. He decided to use an integer to represent the month and an integer to represent the date. He also named tables with an identifier followed by the 3 letter month. A year after the system was in place, all numbers for Feb were suddenly twice as large as usual! Customers were getting billed twice as much. He had managed to create a Y2K bug that happens every year! There should be some kind of award for that. I posted as anonymous for obvious reasons. :)
What does the date have to do with controlling a "large flying contraptions that are designed to safely get 7 people 300 miles up, keep them there for a week (or two) and get them home"? Flight control, navigation, etc are all done in real time, not on a calendar basis. The only thing I can think of is maintaining a log, in which case the date doesn't really matter. The log file can be cleaned up on the ground afterwards.
When our name is on the back of your car, we're behind you all the way!
omg everyone go out and buy water, jerky, and biohazard suits cuz the world is gonna end when the shuttle flies around madly, crashing into building after building and bringing down the whole infrastructure of the world! This is gonna be Y2k007. That's right, Y2k but with 007 tacked on because that makes everything more intense!
Is it just me or is it not going to upgrade to Vista in here?
I originally found it hard to believe the shuttle hasn't been in orbit over new year's before.
e _missions
http://en.wikipedia.org/wiki/List_of_space_shuttl
The closest I could find was STS-103, the HST servicing mission in '99. Launched December 19th and lasted 7d 23h.
(except for the road crews in some places)
please upgrade or replace the bloody shuttles!
http://www.fastcompany.com/magazine/06/writestuff. html is a really good read on how the shuttle software is actually made. It's the most reliable software in the world with the most exacting design process.
How many other groups can deliver a half million lines of code with only 1 error (and no, not this issue. And as far as this being an error or bug, it really isn't. It's a know design restriction on a system that just works. Do you really want to go redesign a large chunk and possibly introduce life threatening bugs, or work within the known design window for the system.
We probably won't ever know the real reason why they are thinking of postponing this launch; unbelievable how many /.s accepted this piece of crap.
Really, am I the *only one* who remembers previous year's missions that have overlapped the holidays? What; you haven't heard that they have to 'dry dock the ISS every year? Heh.
Yhbt; hand.
They're calling this one 'Y2Day?'
from the 1999-called-they-want-their-date-bugs-back dept Speaking on behalf of 1999, the whole blank called, they want their blank back joke ATE MY BALLS.
Why is the date critical to the operation of the shuttle? Do the astronauts forget what day they are supposed to land or something? If the day flips to 366 - so what? Now, do not get me wrong. I'm sure there is a *good* reason why a date rollover to a non-existing day would cause a problem, but I can't seem to find out what that problem would be. Does the computer lock up? Does it loose it's ability to navigate? Does the life support system shut off? Do they even know? Maybe it is a case of 'we don't know what would happen, so rather than find out let's just not do it.'
Also, from what I understand, there are 4 computers aboard the craft. So, why not reboot one computer at a time to update the date until all are updated?
I want the cowboy astronauts back. The boys that few Apollo 13 and duct-taped their space craft together and rode it home. I think they are more scientist than hot-shot now-a-days. Kind of a shame, it was the ego driven pilot that sorta made it all romantic in a way, now we send accountants in to space that get freaked out over a little date change procedure.
"Yeah, you're missing something. Such as the fact that the Shuttle was designed a quarter century ago, "
I can't believe this was moderated as +5, Insightful.
The shuttle was designed WELL OVER a quarter century ago. A quarter century ago, they had done some much design and testing, they were able to have the maiden flight (STS-1, Columbia launched in April 1981). Shuttle design and specification requirements analysis began in October of 1968. VMS, CP/M, PC-DOS, and 4BSD did not exist when the Shuttle was designed.
You must be thinking of Multics, which was the closest thing to a modern operating system that existed in the 1960s.
Seriously, you have no idea how old the Shuttle design is. I have no idea why they keep using it after the great work done 20 years ago by Richard Feynman who showed that NASA's shuttle design was about 1/100 flights unreliable. For the record, we've sent up 200 missions and had 2 shuttles blown up. The Space Shuttle is a piece of garbage, and NASA has wasted billions exploring low Earth orbit, rather than do something more useful.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
In my personal opinion, if the following two are true:
1) implementing what is required to alleviate the deficiencies implied here introduces complexities or logic that may jeopardise a mission; and
2) not implementing 1 will not pose an unacceptable limitation on the purpose of the system.
Then this was certainly the right choice.
If I were a crew member of a shuttle, I'd certainly opt for the limitation and over introducing another factor that may compromise my life.
I have not had opportunity to consider it, but space travel is a very different domain to what we live in, and to automatically think that earth time is even a suitable time reference for a spacecraft would be somewhat naive. That is not to say that it isn't, but it should a least be considered.
Never happened. True story.
"he problem, according to HAL, 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." I mean, I grew up with this guy, this sounds so much like him.
With great power comes great electricity bills.
Imagine you are a member of the shuttle design team and you can make a choice (for the next 20 years) to either know for sure that you're with the kids at home on X-mas and New Year .... or you can suggest a software feature that could result in your New Year's Eve being spoiled down the road because you have to be for days in a dumb control room. Hey, what would you do??
And I still remember, when I was a kid, that we had that Apollo flight during X-mas. I think it was the one that would for the first time go behind the moon. Someone in the control room that year made it into an important enough person on the Shuttle program so that this WOULD NEVER HAPPEN AGAIN. :-)
Browsers shouldn't have a back button!! It's all about going forward...
I would say that requiring a reboot every year on December 31 is a pretty huge error.
I wouldn't. When you're designing something like Shuttle software that has to work absolutely flawlessly 100% of the time, you don't put in any frills. And on something that is only ever in space for 10-15 consecutive days at most, year-end handling is most certainly a frill. (If you are a professional software developer, it ought to be obvious just how many things could break by adding a feature like that. If the original design calls for a monotonically increasing day number, for example, there's very likely to be some code that relies on that, so you have to go through the entire system, checking everything that even touches the day counter to ensure it can handle a reset from 365 to 1--and then check everything that uses those routines, and so on and so on.)
I suspect this is routine to NASA, and the reporter just blew it out of proportion. After all, Windows can handle end-of-year rollover, so if the Shuttle can't then it's broken, right?
- In before UNIX time, RMS, pirate beards, etc (Just kidding)
space is pretty cool.
Who said to use a YDM HMS time format?
I thought most scientists used Julian date system, thats similar to a stardate, ie DAY.SEC from eons ago.
Infact, dealing with YDM is a pain, and more complex and error prone than JD.
And how many systems do need to know the date any way? Is it only the CRT displays? What timezone
is the shuttle in, i assume they use Florida time.
Liberty freedom are no1, not dicks in suits.
Latest of three articles was last week pre-empting this news. Wire services are never first ;)
http://www.nasaspaceflight.com/content/?cid=4887
. . . Imperial time and the ground-based systems use Metric time.
CAPE CANAVERAL, Florida (Reuters) - A glitch in a computer dating system may delay the next space shuttle launch because it erroneously matched the flight director with a sumo wrestling transvestite into S&M. Before the flight director could flee from the encounter, he suffered multiple bruises and contusions that placed him in the hospital. Surgeons are unsure when the flight director will recover, and plans are underway to train a replacement.
9/11 Eyewitnesses to Explosive WTC Demolition 1 of 2
TFA carefully does NOT say that anything actually will fail, but that something might fail. Thank you, Fallon: your link (http://www.fastcompany.com/magazine/06/writestuff .html) is a good explanation. (However, the "on-board shuttle group" is actually called the "on-board systems group").
It's like this: A clock rollover (such as at midnight or the last day of the month or year) always sets something back to zero. That resetting is a risk: Is there something somewhere that doesn't take the rollover into account? It may be an obvious bug, or not so obvious - what if the problem is dynamic? For example, what if system A sends some data and rolls over, and system B rolls over and receives the data? Then it looks like stale data, but isn't. How do you test for dynamic conditions like this?
Dodging this bullet is far, far cheaper than testing for it.
The only time I know of that a shuttle flight software bug affected a flight was uh...STS 2 or 3 or thereabouts. The shuttle often flies an updated load on one or two of its computers before the load is installed on all of them. On this mission, a new load on one GPC dumped (crashed) at T -9 seconds or so, causing everything to shut down automatically. The shuttle launched a day or two later, after the new load was rolled back.
Funny thing was, the same bug had occurred in the training simulators before launch, but was written off as a lack of fidelity of the simulator itself, not a bug in the flight software.
After that, the astronauts really began to appreciate running the real GPCs with the real flight software in the simulators.
PS: Although I work at NASA, this message is my own expression, and not that of NASA or my employer. I am a programmer only, not anyone with any kind of authority or insight except for my experiences here.
Pavlov wouldn't be so famous if he'd used a can opener instead of a bell.
Is it no surprise?! And he we are planning a trip to Mars. What the hell are those poor lab rats of astrtonauts going to do in the middle of space on a trip that takes several months, and January 1st rolls around? Maybe they could pull into that spacecraft garage on the corner of Deimos and Phobos. I did get a chuckle about plugging in the cellphone. I mean, hell, if a lousy machine the size of a pack of cigarettes can do it...
NASA scientiests can't get a simple thing like the date right after 35 years, BUT some scientists there are willing to go on the record saying they know what the weather in 50 years will be like. Yeah, right.
Look, Ada, may be great, maybe not, but I very much doubt the implementation language had anything to do with this design decision.
And, as I have said in a reply elsewhere. If implementing the alluded flaws would introduce unnecessary complexities, that may compromise safety, then it should only be implemented if it is absolutely required.
I believe this is a very minor limitation for the degree of risk mitigated.
Never happened. True story.
Actually, the estimated failure rate for the shuttle program was 1 in 35, though the shuttles themselves may have been designed to withstand 100 launch/landing cycles*. This was a bit of an issue when the 25th mission resulted in a failure (since most of the population does not understand statistics).
And, for the record, there have been 117 launches, according to wiki, which I will take as accurate enough for this discussion (far less than 200).
*yes, IWAAE (I was an aerospace engineer) working for NASA, and was involved with shuttle payloads and structural reliability analyses.
Is it just my observation, or are there way too many stupid people in the world?
How many PhDs are there involved in the Shuttle program? ;)
Loading...
Ever since the Columbia accident, NASA has approached every human flight with extream caution. The article does not say that there is a date roll over issue, it says they don't want to fly with an unknown system responce. This system is not just the launch stack and the orbiter, it is comprised of all the gound support and communications gear. If there is a glitch that crops up while the Shuttle is landing on day 367 and the landing approach hardware is working on day 002, bad things can happen. Why risk the problem? It doesn't cost much to stay on the ground. If they are ready before the 17th, they fly. If they are not ready, they fly a couple of weeks latter.
I am actually surprised that they have a date on the flight computers. If you look at the schedules, everything is based on flight day numbers and T+ times.
It sounds to me like this is a problem with the ground computers... not the shuttle computers. The shuttle computers clearly handle things like any other computer does, going to 366 instead of 1. The ground computers on the other hand... who's the moron who thought up that design?
"You had this look that of an angel, it was such a bad disguise" --Dishwalla
NASA would be more leery of computer dating. I mean, really.
What if I do the same thing, and I do get different results?
Is Evian spelled backwards. :p
Good thing they don't fly across time zones! Oh wait...
As a professional engineer who spends most of his time writing software (Aerospace simulations):
1) You follow the spec you are given. If the spec says don't worry about end-of-year transitions because we won't be flying over the transition, then you don't code it. You follow the spec you are given.
2) I would say that requiring a reboot every year on December 31 is a pretty huge error. The shuttle powers down in between flights. For a long time. This is a non-issue. And again, following the spec is not an error. It may be a design error, but it is not a programming error.
So, what if, oh, say, the CO2 scrubbers need to work differently depending on how many days the mission has been run. So, they keep track of the first day number, and the current day number. The amount of CO2 scrubbing then is varied based on elapsed days.
^^and here's the key -- it's something you don't know about^^
Now, you make your little 5-second fix, and send seven astronauts into space.
New Year's Eve rolls around, and suddenly the mission started on day 360 and it's now day 1. Holy crap, says the scrubber, we have to scrub as though it's a 359-day mission, instead of a lousy 6.
Scrubbers go into overtime, and break. (Or, scrubber math is done in eight bits, and they think the shuttle's still on the ground and not ready to launch for another ~100 days due to integer roll-over. Or any other set of unforseen possibilities.)
Next, astronauts die of CO2 poisoning because the scrubber subsystem has been compromised.
Great fix, mister five-second-coder.
Do daemons dream of electric sleep()?
Some of the Mars rover software couldnt handle four digit dates, having been designed for 90 days. But the rovers were designed to be reprogrammable and have been updated over a dozen times. Rover Spirit turned 1000 Sols October 25 during solar conjunction (Mars behind the Sun). It becomes radio-visible at the end of this week and is expected to still be working, but in winter-slowdown mode.
If I recall, the shuttle computers were originally based on the IBM 360 (or maybe 370) mainframe architecture standard. The 360 series was the first real effort at standardization of components and instruction set so that upgrading your machine does not mean upgrading your software or peripheral equipment. And like the IBM PC after it, this bit IBM on the ass by allowing an open market to emerge where clones (Amdahl Computers, Hitachi) and third party peripheral manufactures to compete against IBM. (This is where the term FUD originates... Amdahl, one of the original 360 architects who left to found a clone manufacturer, created the term FUD to describe aggressive IBM sales tactics to discredit third parties and intimidate customers into staying with IBM.)
I have no idea if the flight computers are still the same or not, but NASA long ago ditched their 360 complex for flight operations. (I think it was in use roughly until the mid 80s? Maybe early 90s?)
"The shuttle computers were never envisioned to fly through a year-end changeover,"
.. In the HAL/S system, the RTE contains a clock measuring elapsed time ("RTE-clock" time). The time is measured in "machine units" (MUs) whose correspondence with physical time is implementation dependent. HAL/S contains several instances of timing expressions which in effect make reference to the RTE-clock"
"Timing Considerations
"The true HAL/S concept of a program at run time is an entity executing over some interval in "real time", directed and controlled by a Real Time Executive (RTE). At the outset, the RTE begins execution of the program"
davecb5620@gmail.com
[insert bad joke of rocket scientists not getting "dates" here]
What you've failed to realize is that the flaw isn't so much that they decided to not
do a rollover, it's that the ground computers do a rollover, and the shuttle computers don't.
AccountKiller
Yeah, whenever someone brings up the CMM, I point out that NASA is CMM level 5 and they managed to smash probes into Mars because of unit conversion issues. This date issue is just another example. NASA does neat stuff, but that is not an indicator of the quality of their develoment process.
Computer Date Glitch May Limit Next Shuttle Launch
"Wait. A computer matched her with him? I don't think so."
Have you read my journal today?
what QA testing is for? Wouldn't you want to have mock hardware to run this through on all those weird changing date situations?
Hundreds of comments and not a single one mentions that NASA is a CMMI Level 5 organization. For those that don't know (and apparently, that's a lot of you), CMMI, aka Capability Maturity Model Integration, is software ENGINEERING methodology for developing processes and technologies around IT systems. It is a very in-depth methodology for developing software and comes about as close to "engineering" as you can get in software development.
Here is a list of participants in this program.
And here is a general overview of what CMMI is.
And just to put it into perspective, when I was last working with CMMI, there were only 3 companies certfied at level 5. Nasa, Motorola, and another one I can't remember. I am sure that has changed but nonetheless, it's a big deal and shows a serious effort to do things in a controlled, measureable, testable, way.
I only bring this up to counter the ridiculous "solutions" that some have proposed on this site.
"I can fix that in 3 lines of code".
Well, great. That might work at YOUR company. But please don't do that at NASA. Despite what many think here, NASA is a top-notch software development house. And I would expect nothing less given what is at stake.
It has to be supported doesn't it?
it's tailored to do what it needs to do, nothing more, nothing less and it does it perfectly.
And if you come up with something it can't do, like fly a mission on December 31st, then by definition it doesn't need to do that.
Yup, perfect!
half a million lines of code, 1 bug.
This isn't a big. If you don't know why, shut your pie hole.
The Kruger Dunning explains most post on
It wouldn't be too much effort IMO
"Nobody ever went broke underestimating the intelligence of the American public." - HL Mencken
Frankly, I'm surprised that the original s/w design didn't ignore dates and use mission time. Count upwards from launch and never roll anything. After all, they're not running a payroll up there.
Have gnu, will travel.
Face it, since JFK died, NASA hasn't been the same.
http://www.thirdrake.com - Best Webcomic of all time.
It's amazing such a fine detail was recognized by the NASA managers. In a typical IT project, details like that are so far down the chain of command and the employee turnover so high, that they just get forgotten or buried.
I think the third one you're thinking of is Dibold?
They did think about it, and plan for it. From the article: "The shuttle computers were never envisioned to fly through a year-end changeover,"
No shuttle has ever been in space over the year end, and this one won't be either. I don't know why the fuss now, with only a dozen or so more flights left.
When our name is on the back of your car, we're behind you all the way!
Given that the shuttle orbits Earth something like sixteen times a day, does the concept of "year-end changeover" actually have any meaning to it? Just which timezone would be used to keep track of the date? If it's the "local" zone, then that "simple fix" had better be able to switch the date backwards and forwards every ninety minutes whenever the ship slides across the International Date Line. But if the relevant time zone is that of Mission Control, no matter where in the world that is, then it sounds as though the whole concept of date or time of day is pretty much irrelevant: surely it's only the number of seconds since takeoff that matters. And if that's the case, then it sounds as though the shuttle's software is designed perfectly: it's the ground-based systems, with their convoluted, irrelevant and incompatible "year-end changeover" functionality that are the problem...
There is a buffer overrun bug in your usenet/rfc822 dates in C page.
:)
May I suggest using a "sizeof(buffer)" construct, rather than "50" as the second argument to strftime? Especially when your buffer is only 30 bytes long as is from alloca() memory. Sizeof is totally portable, right back to K&R-ANSI-draft at least. More portable than strftime!
It is potentially exploitable because you are not checking the locale before calling strftime(). The formatting of strftime() varies based on locale rules and so forth. For example, %a will yield "Mon" in english, but "Lun" in french.
So, actually, by not flipping explicitly into the C locale, and tzset()ting to GMT, your example is incomplete. I'm fairly certain that both 821 and 1123 explicitly call for date headers to be in english.
Boy, I'm a pedantic pain in the ass, aren't I? Just one of those days, I guess, eh?
Do daemons dream of electric sleep()?
"Endless September" technically ended last year, as these articles state:
2 100-1032_3-5550036.html
http://news.com.com/AOL+shutting+down+newsgroups/
http://www.metafilter.com/mefi/38978
However, AOL users discovered the "Google Groups" interface to Usenet newsgroups, and there are surely more clueless AOL users (sorry for the redundancy) posting to Usenet through Google than there were posting "directly" to Usenet through AOL's interface in 1993. Thus, your date of "Monday, September 4815, 1993" is more-or-less correct.
It's fortunate that (AFAIK) no Usenetian has ridden on the Space Shuttle - his or her insistence that the date is always a day in September 1993 would have been too confusing for all others involved.
Tag lost or not installed.
the bug rolls over you!
m10
I haven't failed to realize it, I simply don't have enough information to make a judgment one way or the other. It's equally possible that those computers are used for more than just interfacing with the Shuttle, and those other uses require a rolling-over date counter. Again, this comes down to the criticality issue: it's far more important that the Shuttle systems remain in working order than that those on the ground do, and the designers may have decided that it simply wasn't worth the risk of trying to implement rollover on the Shuttle systems, whereas the ground systems needed rollover for e.g. data logging. Without knowing more about the systems, you can't just go and say "they screwed up"--that would be like blaming a toaster maker because the toaster shorted out when you put it in the bathtub: it's simply not designed for that.
But does it run Linux?
Libertas in infinitum
The NASA Software Engineering Requirements for your review.
hmm, I'm sure someone else must have writtend this and I'm sure I'm missing something.
Why not just change the date on the shuttle to say, July or something? is there any need for them to be sycned to the actual current date?
if (!signature) { throw std::runtime_error("No sig!"); }