Some of Ron's Code?
Ken Tilton
past December 17 since flight controllers want Discovery on the ground
before the new year. 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."
Speechlessly, kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Frank Buss
> 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.
This will be a problem, if they want to fly to Mars before the invention of
the Warp drive.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Jim
> "Cape Canavaeral (AP) -- The space agency likely won't attempt to launch
> past December 17 since flight controllers want Discovery on the ground
> before the new year. 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."
1970's technology. As a student intern I did a little bit of work on
the Hubble and the answer to some of these kinds of reports was that
the systems simply did not have the capability. (I don't know about
this particular one, though.)
Jim
Espen Vestre
> The only point to remember is that these computers physically are
> 1970's technology.
And sometimes it's more impressing than today's technology
- e.g. Voyager I and II are still alive:
http://voyager.jpl.nasa.gov/
--
(espen)
Didier Verna
> This will be a problem, if they want to fly to Mars before the invention of
> the Warp drive.
That's assuming they /have/ to fly. Once the intercession capabilities
of the universe will be discovered, it will be possible to fold up space-time
on itself. Then, instead of having to reach Mars, you will be able to simply
have Mars reach you.
I think that Lisp will make this very easy...
--
Looking for a Christmas present idea? http://cdbaby.com/cd/didierverna
Didier Verna EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicętre, France Fax.+33 (1) 53 14 59 22
Ken Tilton
Frank Buss wrote:
> Ken Tilton wrote:
>
>
>>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.
>
>
> This will be a problem, if they want to fly to Mars before the invention of
> the Warp drive.
>
We gotta get them onto Lisp for that project. And Cells.
Ken Tilton
What capability? Computers do not do julian date calculations,
applications do. I mean, can the shuttle cross month boundaries?
February 29th?
Frank Buss
> What capability? Computers do not do julian date calculations,
> applications do. I mean, can the shuttle cross month boundaries?
> February 29th?
Usually RTC chips counts in julian dates, see e.g.
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3029
If they use this chip in future developments, they will have a problem in
2100 for February 29th :-)
George Neuner
wrote:
>Ken Tilton wrote:
>
>> 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.
>
>This will be a problem, if they want to fly to Mars before the invention of
>the Warp drive.
Earth and Mars are both well inside the sun's warp effect boundary.
There is a small, but not insignificant, chance that warping from one
to the other will cause the sun to explode.
The trip is only about 20 minutes at impulse ... are you really in
that much of a hurry?
George
--
for email reply remove "/" from address
Ken Tilton
Frank Buss wrote:
> Ken Tilton wrote:
>
>
>>What capability? Computers do not do julian date calculations,
>>applications do. I mean, can the shuttle cross month boundaries?
>>February 29th?
>
>
> Usually RTC chips counts in julian dates, see e.g.
> http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3029
Someone built a dedicated chip to do julian dates, but did not build it
to cross year boundaries? The y2k bug writ large?
Jim
Ken Tilton wrote:
> What capability? Computers do not do julian date calculations,
> applications do.
number of routines to fit in there, and there may well simply not have
been enough room for the one that we are talking about. We are talking
K's here, not M's or G's.
On the other hand, I don't *know* that; it is all speculation on my
part based on a prior experience.
Jim
Jim
Jim wrote:
> We are talking
> K's here, not M's or G's.
computers have 424K, with no hard disk (and process 400K instructions
per sec).
http://en.wikipedia.org/wiki/Space_Shuttle
And anyone who asks "Why don't they just upgrade?" has never worked for
a contractor for the military or NASA. :-)
Jim
Ken Tilton
Jim wrote:
> Ken Tilton wrote:
>
>>What capability? Computers do not do julian date calculations,
>>applications do.
>
> The capability to hold that much software, of course. They have a
> number of routines to fit in there, and there may well simply not have
> been enough room for the one that we are talking about. We are talking
> K's here, not M's or G's.
Oh, probably not. Lisp Machines had a lot of RAM because the DOD was
paying the tab. I think the shuttle boxes have some RAM. besides....
...they fly across month boundaries (I am guessing, but I would die
laughing if it turns out they actually avoid that, too) and apparently
are doing /some/ calculations that will break by crossing a year
boundary, so it seems like they know about going from 28, 29, 30, and 31
to 1 so a year rollover (if (month==12)...) -- what? another three lines
of code?
I think you guys are being to easy on Ron. :)
Wouldn't be sickening to be the person who looks down in the newspaper
and discovers NASA cannot launch an entire fricking mission because you
came up short on date calculations? Come on, I coded this crap in my
first month as a programmer in tall buildings.
OTOH <gasp> at least they identified the constraint. Can you imagine
losing another shuttle over that? :(
Ron Garret
Ken Tilton <kent...@gmail.com> wrote:
> I think you guys are being to easy on Ron. :)
I was really hoping to stay out of this, but since Kenny just can't seem
to resist taking these cheap shots I feel the need to set the record
straight.
The original shuttle computers had about 500k bytes of RAM and ran at a
clock rate of about half a megahertz. In 1990 they were upgraded to
machines with about a megabyte of RAM and a 1.2 MHz clock. In other
words, these machines have about 1000 times less RAM and run about 1000
times slower than current state-of-the-art PCs. On top of that, they
have no disks, and hence no off-line storage. The software (which is
written in HAL/S) is loaded from tape.
N.B.: I have no particular insight into the design of the shuttle's
computers. I got all that information from Wikipedia. I mention this
because I can't help but wonder what Kenny was hoping to achieve by
chucking stones at some pretty damn capable engineers when it is clear
that he hasn't done even the most basic homework.
But I digress.
Now you may be thinking to yourself that half a meg and half a megahertz
is plenty of computing power to keep proper track of the date. And
indeed it is. What Kenny overlooks is the admittedly subtle point that
the shuttle software has a few other things that it needs to concern
itself with, like, oh I dunno, actually flying the shuttle. On top of
that, the whole system, software and all, has to be designed in such a
way that when (not if) things fail the shuttle keeps flying. Designing
a system that is actually capable of flying the shuttle in 0.5MB and
0.5MHz is not such an easy thing to do, and designing it so that it is
robust in the face of failures is even harder. But they (not me -- I
was five when they started working on this stuff) did it. And it does
work. And if one of the design tradeoffs they decided to make was to
assume that the astronauts would generally be taking New Years Eve off,
I am not going to go second-guessing them, because I've never built
anything anywhere near as complicated or reliable as the space shuttle
control software. And if Kenny has he's done an admirable job of
keeping it secret.
To be sure there are many things one can legitimately criticize about
NASA. But this isn't one of them.
rg
Barry Margolin
"Jim" <jhef...@smcvt.edu> wrote:
How does old hardware make it hard to write correct software?
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Fred Gilham
"Jim" <jhef...@smcvt.edu> writes:
I thought the reason they didn't upgrade was that after the system
... or shuttle ... crashed because of a bug in the upgrade, the next
time there was a launch the surviving astronauts would strap the
programmers to the sides of the shuttle's fuel tank along side the
booster rockets.
But I may be mistaken.
--
Fred Gilham gil...@csl.sri.com
Do you know how it feels to be evil? It feels *normal*. A
conscience is so easily seared. -- "Nick"
Pascal Bourguignon
> "Jim" <jhef...@smcvt.edu> writes:
>
>> Jim wrote:
>>> We are talking
>>> K's here, not M's or G's.
>> Sorry to reply to my own post. Wikipedia says that the shuttle
>> computers have 424K, with no hard disk (and process 400K instructions
>> per sec).
>> http://en.wikipedia.org/wiki/Space_Shuttle
>>
>> And anyone who asks "Why don't they just upgrade?" has never worked for
>> a contractor for the military or NASA. :-)
>
> I thought the reason they didn't upgrade was that after the system
> ... or shuttle ... crashed because of a bug in the upgrade, the next
> time there was a launch the surviving astronauts would strap the
> programmers to the sides of the shuttle's fuel tank along side the
> booster rockets.
>
> But I may be mistaken.
Well, no need to be so drastic. They could just reserve a seat for
the programmer(s) in every flight. ;-) ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
Ron Garret
Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <1165416640.1...@j72g2000cwa.googlegroups.com>,
> "Jim" <jhef...@smcvt.edu> wrote:
>
> > Ken Tilton wrote:
> > > "Cape Canavaeral (AP) -- The space agency likely won't attempt to launch
> > > past December 17 since flight controllers want Discovery on the ground
> > > before the new year. 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."
> > The only point to remember is that these computers physically are
> > 1970's technology. As a student intern I did a little bit of work on
> > the Hubble and the answer to some of these kinds of reports was that
> > the systems simply did not have the capability. (I don't know about
> > this particular one, though.)
>
> How does old hardware make it hard to write correct software?
The resource constraints of older hardware (and particularly of older
space-qualified hardware) often requires engineering tradeoffs to be
made in order to shoehorn all the required functionality into the
available memory and processor cycles. Sometimes optimizations are made
that trade correctness in one area for capability in another.
rg
Andrew Reilly
Or put another way: correctness is a function of the spec, and the spec
probably says to behave that way.
Like most embedded systems (and why the Y2K was not as large a problem as
it was prophesied to be): I doubt that there is any strong need for the
space shuttle to compute *anything* in calendar dates. Differential
milliseconds or the like are usually perfectly fine, and largely immune to
this sort of nonsense. However some sort of year-day counter obviously
crept into the system, and something else that *knew* that that couldn't
possibly have a value larger than 365...
Not all specifications are "correct"...
Cheers,
--
Andrew
Ken Tilton
You clown are making a pretty convincing case for that when you suggest
that handling year rollover would tax RAM, clock speed, NASA budgets,
and make it necessary to leave off the landing gear.
<sigh>
C'mon, kiddies, it's just a bug.
Ken Tilton
From a longer story: http://www.fcw.com/article96776-11-09-06-Web
"The shuttle software code was designed 30 years ago..."
Oh, gosh, thirty years ago, the Geico caveman was programming for NASA
back then, sure, no wonder, understood.
"... to operate periodically, not for years at a time..."
This next flight will last years? Nice use of language to obfuscate, tho.
"... so the computer does not recognize the end of a calendar year,..."
Right, I was only told it would be up for two weeks, not years, how
could the date ever go from one year to the next?!
"... NASA spokesman Kyle Herring said."
Well, it is better than being Bush's spokesman.
Anyway, looks like they will not scrub, they will just spend 4-6 hours
on New Years's Eve re-installing Linux from scratch or something, wasn't
clear.
:)
Bruce O'Neel
<snip>
>
> ...they fly across month boundaries (I am guessing, but I would die
> laughing if it turns out they actually avoid that, too) and apparently
> are doing /some/ calculations that will break by crossing a year
> boundary, so it seems like they know about going from 28, 29, 30, and
> 31 to 1 so a year rollover (if (month==12)...) -- what? another three
> lines of code?
A lot of these sorts of calculations in the ESA ground station world
are YYYYDDD, ie, year and day of year. Given you can probably do a
manual reset of the day of year, you probably don't have to keep track
of the year then. Then you have code that someone put in to get
unhappy if you get bigger than 366. If they don't put that code in
than you're good for almost 3 years.
--
The Brave New World of privatized digitally rights managed data sounds
good, but when you combine complex business strategies with today's
incompetent programmers, the result is that customers probably won?t
get what they paid for. In an airplane, in the clouds, this is not
comforting. - Phil Greenspun
Bruce O'Neel - bruce...@obs.unige.ch
http://edoneel.chaosnet.org
Ken Tilton
Bruce O'Neel wrote:
> Ken Tilton <kent...@gmail.com> writes:
>
> <snip>
>
>
>>...they fly across month boundaries (I am guessing, but I would die
>>laughing if it turns out they actually avoid that, too) and apparently
>>are doing /some/ calculations that will break by crossing a year
>>boundary, so it seems like they know about going from 28, 29, 30, and
>>31 to 1 so a year rollover (if (month==12)...) -- what? another three
>>lines of code?
>
>
>
> A lot of these sorts of calculations in the ESA ground station world
> are YYYYDDD, ie, year and day of year.
Yes, with the benefit of a night's sleep I am able to notice:
"On Jan. 1, 2007, the computer will think it is the 366th day of 2006."
So the code days:
++day;
and should read:
if (day == (365 + (mod(year,4)==0))) {
++year;
day = 1;
} else ++day;
Sh*t, they could hardcode the leap leap year.
Frank Buss
> So the code days:
>
> ++day;
>
> and should read:
>
> if (day == (365 + (mod(year,4)==0))) {
> ++year;
> day = 1;
> } else ++day;
Do you think they use C? (BTW: then they would use "%" instead of "mod")
Maybe they are using Forth, then it will fit in a microcontroller, for the
Lisp footprint you'll need a harddisk :-)
Nils M Holm
> Do you think they use C? (BTW: then they would use "%" instead of "mod")
> Maybe they are using Forth, then it will fit in a microcontroller, for the
> Lisp footprint you'll need a harddisk :-)
My copy of the Shuttle Computer FAQ says that the system was
mostly written in HAL/S, a PL/I-like language designed for
developing embedded applications.
--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/
Paolo Amoroso
> N.B.: I have no particular insight into the design of the shuttle's
> computers. I got all that information from Wikipedia. I mention this
Likewise, but here is an interesting article on the Shuttle software:
They Write the Right Stuff
http://www.fastcompany.com/online/06/writestuff.html
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Pascal Bourguignon
> Frank Buss <f...@frank-buss.de> wrote:
>> Do you think they use C? (BTW: then they would use "%" instead of "mod")
>> Maybe they are using Forth, then it will fit in a microcontroller, for the
>> Lisp footprint you'll need a harddisk :-)
>
> My copy of the Shuttle Computer FAQ says that the system was
> mostly written in HAL/S, a PL/I-like language designed for
> developing embedded applications.
Wikipedia says:
One particularly interesting feature of HAL is that it supports a
three-line input format in which three source code lines are used
for each statement, with the first and third lines usable for
superscripts (exponents) and subscripts (indices). This was
designed to be similar to mathematical notation.
Outch!
--
__Pascal Bourguignon__ http://www.informatimago.com/
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
Rob Thorpe
> Ken Tilton wrote:
>
> > So the code days:
> >
> > ++day;
> >
> > and should read:
> >
> > if (day == (365 + (mod(year,4)==0))) {
> > ++year;
> > day = 1;
> > } else ++day;
>
> Do you think they use C? (BTW: then they would use "%" instead of "mod")
> Maybe they are using Forth, then it will fit in a microcontroller, for the
> Lisp footprint you'll need a harddisk :-)
They use a language similar to Fortran called HAL/S. It is similar to
C doing the above would be quite trivial.
Probably to go through the code verification procedures for the change
would take into next year anyway, so they're not going to bother. NASA
are quite paranoid about testing for some applications and will retest
everything for a very small change in the code.
Unfortunately for many other things they are less than paranoid.
Ken Tilton
Frank Buss wrote:
> Ken Tilton wrote:
>
>
>>So the code days:
>>
>> ++day;
>>
>>and should read:
>>
>> if (day == (365 + (mod(year,4)==0))) {
>> ++year;
>> day = 1;
>> } else ++day;
>
>
> Do you think they use C?
Ada?
> (BTW: then they would use "%" instead of "mod")
Sorry, it's been a while. :)
Nils M Holm
> Wikipedia says:
>
> One particularly interesting feature of HAL is that it supports a
> three-line input format in which three source code lines are used
> for each statement, with the first and third lines usable for
> superscripts (exponents) and subscripts (indices). This was
> designed to be similar to mathematical notation.
>
> Outch!
Wow! This is even weirder than RPG.
Ken Tilton
Paolo Amoroso wrote:
> Ron Garret <rNOS...@flownet.com> writes:
>
>
>>N.B.: I have no particular insight into the design of the shuttle's
>>computers. I got all that information from Wikipedia. I mention this
>
>
> Likewise, but here is an interesting article on the Shuttle software:
>
> They Write the Right Stuff
> http://www.fastcompany.com/online/06/writestuff.html
Ooooooh, I be lovin' it. Thx. Still reading, but this jumps out:
"At the on-board shuttle group, about one-third of the process of
writing software happens before anyone writes a line of code. NASA and
the Lockheed Martin group agree in the most minute detail about
everything the new code is supposed to do -- and they commit that
understanding to paper, with the kind of specificity and precision
usually found in blueprints. Nothing in the specs is changed without
agreement and understanding from both sides. And no coder changes a
single line of code without specs carefully outlining the change. Take
the upgrade of the software to permit the shuttle to navigate with
Global Positioning Satellites, a change that involves just 1.5% of the
program, or 6,366 lines of code. The specs for that one change run 2,500
pages, a volume thicker than a phone book. The specs for the current
program fill 30 volumes and run 40,000 pages.
"Our requirements are almost pseudo-code," says William R. Pruett, who
manages the software project for NASA. "They say, you must do exactly
this, do it exactly this way, given this condition and this circumstance."
My additional three lines of code thus would require a one-page spec. :)
This also jumps out:
"December, 1996"
Have the recent lean/mean years taken their toll?
Ken Tilton
Ken Tilton wrote:
> This also jumps out:
>
> "December, 1996"
>
> Have the recent lean/mean years taken their toll?
Nope:
"Ted Keller offers an example of the payoff of the approach, involving
the shuttles remote manipulator arm. "We delivered software for crew
training," says Keller, "that allows the astronauts to manipulate the
arm, and handle the payload. When the arm got to a certain point, it
simply stopped moving."
The software was confused because of a programming error. As the wrist
of the remote arm approached a complete 360-degree rotation, flawed
calculations caused the software to think the arm had gone past a
complete rotation -- which the software knew was incorrect. The problem
had to do with rounding off the answer to an ordinary math problem, but
it revealed a cascade of other problems."
Wraparound simply eludes them, and always has. :)
Paul Wallich
> "On Jan. 1, 2007, the computer will think it is the 366th day of 2006."
>
> So the code days:
>
> ++day;
>
> and should read:
>
> if (day == (365 + (mod(year,4)==0))) {
> ++year;
> day = 1;
> } else ++day;
>
> Sh*t, they could hardcode the leap leap year.
You've made a number of assumptions here. Two I can think of:
1) the year is stored in a mutable variable (or is stored at all aboard
the shuttle, since under most conditions there's no need for it, the
ground stations can just fill it in)
2) there's no sanity-checking routine that issues an HCF for whichever
of the redundant processors first detects that the date is not
monotonically increasing.
paul
Ken Tilton
Paul Wallich wrote:
> Ken Tilton wrote:
>
>> "On Jan. 1, 2007, the computer will think it is the 366th day of 2006."
>>
>> So the code days:
>>
>> ++day;
>>
>> and should read:
>>
>> if (day == (365 + (mod(year,4)==0))) {
>> ++year;
>> day = 1;
>> } else ++day;
>>
>> Sh*t, they could hardcode the leap leap year.
>
>
> You've made a number of assumptions here. Two I can think of:
>
> 1) the year is stored in a mutable variable (or is stored at all aboard
> the shuttle, since under most conditions there's no need for it, the
> ground stations can just fill it in)
That makes a lot of sense. If they were handling a year value they would
certainly have thought of it. OK, so we have our first clue as to how
this happened: they do not handle years at all, so their brains did not
get a kick in the pants. (?)
>
> 2) there's no sanity-checking routine that issues an HCF for whichever
> of the redundant processors first detects that the date is not
> monotonically increasing.
Well, I guess they change dayofyear at different times and survive that.
Anyway, I like the no-year thing and...
My later post about the robotic arm software failing in flight because
they did not handle the boundary condition of 360 degrees very well says
it all (along with the effusive article Paolo found). Live by the
process, die by the process.
The programmers' brains are turned off. Thought is assumed to be
upstream. Unfortunately, there is nothing like making an algorithm
concrete to trigger concerns about boundary conditions. Unfortunately,
the people writing the concrete have their brains turned off.
With shuttle flights being -- what? two weeks? -- no test started with a
launch date before Dec 15th would pick up the failed imaginations of the
people upstream.
The funny thing is that it seems they have known about this for a while
without fixing it.
Rob Thorpe
> Nils M Holm <before-2...@online.de> writes:
>
> > Frank Buss <f...@frank-buss.de> wrote:
> >> Do you think they use C? (BTW: then they would use "%" instead of "mod")
> >> Maybe they are using Forth, then it will fit in a microcontroller, for the
> >> Lisp footprint you'll need a harddisk :-)
> >
> > My copy of the Shuttle Computer FAQ says that the system was
> > mostly written in HAL/S, a PL/I-like language designed for
> > developing embedded applications.
>
> Wikipedia says:
>
> One particularly interesting feature of HAL is that it supports a
> three-line input format in which three source code lines are used
> for each statement, with the first and third lines usable for
> superscripts (exponents) and subscripts (indices). This was
> designed to be similar to mathematical notation.
>
> Outch!
See the bottom of this paper for a sample:-
http://history.nasa.gov/computers/Appendix-II.html
It's not incredibly weird, but it's quite weird.
Pascal Bourguignon
What's surprizing is that NASA took the _risk_ of such an innovation in
a programming language. It's not obvious at all that it doesn't lead to
more errors than the "normal" notation.
On the other hand since it has both a 1D notation and this 2D
notation, perhaps programmers use only 1D notation for editing, and
this 2D notation is only used for printed listing (even if the parser
_can_ parse it).
By the way in the HAL/S pdf I've browsed, I notice these two kinds of
examples, my guess is that one is wrong:
E 2
M a = x ;
E 2
M a = x;
--
__Pascal Bourguignon__ http://www.informatimago.com/
"I have challenged the entire quality assurance team to a Bat-Leth
contest. They will not concern us again."
Ari Johnson
> Bruce O'Neel wrote:
> "On Jan. 1, 2007, the computer will think it is the 366th day of 2006."
>
> So the code days:
>
> ++day;
>
> and should read:
>
> if (day == (365 + (mod(year,4)==0))) {
> ++year;
> day = 1;
> } else ++day;
No, it shouldn't. Notwithstanding that (mod(year,4)==0) could be any
non-zero value in most languages where the above is valid syntax,
while the above algorithm will work in all years from 1901 through
2099, it is not correct in general. Leap years occur every 4 years,
except not every 100 years, except that they do occur every 400 years.
(While most people are completely unaware of this and thought that the
year 2000 was a regular leap year, it was in fact an exception to the
exception to the exception.)
One sane solution would be to use the Mean Julian Date internally.
This would allow a more direct link between the computer's clock and
calculations of the state of the solar system.
Of course, all of this ignores the likely possibility that the
shuttle's computer's clock is mostly or purely hardware.
Ron Garret
"Rob Thorpe" <rth...@realworldtech.com> wrote:
And a dilly to parse.
rg
Larry Clapp
> Paul Wallich wrote:
>> 2) there's no sanity-checking routine that issues an HCF for
>> whichever of the redundant processors first detects that the date
>> is not monotonically increasing.
>
> Well, I guess they change dayofyear at different times and survive
> that. Anyway, I like the no-year thing and...
>
> My later post about the robotic arm software failing in flight
It didn't fail in flight. It failed in training. And then they found
another bug just like it in the code that pointed the high-gain
antenna. And then they fixed both problems.
So you're criticizing the testing because it found a bug, and you're
criticizing the process that led them to look for similar bugs
elsewhere, and find them, and fix them. Do I have that straight?
(decf (credibility kenny-tilton) a-lot)
-- L
Fred Gilham
> With shuttle flights being -- what? two weeks? -- no test started
> with a launch date before Dec 15th would pick up the failed
> imaginations of the people upstream.
I have to admit that I wrote code that had a similar kind of problem.
It would do the wrong thing for about 8 hours at the end of each
month.
This was due to an error in a boundary condition for code that was
adjusting from local time to UTC. I rolled over the day but forgot to
roll over the month, or something. It also would have had a worse
problem at the end of the year.
Fortunately I happened to notice that MySQL records weren't updating
and wondered why. Turned out that Oct. 32 was not something MySQL
would swallow.
Even more fortunately I was able to find a way to delete all my code
and use stuff the implementation already provided. As the saying
goes, "Code deleted is code debugged."
--
Fred Gilham gil...@csl.sri.com
"If I'm going to get paged at 3 in the morning, I'd like it to at
least be my fault, and I'd also like a fighting chance of fixing the
problem." -- Tim Moore, arguing for professional open-source tools
Rob Thorpe
It's probably not that bad if you think about it. You just need to
design the lexer in a slightly different way.
You have the three lines superscript, normal and subscript. When asked
for a token the lexer reads ahead simulataneously in all three. It
then reports the tokens found, the lexer can give semantic information
indicating which line they are on. The only problem is how to handle
it if more than one token begins in the same place. Even that
shouldn't be too hard.
It's probably easier to parse than Fortran since there are no
abbreviations and keywords are reserved words.
Ken Tilton
Larry Clapp wrote:
> On 2006-12-07, Ken Tilton <kent...@gmail.com> wrote:
>
>>Paul Wallich wrote:
>>
>>>2) there's no sanity-checking routine that issues an HCF for
>>>whichever of the redundant processors first detects that the date
>>>is not monotonically increasing.
>>
>>Well, I guess they change dayofyear at different times and survive
>>that. Anyway, I like the no-year thing and...
>>
>>My later post about the robotic arm software failing in flight
>
>
> It didn't fail in flight. It failed in training.
OK. All that registered was "after software validation". And that is
pretty bad since they did (wisely) have an entire separate team of
attack programmers who in friendly/adversarial way attempted to find
bugs, which caused the first team to super-check code before releasing
it to the test group so they could not find bugs.
> And then they found
> another bug just like it in the code that pointed the high-gain
> antenna. And then they fixed both problems.
>
> So you're criticizing the testing because it found a bug,
No, I won't be criticizing until/if I understand how it happened. I may
never.
Try not to lose sight of the theme: how did such a simple thing (the
date thing) make it on board the shuttle and (potentially) ground it
until year-end (tho the article I cited said it would only mean 4-6
hours reprogramming in space when the STS crew should be watching the
Rose Bowl parade. The funny thing about this being that the original
article said that they had a fix but that the extensive retesting
required had not been completed. But I guess the four-six hour thing is
more "forget the flight this far, reboot, start a new flight" so... nah,
tha sounds like it needs even more testing.
> and you're
> criticizing the process that led them to look for similar bugs
> elsewhere, and find them, and fix them. Do I have that straight?
No. "Not in-flight, in-training" just changes where in the process the
fault got caught to somewhere else /still after/ where the huge software
design/code+test/attack-test sequence failed to catch a trivial, classic
boundary condition gaffe.
That they have/had a fine record on software reliability is beyond
dispute, what is interesting is how the process failed. Note that I am
only doing what they do:
"4. Don't just fix the mistakes -- fix whatever permitted the mistake in
the first place.
The process is so pervasive, it gets the blame for any error -- if there
is a flaw in the software, there must be something wrong with the way
its being written, something that can be corrected. Any error not found
at the planning stage has slipped through at least some checks. Why? Is
there something wrong with the inspection process? Does a question need
to be added to a checklist?
Importantly, the group avoids blaming people for errors. The process
assumes blame - and it's the process that is analyzed to discover why
and how an error got through."
To me this is interesting because we have always heard that the cascade
method of system development does not work, and in this case it was
working. Perhaps that was because of the resources available:
"Admittedly they have a lot of advantages over the rest of the software
world. They have a single product: one program that flies one spaceship.
They understand their software intimately, and they get more familiar
with it all the time. The group has one customer, a smart one. And money
is not the critical constraint: the groups $35 million per year budget
is a trivial slice of the NASA pie, but on a dollars-per-line basis, it
makes the group among the nation's most expensive software organizations."
...and good management, and an understanding that, no, this is one place
we have to get the code right the first time.
"The group writes software this good because that's how good it has to
be." ... later... "Bill Pate, who's worked on the space flight software
over the last 22 years, says the group understands the stakes: "If the
software isn't perfect, some of the people we go to meetings with might
die.""
At any rate, how did the process fail? My hypothesis stands: programmers
are too robotically following their specs, and I will soften that to
note that they have no choice. They do not have any big picture. Perhaps
they were not even involved in writing the specs.
"NASA and the Lockheed Martin group agree in the most minute detail
about everything the new code is supposed to do -- and they commit that
understanding to paper, with the kind of specificity and precision
usually found in blueprints."
Their brains have to fall asleep and follow the spec as dumbly as
computers obey our code, or at least there exists unusual pressure in
that direction-- I am sure many things do get picked up by programmers
and kicked back to the design team.
I think my hypothesis gets a lot of support from the existence of the
separate testing group. They did not find it either. Clearly their
independence did not extend to independence from the spec -- they, too,
over-focused on adherence to the spec, because the first thing a tester
does is attack at the edges. QED?
Note that I am /not/ painting an ugly picture, so you apologists can
stand down: with their error rate, the system is working beautifully.
But your knee-jerk defensiveness is exactly not what they need, they
need to (and do, as noted) analyze the process.
Recall that I was just wondering how something like day 366 of 2006
could get on board the shuttle. Now it does not seem so odd.
>
> (decf (credibility kenny-tilton) a-lot)
I have some bad news for you. We stored credibility as an unsigned long.
Given the Cells adoption rate, you should have known my credibility here
is zero...well, it was. Thx!
:)
kenneth
George Neuner
>
>Jim wrote:
>> We are talking
>> K's here, not M's or G's.
>Sorry to reply to my own post. Wikipedia says that the shuttle
>computers have 424K, with no hard disk (and process 400K instructions
>per sec).
> http://en.wikipedia.org/wiki/Space_Shuttle
>
>And anyone who asks "Why don't they just upgrade?" has never worked for
>a contractor for the military or NASA. :-)
>
>Jim
NASA doesn't upgrade because they have a requirement for Mil-spec,
radiation hardened parts. For most components nowadays, if such parts
are available at all, they are special order and are enormously
expensive relative to their consumer versions. Most modern processors
have no radiation hardened versions.
George
--
for email reply remove "/" from address
Ken Tilton
software never crashes. It never needs to be re-booted. This software is
bug-free. It is perfect, as perfect as human beings have achieved."
And that: http://www.palantir.net/2001/tma1/wav/foolprf.wav
Hmmmm....
:)
kt
Robert Uhl
>
> Fortunately I happened to notice that MySQL records weren't updating
> and wondered why. Turned out that Oct. 32 was not something MySQL
> would swallow.
IIRC, MySQL swallows 32 Oct. just fine--it's just that it stores
nonsense in its place. A database which throws an error on invalid data
is so much nicer...
I think that more recent versions of MySQL will actually validate data
now.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Mit den Frauen ist das wie mit den Firewalls: was [...] am meisten
Sicherheit garantiert und am wenigsten Probleme macht, ist immer das,
was zum speziellen Fall am besten passt.
--Urs Traenkner in de.comp.security.firewall
Ken Tilton
Ken Tilton wrote:
> "Cape Canavaeral (AP) -- The space agency likely won't attempt to launch
> past December 17 since flight controllers want Discovery on the ground
> before the new year. 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."
>
> Speechlessly, kt
>
Better article:
http://www.livescience.com/blogs/2006/11/07/shuttle-computers-find-no-end-to-2006/
“The interesting thing about the shuttle computers and the ground
computers that support the shuttle is that they were never envisioned to
fly through a year-end changeover,” says NASA’s shuttle chief Wayne Hale
here at the agency’s Johnson Space Center. “So the shuttle computers
actually keep counting and they believe that it is Day 366 instead of
Day 1 of the New Year.”
While it sounds trivial, it’s actually not since the chronological
misalignment would put an orbiter and its ground support out of step
with navigational assets vital for a shuttle mission, Hale said."
So it is not an "interesting thing", it's a flaw, and I wish Hale would
not pretend not flying end of year was an accepted design constraint for
something originally planned to fly once a month.
OTOH, GPS is relatively new compared to the shuttle. Perhaps at the time
folks felt all that mattered was being able to subtract day-now from
day-start and decided rolling over the date would break more code than
it fixed. Now ya need a date library and date-delta functions and whatever.
This gets to one of my favorite software QA rules: doing things right
can have unexpected benefits, such as gracefully accommodating
unimagined navigational systems of the future.
And yes, there is a corollary to the rule. :)
Another good one:
"his is not the first time that the shuttle programme has been faced
with the year-end rollover problem. On a Hubble servicing mission in
1999, the year of the overblown Y2K computer scare, the shuttle landed
on 27 December (see Fuel fault delays space repair). To make sure the
shuttle got back on the ground before 31 December, mission managers
decided to drop one of the four planned spacewalks."
So they have known about it long enough to do something, unless we are
talking about a huge software review and re-validation, and we probably
are. It really is Y2K all over again.
ken
Rob Thorpe
> Ken Tilton wrote:
> OTOH, GPS is relatively new compared to the shuttle. Perhaps at the time
> folks felt all that mattered was being able to subtract day-now from
> day-start and decided rolling over the date would break more code than
> it fixed. Now ya need a date library and date-delta functions and whatever.
What makes you think NASA ever learn?
Search the web for "GPS EOW bug".
Harald Hanche-Olsen
| What makes you think NASA ever learn?
| Search the web for "GPS EOW bug".
And just what is the connection with NASA again -?
Sorry, I am having a slow day and my google skills must have
atrophied.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Rob Thorpe
> + "Rob Thorpe" <rth...@realworldtech.com>:
>
> | What makes you think NASA ever learn?
> | Search the web for "GPS EOW bug".
>
> And just what is the connection with NASA again -?
Ah, good point, I didn't know it was DoD thing not a NASA thing.