The STS is currently on the pad and set to launch Thursday to do some work on the International Space Station.
If they can’t launch by December 17th, they will postpone the mission until after the new year.
Why?
Because the computers on the most sophisticated machine ever made 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.
http://www.mercurynews.com/mld/mercu...h/16149688.htm
Can someone explain to me why this is?
Two things:
(1) You want a software engineer, not a rocket scientist, for this problem. My guess is that they have never tested the post-2000 functioning of the year-incrementing function, and don’t want to find out on orbit. However, I’m just a rocket scientist, so I’ll step aside for the software and computer engineering experts.
(2) STS is not the most sophisticated machine ever made, and hasn’t been for a while; it’s 1980s hardware built on 1960s spaceflight paradigms. Thanks in part to STS, and in part to the march of time, we’ve learned a lot about materials science, computer engineering, and systems engineering. Just off the top of my head, I’d say that the Boeing 777, the F-22 fighter, or the B-2 bomber is easily a match for the STS in terms of materials science, propulsion technology, aerodynamics, and control systems sophistication.
There are a number of reasons.
The point at which the year ends is variable. It’s affected by the leap year and leap seconds. This makes computing and measuring time intervals across the year’s end complicated and error prone.
Navigation data, such as orbital elements, is often only valid for the year of its epoch. New elements have to be generated for the new year and loaded into the computers.
The ranges (CCAFS, KSC, VAFB) are essentially shut down in late December for the holidays. Many people take vacation at that time.
Support for correctly handling the end-of-year rollover may have never been a software requirement. If it isn’t a requirement, it doesn’t get written and tested.
Many NASA/DOD clocks and timing systems do not track the year, they keep track of the day-of-year (1…366) and the time-of-day (milliseconds of day). Many may have to be manually adjusted when the new year begins.
It’s a low probability event, so management may have decided that it was safer, simpler, and cheaper to not fly a mission that crosses the end-of-year boundary. KISS.
So why doesn’t the ISS have this problem?
If you live in Seabrook, I’d bet you don’t have a long commute…
Because the ISS was designed from the get-go to be up there for a long time. The longest space shuttle mission was only 17 days.
I’m not a rocket scientist, but I am an engineer who works with rockets, so I’ll take a SWAG at it. Even after going through all the registration hoohaw required by the Mecury News I couldn’t see the news article, but I get the gist of the issue from the context. From SpaceflightNow.com:When the shuttle’s flight control software was developed in the 1970s, NASA managers did not envision the possibility of flying missions during the transition from one year to the next. Internal clocks, instead of rolling over to Jan. 1, 2007, would simply keep counting up, putting them at odds with navigation systems on the ground.
“It’s an interesting problem because if you remember a few years ago, we went through the Y2K change and there was a lot of concern about what computers would do,” Hale told reporters earlier this week. “The interesting thing about the shuttle computers and the ground computers that support the shuttle is they were never envisioned to fly through a year-end change over. So the shuttle computers actually keep counting and they believe it’s day 366 instead of day 1 of the year.”
"That sounds rather trivial, but the fact of the matter is to keep the navigation in synch with the rest of the world, which has changed from day 365 to day 1, you’ve got to make that change appropriately and it was never designed in."I’m not a software guy (at least, not anymore) but my understanding of embedded avionic software systems for GN&C is that they’re very convoluted, often extensively and yet poorly documented, and that engineers are loathe to alter anything without the opportunity for extensive testing. The original computers on the Shuttle were IBM AP-101 computers using ferrite core member with the avionics code written in the proprietary real time HAL/S language. In the early Nineties the remaining fleet was retrofitted with AP-101S using solid state memory but able to run the same instruction set for the original code. In essence, the code it as it was written in the mid-Seventies with minor corrections and updates.
I’m personally rather suprised that the code would use a timing system based upon the beginning of the year, rather than an arbitrary sychonized value. This seems like incredibly poor planning to me. I wonder if there isn’t more to this explanation than offered here.
Stranger