Slashdot Mirror
Software Problem Linked to Osprey Crash
An Anonymous Coward sent in: "While not the only problem facing the ill-fated V-22 Osprey, a bug in the software controlling the pitch of the Osprey's rotors was listed as a contributing factor to the crash of a Marine Opsrey last December. It appears that a hydraulic leak initiated a sequence of events that included the pilot pressing a computer reset button. Rather than resetting the computer, the software changed the pitch of the rotors. Not so good... One more reason to fear too much technology. Has anybody ever seen a bug-free piece of software of any complexity greater than "Hello World"?"
Has anybody ever seen a bug-free piece of software of any complexity greater than "Hello World"?
It's called SLASH!
You seem to have misspelled "Visual Basic".
The link you gave says Naur "informally proved" correctness which is generally a euphemism for waving your hands a bit and then making a guess. If he had actually had a proof, there couldn't have been any bugs in the program relative to the specifications. That's what proving correctness means. Claiming that proving things doesn't work because someone who didn't prove anything wrote a buggy program doesn't make a lot of sense.
Not making mistakes is what makes software robust.
"Sorry Team.
You're going to have to stay late.
Until it's done.
And debigged.
And tested.
And documented."
Gawd that's fscking annoying. The moral of the ad? Why let staff rest when they can just be pumped full of drugs, I forget which particular ones were being advocated, to keep 'em working so they can meet the deadline that the boss horribly mismanaged and allowed to become a panic.
Well SCREW YOU! We are not slaves to be worked to death. It's management attitudes like this, that cause code to have bugs and look like shit. No wonder the code is buggy. The staff writing it was in a big fucking hurry to get it the hell done any way they could so they could go home and enjoy the weekend. What other kind of code could you expect to be produced?
You know what would be really funny? Someone should make a joke about running "Hello World" and having it core dump. Now *that* would be amusing. I'm shocked no one has thought of it yet!
:P
WWJD? JWRTFM!!!
Airbus, while showing off one of the first A320 aircraft at the Paris Airshow (I don't remember what year) suffered a fatal software error in it's fly-by wire system. The pilot was doing a low, slow pass at an altitude 50-100 FtAGL down the runway. The flight control software mistook this for a landing and refused to let the engines throttle back up. The plane plowed into a heavily wooded area near the end of the runway.
If you watch TLC or Discovery channel long enough you will see the footage of the crash. They've been using it in a commercial for the last few weeks.
Of course, this whole thing prompted the (poor) joke: Q: What's the difference between an Airbus and a chainsaw? A:10,000 trees per minute
He pointed out that the software that controls nuclear arms is required to have "path coverage" testing, where every possible execution path through the code has been tested. That is a combinatorial nightmare. (Not to mention that I have no idea how loops work with this sort of testing.)
That was the Hyatt Regency. I stayed there before the accident and when the band would play, spectators on the catwalks would start the catwalks to sway by pumping the catwalks like a swing - adding positive energy.
I lost a co-worker that night that the two cat walks fell. It was their anniversery and their kids saved their money so that their parents could celebrate by dancing, dinning, and spending the night.
The good die young.
And in the end, the love you take is equal to the love you make
I suppose it can be useful to formulate a program in a thoughtful, formalized system. But that's what good code is anyway, so...
It's a shame that programming still has this bullshit mystique of "art" to it.
In many cases, it's not at all a matter of not knowing how to properly plan, design, and test (though sometimes it is). It's a matter of what the customer will pay for, how long they will wait for it, and how important it is for the software to operate flawlessly.
Usually, they want it cheap and yesterday. They want the latest whizz-bang while you're at it, never mind that it has no track record.
When, if ever, the customer wants to pay what it costs, wait as long as it takes (even if the initial estimates are wrong), and use what's known to work, things will change.
Well, actually 'Teach Yourself Java in 21 Days' (yeah, so sue me!) book has as a first code example a Hello World applet, which, you guessed it, doesn't compile.
"Hot lesbian witches! It's fucking genius!"
??=include <stdio.h>
??=include <errno.h>
??=include <stdlib.h>
int main(void)
??<
int rc;
rc = printf("Hello, World!??/n");
if (rc < 0)
exit(EXIT_SUCCESS);
return 0;
??>
Now that's proper and portable C code! Behold it's beauty!
Remember, many characters are not portable across all character sets. The square brackets, for example, dot not exist in EBCDIC. The hash/pound character is often replaced by the British currency symbol in some ASCII variants. Reverse slants do not exist in Baudot or Morse code. And so on. So ANSI C (2nd revision) defines 'trigraphs' of the form ??x where x is a from a list of more universal characters and the preprocessor treats the whole sequence as the appropriate C character. Note that trigraphs can even be used in quoted strings (see ??/ above).
I wuz speaking rhetorically to illustrate the point.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
anyone who has ever written anything, 'nuff said, right?
.
Now, what's described in this Osprey crash, that's definately a bug. The expected behavior was a reset - is the expected behavior of a reset to change the pitch of the rotor? Then the bug was in the TRAINING procedure that recommended hitting that button.
In the real world, bugs range from, mispelled words in dialog boxes, to crashes, to having an OK button two pixels too small. It's all a matter of the opinion of any single user of a peice of software, if a given feature "worked". Worked how? Fulfilled the expected requirements? In 99.999% of the cases out there, the requirements were not well enough defined. For that matter, when you THINK you've got them defined well enough, you start running into semantics issues that would make a lawyer drool. Marketing guy writes requirements, engineer interprets requirements. It's a beautiful world eh? You thought you were writing "Hello World", but now you've got to spit it out in 50 different languages on 10 different OS/Hardware platform combinations, and it's got to be able to notify SNMP and email the administrator if it was unable to do so. And you've got to be able to get it to print out Hello World in the correct language from a single mouse click, and for some languages it has to determine the time of day, and present the greeting as a "good morning, world" or "good evening, world".
Pretty soon you're talking about 200 pages of specs. .
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Then all you have to do is look through the output of the test for each of those infinite possibilites and decide if it was correct.
Of course you could write a program to
verify the results of the testing program,
but it would need its own testing program.
Recurse.
I wrote a program that was totally rock solid and bug free, but it got away...
;->
#define X(x,y) x##y
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
The belly in on the YF-22 (NOTE the 'Y' .. That was a demval aircraft NOT a real F-22) was due to pilot error!!
The FLCS people KNEW there was a problem in the software. (Actually it was a problem with the control laws, not the implementation of the software, hence not a bug.) There was an Aircraft Operational Limitation that specified "Thou shalt not go into afterburner with thrust vectoring enabled."
The test pilot did it anyway on takeoff (probably an accident, pushed throttle forward too far). The system went into oscillation, and the pilot went in belly first for safety reasons.
Anyway, thus endeth my rant.
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
I think you may be missing a key issue here.
...) that this could have been a requirements problem.
...
Everyone is assuming that this was an actual bug. (i.e. a requirement not implemented correctly, or a coding error, or even a design error.)
Don't forget to track back to the next level. It's very possible (and no, I don't KNOW, I'm just guessing
When the requirements were written for the control software, maybe nobody thought to specify what data should be output on that interface in this case. Therefore, there was no test case to cover it, and therefore the software got shipped out the door as "Bug Free" as the creators thouhgt possible.
Failure mode analysis on complex systems is HARD
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
You have to remember that most modern aircraft are aerodynamically unstable. This is done to gain manuverability. They are not capable of flying without computer control. The pilot isn't really "flying" the aircraft anymore, he's just telling it where to go.
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
My experience with realtime embedded control systems has been that (with ada anyway) they don't usually die that way. In fact as I type this I'm trying to recall the last time the system I'm currently coding on went off in the weeds, and I can't. In this case, it most likely didn't go out of bounds either.
...
In my experience, most deeply embedded systems, like flight controls, rarely use pointers. They rarely use any "exotic" language features. They rarely (read as never) use anything that is allocated in a dynamic manner.
When things like this happen (reset problems) usually you end up with a situation where your box gets reset, and you output a default values on all of your interfaces, but these default values may not apply for all situations.
Rather than blaming the coders for these issues and calling them bugs, blame at the systems engineers for not covering the situation when they wrote the requirements. Not that it's easy to do this.
Failure mode analysis in a system as complex as the V-22 is a job I would not want
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
Read the manual page for mf(1) under the "BUGS" section.
--
I think there is a world market for maybe five personal web logs.
I think you are mistaken. Knuth will double the size of the bounty for every year that has passed since he made the offer (in 1986). See my other post in this thread.
--
I think there is a world market for maybe five personal web logs.
Go download the core (e.g. written in CWEB) part of TeX, which was written by probably the greatest computer scientist of our day, Donald Knuth. I don't think a bug has been found in TeX in at least a decade. It's gotten to the point where Knuth will cut you a check for several hundred "hexadecimal" dollars (256 cents ** years since he made the offer) if you find one, which you would never cash anyways but rather mount it on your wall. TeX is definitely a bit more complex than "Hello World". Many people in the publishing industry will tell you that the features it provides could be sold for many thousands of dollars or even tens of thousands as a closed-source software package. It's highly complex.
--
I think there is a world market for maybe five personal web logs.
I'm going to guess that the errors (I count eight so far) are intentional -- he's making a joke, see, in the guise of a stuffy response that failed to get the previous guy's joke, while also accusing him of failing to get the previous guy's joke. Very recursive; maybe his program should also have called main() recursively -- ooh, I'm not continuing it, am I?
David Gould
David Gould
main(i){putchar(340056100>>(i-1)*5&31|!!(i<6)<< 6)&&main(++i);}
Not that anyone will still be reading this, but...
It's fun to argue over which ones "count", huh? The ones I had in mind were 1, 2, 3, 4, 5, 6, and 8 above, plus no "#include <stdio.h>", which different environments might or might not give you for free. I didn't count 7 since I didn't think main() is required to take the standard "(int argc, char **argv)", or are we debugging my sig now, too?
David Gould
David Gould
main(i){putchar(340056100>>(i-1)*5&31|!!(i<6)<< 6)&&main(++i);}
A story in yesterday or today's (Raleigh, N.C.) News and Observer (the people who started Nando), and possibly in the local fish wrapper as well, indicates that the military knew about the problem with the wiring bundle rubbing against the hydraulic lines 18 months ago. The military may be at fault here, but not the aircrew.
I see even classic Slashdot is now pretty much unusable on dial up anymore.
Didn't know there were any other Slashdotters in town except the guy who went up to New Bern when Coastalnet bought out toddalan. Did they ever get the VR trainer for the Osprey installed out there? I was out there a couple of summers ago but forget the building number.
I see even classic Slashdot is now pretty much unusable on dial up anymore.
I think his point is that the basic hello world program:
int main(void}
(
printf ["hello, worldn\'),
}
will always be considered practically bug free. Jeez - some people never catch a joke.
That was a famous accident. The hotel was in kansas city, IIRC. The design of the original structure was sound: a long rod suspended from the roof supported two catwalks, by supporting them both from underneath. Thus, each catwalk support had to hold the load of a fraction of one catwalk. As the drawing passed from the chief engineer down to the detail draftsman, the design of one long rod was changed to two shorter rods. So the builder suspended the upper platform from the roof, and suspended the lower platform from the upper one. The supports for the upper catwalk were loaded with twice the load they were designed for, and the offset of the lower rods caused a torque unanticipated by the designer.
I don't think that's really a bug, because if stdout is not valid, rc will be less than zero and errno will be set to EBADF. If stdout was a pipe that was closed, the program will receive SIGPIPE, which is not handled and thus the program will exit via the default handler.
errno.h was needed to declare errno. Otherwise, gcc won't build without warnings. If I were to just declare extern int errno, I might be stepping on an implementation that uses macros for errno.
As you note, there were several problems. The original design was weak. Then the builder unilaterally decided to build the box beams the way they did. They also did not want to thread the entire length of the rod, so they changed the design to two rods. The hotel's prime contractor would not allow the engineering firm to be represented on site, for cost reasons. All of this added up to the disaster. The hotel was even fucked up before it was complete: 2000 square feet of roof collaped during construction. One of my old professors put up a page about it with lots of picures. Check out this picture of the distressed box beam from the walkway that didn't collapse.
Maybe this is the ultimate version of hello world:
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
int main(void)
{
int rc;
rc = printf("Hello, World!\n");
if (rc < 0)
ex it(errno);
exit(0);
}
I think the real problem is the change in the meaning of the word art in the past ~100 years. What most people think of these days when they hear the word "Art" is what is traditionally thought of as "Fine Arts". The traditional meaning of the word Art was more akin to "Technique". The phrase "State of the art" is refering to the most advanced techniques available. This is also why many universities still call their science departments "The college of arts and letters".
It used to be that professions that required a lot of talent and/or practice in order to master a technique, such as painting or dancing were considered the "fine arts". Then, in the latter part of the 19th century or early part of the 20th century some revolutionary fine artists decided to discard these old-school techniques. In the process they succeeded in changing the traditional notion of art from something that was more technique to something that was more creative.
Unfortunately, the traditional use of the word art wasn't obilterated in the process, so many early computer scientists (particularly Knuth) started to talk about "The Art of Computer Programming." What they meant wasn't that it's a creative process, but rather that it's a technique that must requires talent and must be practiced. Knuth preaches a lot of things about computer programming: programs should be simple and comprehendable, they should implement algorithms that are mathematically proven. It might not be anything as formal as methodologies like ISO-9000, but there's no implication of creativity like, "Let's see if we can fit 30 function points on one line because that would be so cool!"
Anyway, I think the only reasonable solution at this point is to abandon the antique word "art" and start talking about software development as a "technique" or other similar term.
My $.02,
-"Zow"
$ ./a.out
Hello Wor
(core dumped)
$
#define RANT 1
#define BLEARYNESS 1
Software comes in two forms nowadays, it seems:
1. "Not for mission critical applications."
and
2. "We told you it's not for mission critical applications!"
This needs to change. There needs to be a
grade of software that its programmers will
stand behind. It should be governed
by slow and laborious reviews, written by
programmers certified for it. In other words,
we need a software version of the rigors of
civil engineering. (How often does a bridge come
with a disclaimer?) It should be expensive,
(for enough eyeballs, all bugs are shallow,
but also the price gets steep), and it should
come without deadlines. When a piece of software
can kill, the author should not be afraid to
miss his deadlines.
It's my understanding that the rotor size, dictated by the need to fit on carrier decks, prevents autorotation. I don't know enough aerodynamics to know why that is. But I believe it cannot autorotate.
--
Infuriate left and right
In reply to all those that say that using methodical, systematized approaches to software is overwhelming expensive:
Bullshit.
The cost of fixing your own goddamn mistakes, and the cost of maintaining your P.O.S. application is far, far, *FAR* higher than the cost of taking the time to do it right. And the cost to your users is even greater, in terms of downtime, data loss, rework, and inefficiency.
Every naysayer needs to pull his head out of his ass. Go buy some quality education and/or books on software project management.
There has been extensive, exhaustive, and rigorous research on software project management methodologies, software programming methodologies, and software maintenance practices.
They all consistently come up with the same conclusions: the more time spent in planning and design, the less time spent in programming, debugging, maintenance, and end-user failures.
There are NO excuses for the shoddy practices in use today. Better ways have been clearly identified. Your ignorance or slothfulness is an embarassment to the profession.
Do it right, or get the hell out.
--
--
Don't like it? Respond with words, not karma.
NASA's software development methodology is remarkable. Their work should be the standard by which every programmer measures himself against.
Unfortunately, most programmers are underinformed, and haven't the foggiest idea that there's are methodologies that will reduce their error rates, increase their productivity, and meet their customers' needs fully.
It's a shame that programming still has this bullshit mystique of "art" to it. "Art" is just a lame excuse for laziness: instead of approaching the problems methodically and scientifically, it's just ever-so-much easier to take a half-assed hack-and-patch approach.
I think I'd better stop here, before I really kick into a rant...
--
--
Don't like it? Respond with words, not karma.
Dude, I work in a hospital. The firmware on the monitoring systems is reasonable. Almost everything else (financial, scheduling, even pharmaceutical) is the buggiest most bloated crap you're ever likely to see.
It's pretty sad... our main system is basically a Pick (that's right, Pick!) emulation layer running on top of HP-UX. It's horrible.
> Has anybody ever seen a bug-free piece of software of any complexity greater than "Hello World"?"
I've even seen Hello World with a bug in it. Forgetting the \n on the end of the printf in a shell which didn't LF when a program exited resulted in the shell prompt being printed over the top of the output...
You try building something under that kind of methodology, and see what the cost to your productivity is.
Go you big red fire engine!
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
And you've got to be able to get it to print out Hello World in the correct language from a single mouse click,
and nowadays you also have to do exhaustive research to find out if someone has already patented the idea of printing "Hello World" with a single mouse click.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
My Win98 machine isn't as buggy as that airplane.
And you stayed on it? Of the four passengers to board that plane, we know which one isn't the smart one!
--Jim
I can't believe nobody's posted about Knuth yet. Donald E. Knuth is famous for writing high-quality software, and even proving some of it (all of it?) correct. He offers rewards to people who find bugs in his code. The reward for TeX and METAFONT is described here: http://www-cs-faculty.stanford.edu/~knuth/abcde.ht ml, under the heading "Rewards".
--Jim
lame.
7 is moot, since the param list for main() isn't necessary, since the program takes no arguments. besides, it would have been much better had there been a deceptive param list.
8 is also lame. the other poster mentioned that programs calling the hello-world prog would not be reliable, but i think that's more of a design flaw rather than an implementation flaw.
---
eight? i only see six:
1. left-curly-brace after `void' instead of left-parenthesis.
2. right-parenthesis starts the block of code, instead of right-curly-brace.
3. printf args start with right-bracket, instead of right-parenthesis.
4. n\ instead of \n.
5. string arg to printf closes with a single-quote, not double-quote.
6. comma after printf(), not semicolon.
now, i could be lame and count not returning a value from main(), but that's a warning, not an error. and it only shows up if you use -Wall. and let's face it, no real hacker ever uses -Wall.
---
Bugs? What bugs? Those are undocumented features.
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
Rather like techies joke about rm -f /, actually.
If anyone has to do things day in and day out, they will start joking about it. And jokes are often in 'poor taste'. And, if you're their only 'customer', sometimes they will even let down their guard and joke with you. Of course, killjoys like you would be reasons they don't.
Oh, check out here for some great actual airline announcements.
-David T. C.
If corporations are people, aren't stockholders guilty of slavery?
So, if you could win a war with losing one person in half an hour, that would be worse then losing 300,000 people over 10 years? That is illogic. It's total causualties, and perhaps total running time, not casualties per hour. I have no clue who would care about about casualties per hour.
-David T. C.
If corporations are people, aren't stockholders guilty of slavery?
No, they care about total casualties and total time. If they cared about casualties/hour, then they would stretch the war out as long as possibly, with months between attacks.
-David T. C.
If corporations are people, aren't stockholders guilty of slavery?
Actually, I get my information from my aunt, an RN. I was telling you where you could get information. And I'm not aguring with you anymore, anyone who thinks airline pilots and doctors aren't human and don't make jokes about their work is not really worth of my time.
-David T. C.
If corporations are people, aren't stockholders guilty of slavery?
Folks,
I think people don't understand that fly-by-wire systems in general are extremely tricky to set up and work properly.
Remember, when the F-16 was designed, the use of FBW was considered extremely daring--and it took a long time to work the bugs out of that system. Remember the Airbus A320 jetliner? Airbus thought its systems was better until that bizzare crash at Mulhouse, France in 1988 where the plane literally flew straight ahead into the hill. Or the numerous problems Saab had developing the FBW system for the JAS 39 Gripen fighter.
Even now, FBW systems are still tricky to use--witness the problem with the Boeing 777 and the fact there was much complaints from passengers about the plane pitching up and down substantially during turns causing motion sickness; Boeing had to carefully reprogram the FBW software so the plane wouldn't pitch up and down so much during turns.
I think the problem with the V-22 Osprey is that the FBW systems are extremely complicated, and it will take a tremendous amount of work to get everything to work correctly.
Raymond in Mountain View, CA
A) Their own buggy hello world programs gone wrong (modest) B) Other peoples buggy hello world programs gone wrong (liars) C) People who fear technology (luddites) D) People who say it was the human error (technocrats) E) People who don't know what Hello World is (people who use AOL)
---
--
Insert Witty Sig Here
Want bugless code? never going to happen... but programming in Assembly gets you closer to it.
One of the best ways to have minimal bugs in your software is to write a testing program right along with your prize software. Making a testing program lets your test and record infinite possibilities and the outcomes. It makes debugging almost a thing of the past.
"Hello, my name is Bengo, I like to climb on things! Eek eek, can I have a banana?"
I love that record.
I like hubcaps, antfarms, etc.
(jfb)
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
It's true that it's not a technology problem, though - according to some news reports, the government knew there were problems but didn't want to embark on a redesign effort until they had secured funding for a full production run of the aircraft. Like most software issues, this one only became a huge bug when coupled with management's inability to properly manage software development.
Your right to not believe: Americans United for Separation of Church and
--jurgen@botz.org
Right, and hand-held calculators aren't correct to 9,000 significant digits. What's your point? That limitations are bugs? I would suggest that well-documented limitations are not bugs.
yeah, NASA is so great they crashed a mars probe cos they can't tell the difference between meters and feet!
-- Spankmeister General
Even if Naur proved his program correct, about 5% of bugs are caused by operating system, library, or hardware bugs. He would still need to test. For example from work, I work on a Win32 program that uses sockets. Windows 95, NT4, and 2000 have slightly different Winsock bugs. :-(
cpeterso
I had this nightmare once, where I was getting laser eye surgery. Just after they locked my head in place, out of the corner of my, I catch sight of the Micro$oft flag and then ...blue screen of blindness.
clancey
The Challenger blew up because it was launched on a day that was too cold for some o-rings, causing fuel to leak out. Software had nothing to do with it.
-Splat
Shut up you ignorant right-wing piece of shit.
-Splat
Ummm...how many humans were on that probe that crashed? Oh, right...zero. The standards for manned and unmanned spaceflight are pretty damn different.
Why yes, I AM a rocket scientist!
Lots of old bridges have limits on the weight that should be driven over them...
Nerd rage is the funniest rage.
Are you presuming that the Osprey project developers were not following these Methodologies?
Gives a whole new meaning to "kernal panic".
By writing code in a language like SPARK (an Ada83 subset), you can then use mathematical tools to formally prove each part of your code to be "correct".
Just to point a few minor inaccuracies here: firstly, SPARK is not an Ada subset at all - although the executable part of a SPARK program is always a valid Ada program, simply writing an Ada program with the subset of executable statements that is defined to be SPARK will not result in a SPARK program.
This is because SPARK has non-executable annotations (which look to an Ada compiler like comments) which are used for static analysis of data and information flow, and also for proof.
Secondly, even if you do regard SPARK as an Ada 'subset', the recent versions should certainly be regarded as Ada 95 derivative, rather than Ada 83.
The reason why I put the word "correct" in quotes is because there is no good, formal definition of what "correct" means. The code may be provable to do exactly what you intend for it to do, but that's not necessarily the same as what it should be doing.
Good requirements capture and specification are obvious prerequisites to good software: the software engineering discipline does not begin where one starts to write code! The chain is clearly only as strong as its weakest link; historically, however, actual software implementation has resulted in bad, buggy and dangerous software with alarming regularity. Strong static analysis and proof tools can do a lot to minimise that risk when used properly.
-- O improbe amor, quid non mortalia pectora cogis!
Most programmers, including myself, do money-critical software. Unless we are specifically trained to write life-critical software, it would be dangerous to even try. Money-critical coders would write unacceptable bugs into life-critical code, killing people. OTOH, life-critical coders working on money-critical code would get fired for failing to show progress.
Life-critical software is rare; the Osprey fly-by-wire and similar code is part of that. Note that its nav computer, comm scrambler (if it has one), and similar systems are not life-critical.
The reliability of life-critical software must be incredible, by commercial standards. Think of a pacemaker. To make sure that its failure rate is rare, it needs to have an uptime of centuries; that is, we should have hundreds of pacemaker-years before a software glitch.
Even Linux doesn't have that sort of reliability. It claims uptime in years, not even decades.
If you want to write life-critical software, you havew to know exactly what you are doing. You need to test extensively. And you need to limit the scope to the bare minimum.
When you build an airplane, the life-critical software they put on board takes about as long to write as the plane takes to build. That means that a "simple" fly-by-wire system can take five to ten years to write.
Imagine writing commercial software that way. If you really wanted to, you could build a life-critical office suite. However:
The priorities in money-critical software are radically different. We throw away the need for as much quality so that we can get the code out the door in six months, rather than ten years. For that, we get an amazing array of features, and very affordable software.
If we built money-critical software to life-critical standards, we might just might have gotten to QDOS by now. If we built life-critical software to money-critical standards, you'd never see me anywhere near a hospital or an airport.
--The basis of all love is respect
Add in software to control some aspect of flight and the pilot is automatically "further away" from the craft he's aviating. It sounds obvious and I'm not going so far as to say that computer-controlled systems are evil in and of themselves, but it's an aspect of modern flight where the negatives are often overlooked.
I've seen compelling evidence that another layer on top of the data that the plot must interpret is a Bad Thing. Anything that changes the pitch of a chopper's rotors other than your left hand on the collective should be viewed with extreme caution IMHO.
--- Hot Shot City is particularly good.
If I'm not mistaken the reward for finding a bug in qmail-1.03 was never claimed.
That the compiler didn't miscompile your code?
That the system calls invoked have no bugs?
Software bugs can crop up in lots of places other than the code you just wrote...and the farther you get from your own source, the more of a pain in the butt they are to find.
I work for an airline. A big one. It doesn't have any Airbus aircraft in its fleet. Airbus has a philosophy that the airplane is smarter than the pilot.
There's a very famous incident at an airshow where the pilot got a little too close to the ground going a little too slow. Sure getting into trouble was the pilots problem, but the aircraft wouldn't let him get out of trouble.
Now and again, you can catch footage of the crash on Discovery Channel or similar programs.
This is a boring sig
all problems found after the death of knuth will be declared "features".
use LaTeX? want an online reference manager that
-- john
Hello Wor
Segmentation Fault
Yeah -- all my perl scripts sucka
Do you realy think that they would respect US law? I dont. The GPL only has power in countries that have/respect copyright. and China DOESNT.
Sanchi
Some days I get the sinking feeling Orwell was an optimist.
Actually, most versions of 'hello world' that i've seen fail to check the return value of printf!
and in many of them, main does not return a value indicating success or failure. *shrug*
--buddy
I was going to cite the Shuttle as well. Here is a great article about it.
The hostpital that I work at recently spent a couple of hundred thousand dollars on a very complicated piece of patient scheduling (it does other stuff too) software.
The company is MediServe (just so that you guys can know and avoid them in the future) and they sold the hospital this software that was at version 1.x. We should have gotten a discount from them for being a beta site.
First of all, this thing requires an SQL server in the backend to handle the data. OK, that's no problem. But this software can't even talk to M$ SQL server! It required an interface pc to translate between the desktop software and the SQL server.
After that, the real trouble started. Even though it was a 1.x release, the project manager felt that it should have been in the early beta cycle. He would spend hours on the phone relaying bugs to the developers. These were bugs that our poor users were wasting time documenting and working around. (luckily it is currently running in parallel to the original system.) In one week, we recieved 5 (yes, five!) new versions of the software. That was only in one week!.
My theory, is that some moron messed up on the budget and they started running out of capital and had to find some suckers to pay them. and they got paid to have someone else test.
A word of caution to everyone out there, Investigate new applications before you buy!
----------------------
Opportunities multiply as they are seized. --Sun-Tzu
In order for software to function perfectly, three things must be present: a perfect operator, perfect hardware, a perfect operating system and perfect code. If you've got buggy hardware or an unreliable OS, even something as simple as "Hello World!" can bring you down. And if your human operator makes a mistake, then the entire thing collapses like a house of cards.
Some people think that the provably-correct school of software design is a panacea to all ills. By writing code in a language like SPARK (an Ada83 subset), you can then use mathematical tools to formally prove each part of your code to be "correct". The reason why I put the word "correct" in quotes is because there is no good, formal definition of what "correct" means. The code may be provable to do exactly what you intend for it to do, but that's not necessarily the same as what it should be doing. If you're writing code to control the flight of an F-16, it doesn't matter how perfect your code is if your code makes the assumption "hey, if one engine fails, we can just switch to the other".
(For those who aren't aeronautically inclined, an F-16 has one engine.)
The way to produce better code is clear. Publish your code; do internal audits; put it out in the field in non-critical environments for real-world testing; get a good feedback loop going from your users. This results in code we can trust; it does not result in bug-free code.
Perfect systems require perfect operators, perfect hardware, perfect operating systems and perfect software. Even if you can get the last three, you'll never get the first one.
The "urban myth" regarding the Airbus crash is quite obviously false.
The idea that the computer would not allow power to be applied because the aircraft is low, has its landing gear and flaps down (oooh, it must be landing thinks HAL) overlooks the point that applying power in the "landing configuration" is a necessity for the standard "going around" procedure.
Going around is where a pilot aborts a landing for various reasons, and goes around for another try. Full power is applied, sometimes at very low altitudes. The computer would not prevent this. Power is also applied for "sinks" close to the runway, difficult weather conditons etc.
So mod me down, if you must...
The article is kinda thin on details in exactly what way the aircraft acted, but basically these three events occurred:
1. Hydraulic line is severed, warning lights go off, including one on the reset button.
2. Per training, pilot hits reset button once, then multiple times.
3. The rotor pitch changes, causing the craft to inevitably crash.
Now, the article says that the hydraulics have had problems in the past... Here is my take:
In the three pieces I outlined above, two stand out as being really underdefined (or wrongly defined) in the article: Number 1, in that they don't mention what the hydraulic line controlled, and number 3, in that they make it ambiguous as to whether the blade pitch changed, or the rotor (ie, the pod) pitch changed.
The V22 is a tilt rotor craft. Say perhaps it was the pod pitch that changed, and not the blade pitch, and the hydraulics that were damaged were the ones controlling the pod tilt on one side. The reset button is hit, computer say "go into hover mode" and only one pod tilts...
See where I am going at? Perhaps what the reset button did was intentional - but the programmer assumed that both pods were working. I am not saying there wasn't a bug - somewhere along the line there was - but the way the article was written doesn't really tell what happenned...
You may mod me down - I am sure I have various things incorrect (for all I know the tilting is done with electric motors - but I doubt it)...
Worldcom - Generation Duh!
Reason is the Path to God - Anon
Anything that makes you want to get into a chopper should begin with you visiting a mental health professional. Rotorcraft are finicky and dangerous.
I'm currently going through the hoops to get a private pilot's, and from what little I've seen of the aviation world, everything that can be analog, is. And there's a fair amount of stuff sitting in front of you that isn't even electric. The gyro indicators run off of engine vacuum! If airplane engineers have suspicions about electricity, forget about ever trusting anything like a computer.
Some of the newer heavy metal is heavily computerized, but outside of that small minority, most general aviation planes are close to 100% hands on. I suspect that even the fuel injected turbo charged engines have no computer control. And I'm not sure you'd get many pilots into a plane that had a computer controlled engine.
About the only thing computerized that has gained any traction are the GPS mapping units. But those just provide information only, and don't affect any vital flight system.
Like everything in engineering, computerized automation provides some tradeoffs. In exchange for removing some complexity from the user, the cost is more overall chaos in the system. For some applications, this makes sense, for others, it doesn't.
>>Funny, they didn't spec a new helicopter.. The sped'ed a VTOL aircraft.
No, they didn't. This is from Air Wing senior officers *before* the Osprey contract was awarded.
>>Funny. The Corps has been the most vocal in trying to get it finshed.
True, once they got saddled with it, they knew they had to make it work, or they'd be left with nothing. Those CH-46's aren't going to fly forever, they're already WAY past their expected life cycle.
>>Funny. They have been trying for years to get more of one of the most complicated and difficult to fly aircraft in the world. The AV-8 Harrier.
Ever work on one? I have. It's actually a very simple aircraft, and pretty easy to maintain. Having only one engine, you don't have to worry about out-of-balance engines flipping your craft like a flapjack. The Soviets built a two-engine copy of the Harrier, it was the most dangerous birds in their inventory. (Starting to see the flaw in the Osprey?) One of our Harriers hit a Great Blue Heron on takeoff, sucked a good part of the canopy through the intakes, and the pilot still managed to bring it back for a landing (with a dislocated shoulder). The AV-8B is a very rugged aircraft, I'd take a ride in one any day.
>>Translation: I'm a clueless line grunt who confuses my narrow perspective with the requirements of the Corps.
Oops, sorry, I spent over 4 years with Marine aviation units, primarily AV-8B Harriers. While I wasn't a mechanic (Navy Corpsman) I did my share of assisting (carting around parts, holding tools, removing panels, and strongbacking bombs). I've also flown as crew on CH-46 and UH1N Helos.
There's a word for this, it's called "overengineered". The Marine Corps wanted a new helicopter, what they got was on over-engineered, overly-expensive, overly-complicated monstrosity that has already taken taken twice the time it would have taken to develop a new helicopter, and *IT'S STILL NOT READY*. In the meantime, their aged fleet of CH-46 Sea Knights (many with authentic Vietnam-era bullet-holes) is just getting older, and failing more frequently.
Folks, the Corps didn't *want* this piece of shit, they got it rammed down their throat by a congressman who is in the pocket of the manufacturer, and his buddies, who owed him a favor. Now they're stuck with it.
The Marine Corps is the smallest of the military branches, with the smallest budget. They *don't like* complexity or high cost. They want extremely reliable, easy to maintain equipment at reasonable cost. This monstrosity doesn't qualify for even one of these criteria, let alone all three. They even got the name wrong, it should have been named "Albatross".
You cannot believe how grateful I am that I am no longer with the Marine Corps, just so I *never* have to get in one of those things.
I squash many bugs each day and the remains seem to serve as fodder for nourishing those that remain so they can breed more... Such is working on .5 million lines of olllllld krufty code that has been re-worked over years by many hands of varying skill but stll klunking a long and making money kuz it's got a fairly protected niche...
It's still makes money who cares it it's good...
We'll just have it re-written in India next year..
morturii
There is some soft(firm) ware that controls most of the functions of the space shuttle that is tested like no other software anywhere. There 5 times as many test engineers as there are coders. There are also some serious regression tests that aggressively simulate and create problems in an attempt to bring bugs into the open.
"If you love someone, set them free. If they come home, set them on fire." - George Carlin
I believe the computer responded to the hydraulics failure by shutting down the engine. The pilot was attempting to override that (or misinterpreted what had happened?) which was why he was trying to reset the computer.
[...]The Ospery is a plane which requires computer control. No human being is able to compensate or be aware of all of the servos and control surfaces on that aircraft[...]
Example: Program is reset by pilot pushing the button. It can't know why. Reads control and servo positions. Should it try and adjust anything or not?
Remember this was an emergency situation where a physical hydraulics failure caused the reset light to come on. How is the computer supposed to set the hydraulics not to jerk when it first attempts to control the plane with those faulty hydraulics?
If the pilot was not supposed to use his judgment as to whether to press the reset button or not there would be no need for the button and light instead of a direct reset. The pilot was under control of the reset process and chose to punch the button.
Why was that button there, is the question I have. For the flight computer to do what you seem to expect it has to be able to handle an immense number of failure scenarios, and must have the data, sensors, and expert systems programming to detect and compensate for them. Almost, it has to be smarter than a human. It can't be, really.
That's why the pilot is there, get it? In case the light has to be ignored.
In my experience, the designs of systems tend to get fscked up by companies who promise more than they're willing to pay for in the way of engineering, than by the engineers who do what they're told. If it is possible with the budget, time, and technology in the first place - things are often required which are not possible, or wise - like the anti-helocopter cannon that was supposed to anticipate random target movements, or the front and rear positraction ordered on the prototype Hummer vehicles that would jerk the steering wheel out of your hand on turns.
got you beat:
i work at a telco, and our billing system runs emulated wang on aix.
Y'know what I don't get... this is a combat aircraft, but it seems to me that it's amazingly delicate for something that's supposed to be getting shot at. Even with patched-up avionics, the Osprey looks to my untrained eye like it'd be easier to shoot down than, say, a Blackhawk. At least a hawk has the possibility of autorotation - the Osprey looks like it'd drop like a rapidly spinning brick at the first sign of small arms damage. Surely this ain't the case... anyone have any insight into this?
Oh, man, that's fuckin' beautiful.
I feel like I'm in on the joke now.
Haven't flown much, have we? That's OK, when you get to be an adult, you will.
Too true. One of the stewardesses questioned my sanity, and all I could say was, hey, I don't really have a high regard for my own personal safety.
To that end, I also remember the pilot leaning back in his chair and yelling back at me something about some new system glitch, and whether or not I thought it was serious, and I yelled back my standard reply: "(whatever it was)? Hell, that's non-essential, ain't it? Screw the FAA, let's roll! How many people can we possibly kill here?"
But actually, since the "cancellation" of the flight, I knew that all the flights leaving that morning would be *packed* full of grumpy, anxious, sleep-deprived people, many of them with babies. Given the choice between that and a plane all to myself with all the first-class benefits, even a wonky Airbus plane, it wasn't much of a choice. What're the odds, right?
Besides, by that time me and the flight crew were *tight*, man. We were all goin' down together.
Uh... not in the Mile-high Club sense, though.
But if ever there were an opportunity, that would've been it...
Strangely enough, I did. Shame about the flight crew, though. Damnedest thing.
And come to think of it... I've never been sick, either. And I was only faking that car accident injury because I loved my wife. Huh. Maybe I'm... Unbreakable.
I'll be right back - I'm gonna go test that little hypothesis.
I was waiting for a flight on an Airbus one night when they announced that they needed to replace a part, and while it might arrive that night, they told everyone the flight was probably cancelled. Not having anything better to do, and being stuck at the airport anyway, I decided to wait it out.
By the time the plane boarded at 3AM, I was one of only four passengers. Shortly after we boarded, the Airbus computers started having fits. They opened and closed the door to the plane 5 times, went through one shift change of mechanics, pulled away from the gate once, power-cycled twice and finally got the computers working properly at 8AM, exactly 12 hours from when I was originally scheduled to leave and minutes before the flight crew timed out.
The cool thing was, I was the only passenger left at that point. The other three chickened out and decided to go on other flights. I think the pilot would've liked to have done the same thing, actually... he was a little nervous. He told me at one point, after a flap malfunction light came on, that he had a real bad feeling about this flight. They kept asking me what I thought, and my answer was always the same: hey, we're flying light, we don't *need* flaps, right? Let's just go! Haven't they got real long runways in Detroit?
The pilots say they like flying the Airbus, but I dunno. My Win98 machine isn't as buggy as that airplane. You should've heard the mechanics bitching about Airbus computers... I already hate the seats they use, and now I sure don't trust the systems. I try to avoid Airbuses wherever possible these days...
But it sure was a fun being the only passenger on a big jet like that...
7. Incorrect parameter list to main()
8. No return value from main specified.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Speaking as a former employee of a defense contractor, if I were the Navy brass, I'd court-martial the guy who considered the system to have passed FQT without an adequate test.
Whenever we had as system go through QT, we were not allowed to have any priority 1 or 2 problems.
Priority 1 = System failure. Danger to operators.
Priority 2 = Danger to operators.
Priority 3 = Nuisance, no workaround.
Priority 4 = Nuisance, workaround.
Priority 5 = other (minor).
What jerk allowed this obvious priority 1 problem through? I hope they find his ass and court-martial him!
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
they haven't got any new helicopters since the Blackhawk
What the hell are you talking about? My last job was working on the avionics upgrade for the AH-1Z Cobra and UH-1Y Huey choppers!
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Let's see, roughly 100 casualties over 100 hours.
Extend that over the eight years of the Vietnamese War and you get slightly over 70,000 KIA, more than the 55,000 names inscribed on the Wall.
Yeah, that's progress alright.
k.
--
"In spite of everything, I still believe that people
are really good at heart." - Anne Frank
"In spite of everything, I still believe that people are really good at heart." - Anne Frank
I used an animation program called Autodesk Animator and over 1000s of hours use it never crashed once.... I really miss its reliaibilty!
So let's see... it's not a showstopper. A reset button that instead changed the pitch of the rotors and caused uneven acceleration (which the pilot could not have anticipated). That sounds like a showstopper to me.
Ground the planes, fix the bug, fly the planes. A "showstopper" is something bad enough to ditch funding for the project. If a single software glitch is enough for you to abandon an entire project, then you should stop reading slashdot, because at one point in its history, it has had a bug.
I'd try to change your mind, but hopefully you'll just take this to heart and do us all a favor.
--
What happens when you outlaw guns
my bad.
sorry for the flame.
i think we're in agreement that it's time to ground the planes.
--
What happens when you outlaw guns
The report said that the software had been tested in December 1996 but that those tests did not adequately check the reset system.
.357 and do the world a favor.
Speaking as an embedded real-time programmer, if I were designing software to control an aircraft full of servicemen, and I let my software get released into an aircraft without ever having tested pushing the "reset" button in flight, I'd take myself out in the back yard right now with a
I write embedded communications software, and we spend weeks on cold and warm reboot scenarios per-blade and per-chassis.
The worst thing that happens if my software goes down is that somebody's pr0n gets cut off.
Ho-ly shit, folks. Can we all just go out, buy a clue, and mail it to these people?
--
What happens when you outlaw guns
The moral of the story is not that there was too much technology or that there is such a thing as too much technology. The moral of the story is that we need to be a lot smarter and more skillful in the creation and deployment of technology. Another level of moral is that we need a lot better tools and development practices. And a final moral is that we need software that is a lot smarter and that evaluates the appropriateness of a candidate solution that calls for things like changing the pitch of the rotors in a situation where that might harm its occupants.
Apart from the NASA systems, and similarly Boeing which use multiply redundant hardware, the other option is to accept the possibility of coding error.
The flight control systems for Airbus aircraft were written by more than one team of developers and then run on independent hardware and they cross check each other.
This produced a highly complex and highly functional system - for example the crash at a German airshow where the aircraft ploughed through a forest showed that the flight dynamic stabilisation worked even when flying through a forest, most planes would have tumbled once into the forest.
So though each piece of software "may" have had flaws the system itself didn't.
I've seen hundreds of codes, not much more complex than Hello World, that ran great, but did't achieve the correct solution due to a mistake made when formulating the problem.. In other words, the Bug in the V-22 code may simply have been an improperly computed gain setting. Something that the engineers, and not coders, were responsible for..
It's a bug in the Turbo Pascal runtimes. They would do some timing routing that would end up going much faster than they expected on pretty much any 400Mhz+ machine (as the original poster stated), and would it would attempt to divide by zero, thus the program would crash.
I think I had that exact same problem once.. I messed with that for hours trying to fix it. Finally I decided to quit and go back to using C. Though, I've seen plenty of buggy C runtimes as well.. Sigh.
Well SCREW YOU! We are not slaves to be worked to death...
Why heck no! Don't be absurd, sir! You're not slaves! As all students of economics know, slaves receive no recompense whatsoever beyond the minimum barely required to sustain organic life. You programmers, on the other hand, get paid so well you can almost afford to live in San Francisco! In fact, if you're really lucky in your choice of employers, in return for all that exorbitant, nerves-destroying overtime, you get richly rewarded in (drum roll) stock options!
ha ha ha ha ha ha ha WD "f*ck computers" K - WKiernan@concentric.net
I have had a "Hello World" generate a GPF on a winders box so I'm not sure every "Hello Wold" program is safe. I doubt it was the cout "Hello World" endl; that did it but all the other error checking put in the code by your friendly neighborhood winders compiler. But to winders credit after a reboot it did work.
Shouldn't it read "Osprey Crash Linked to Software Problem?"
I can picture it now, an Osprey smacks into the side of a server. "Shit, need to grab the patch for that," goes the admin...
Sorry about the misunderstanding. When I was working for the US Army Corps of Engineers, a showstopper was a flaw in a project of significant enough size that we would free the work where it stood, evaluate what was wrong and propose solutions. That's how I read "showstopper". A single glitch isn't enough for me to abandon a project, but if that glitch poses a serious risk to life then I'd put things on hold for a serious shakedown.
Anyway, you have a very valid point, and I think some further clarification by the congresscritter would have helped.
If I could only live my life with my threshold at 4...
and then later...
So let's see... it's not a showstopper. A reset button that instead changed the pitch of the rotors and caused uneven acceleration (which the pilot could not have anticipated). That sounds like a showstopper to me. An we trust people like Rep. Weldon to run the country? Well, as long as he keeps the factory in his district open, I guess that's all that counts, right?
Sigh.
If I could only live my life with my threshold at 4...
It only needs to return a status code when you make main an int. So step 5 is not a bug until you do step 1.
I personaly wrote BUG free 600k LOC. (in one application)
And several 100 kLOC programs which are bug free.
Howver during Y2K reengineering I analyzed 500 k LOC COBOL code and found about 5 bugs.
I know personal several people involved in severl million LOC programs which are considered bug free.
AFAIK the software of teh space shuttles is considered bug free. (and had only foud 4 or 5 bugs after shipping it)
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
void main () {
printf ("Hello World\r");
}
Nice example, but you haven't made a proof that such a program can be made, bugfree!
Riiiight, you deliver me a development CV-22 aircraft and I'll get right to debugging that as soon as I download the source code from Boeing's website.
<rant> The same people who argue that hardware is cheap enough to afford sloppy code are the same ones who later say "fear technology",</rant>
Folks this is what you get when you hire idiots who say, "but I just wanna make some money. I got um cert-t-tificate."
If employees have no interest in the product give them a job suited to the amount of effort they put in on a regular basis.
The message on the other side of this sig is false.
Somebody set up us the Bong... er Boeing... er
The message on the other side of this sig is false.
Or is this the Evil Mach Kernel proving itself?
Ya know, the last thing I want to do is climb into a device that moves me places at 300 + Mph, with the software that controls it still in beta.
No no no. Lemme guess, the control software was written in Qbasic? Visual Pascal? Logo?
Get off my virtual lawn, you damned virtual kids!
They load the vehicle up. They take it over enemy territory.
The control computers determine the appropriate target and desync the rotors. Twenty tons of flaming steel fall onto enemy heads.
We MEANT to do that. Yah we did. :)
Get off my virtual lawn, you damned virtual kids!
http://www.fastcompany.com/online/06/writestuff.ht ml
That has a good article on how the programmers at NASA write their software. They're on budget and on time.
This reminds me of when the ESA first launched Arian 5. They apparently reused the software from the Arian 4 rockets.
There was a fuel shut off problem i think and it went of course and they were forced to detonate. Cost them a lot of money..
but then again no one was killed by it, thought the reckage was spread out over a bunch of villages i heard
"I'm like an opening band for the sun" -Pearl Jam ; Yield ; Push Me , Pull Me
> It's a bug in the Turbo Pascal runtimes.
:= x + 1;
I certainly believe that. I ran into some truly bizarre problems with Turbo Pascal. At one point, I was writing a simple game, and the program kept hard-crashing the computer. Eventually after several reboots, I managed to use the debugger to isolate the statement in the game loop which was crashing. The offending statement was this:
x
After a seemingly random number of iterations, somewhere between 100-150, the debugger showed this statement as being executed when the PC would crash. Never did get around it. Guess it just goes to show that when it comes to totally bug-free code, you can't trust anything.
How do you make a bug-free Hello World program? I'm a senior in Computer Science and have yet to hear any credible evidence of such a program existing.
Has anybody ever seen a bug-free piece of software of any complexity greater than "Hello World"?"
I once wrote a "Hello Universe" that I was fairly confident was relatively bug free.
When will Windows be ready for the desktop?
The Airbus computer can be overridden, but you're right in the fact that their philosophy is that the computer is always right.
This gets into the whole Boeing vs. Airbus commercial airplane debate. Boeing has had a history of listening to what pilots want in an airplane, and they all want force-feedback on the controls. Therefore, the 777, currently Boeing's only fly-by-wire aircraft, has force-feedback controls. From a "touch and feel" point of view, you will get the same response from the controls of a 777 as you would from any other mechanical/hydraulic flight control system.
Airbus, on the other hand, decided to skip the force-feedback and use a sidestick as their control. Therefore, the pilot cannot feel what the airplane is doing by just resting his hand on the controls. Later models of their fly-by-wire jets have force-feedback as I understand.
- "CTRL" + "ALT" + "Crash into the Ocean"
Seriously, I thought that plans would use a real-time OS and wouldn't *need* to be rebooted!-----
A two processor approach is unacceptable for mission critical applications where both safety and uptime are important. If the two processors disagree, what do you do ? That's why systems with three processors and majority voting have evolved. But even then, why make the processors redundant when the sensors and actuators fail much more often ? Garbage in, garbage out !!
Except for the elegant part.
Your example of the shuttle and NASA certainly has merit. I recall an excellent article geared towards the DEV/QA crowd that detailed the processes and methodologies they use. For example, every single class or function is 100% documented in detail, including _all_ variables and any dependecies. This goes into a DB they maintain specifically for this. If a change is made then they have no further to look than the DB to be able to compare where and what. However I would say that even that level of attention to detail does not deliver what is being asked. The truth about the quality process is that there IS NO SUCH THING AS DEFECT FREE. It isn't possible without restricting the size of the application. The trick is to correctly identify the critical defects, and to follow the 80/20 rule. Once those defects are resolved, take what's left and do it again...
You're also right about the air war of course, which again furthers my point. It lasted for weeks, but because of superior technology, we were able to beat down the Iraqis at minimal cost in lives.
I do remember the Valkyrie. I do remember the SGT York. But I'm also familiar with the Blackhawk, the F-16, and a few other extremely complex pieces of technology that work rather well. My whole point was that we shouldn't throw the baby out with the bathwater.
I also know that flashy technology doesn't always win the day. Remember the GAO study about all those Scuds the Air Force "wiped out"? Turns out the only Scuds that were ever provably killed were taken out by Special Ops units on the ground. The Pave Low and other very sophisticated equipment certainly helped them get there, though. ;-)
Read the EFF's Fair Use FAQ
maybe that sentence would be better as "one reason to fear poorly implemented technology".
Let's not forget that the technology in the V22 is akin to the technology that allowed us to wipe out most of the Iraqi army in 100 hours with an incredibly small number of Coalition casualties.
This reminds me of the negative press coverage the M1 tank received during trials because it used a turbine engine similar to those used in helicopters. The engine had problems during trials and was roundly criticized for being costly and "gold plated".
That same turbine engine, after the glitches were fixed, turned out to be more reliable than the old engines it replaced. The M1 went on to become the most feared and capable main battle tank on the planet, easily taking out T-72 and T-80 tanks before they could even DETECT the M1.
Technology in military systems is always risky in one way or another, but the ultimate payoff is usually more than worth that initial risk.
The V22 has been plagued with problems from the beginning, and they may be pushing the envelope a bit too far with an overall concept that is just not workable. But if they do work out the glitches, the V22 will go from becoming an example of "too much" technology to an example of "amazing" technology.
Read the EFF's Fair Use FAQ
Is a bug a crash, or is a bug some sort of undesired action? I suppose a bug is an undesired action... So if this program prints "Hello world!" on my screen, while it is supposed to simulate a rocket engine, then we would be talking about a major bug!
Bizar technology?
Planes don't "crash" anymore. Now they "blue screen."
Only if they're landing in the water. On land it might be a black, grey, yellow, green, or white screen.
Tarsnap: Online backups for the truly paranoid
As a pilot and software engineer, I find that the Airbus philosophy -- that the computer can never, ever, screw up -- fundamentally flawed. There's no frigging way that a bunch of French (or any other nationality) coders correctly coded the system to handle every flight regime. You bet your life that they correctly coded the FBW system every time you board an Airbus.
Do you feel lucky? Well, do you, punk?
It's Linux, damnit! Pay no attention to renaming attempts by self-aggrandizing blowhards.
Yeah, that would be:
#include <sdtio.h>
void main(} {
printf("Hello, wrold\n)
return 0;
)
then?
Seriously though, as I understand it, software errors have been the cause of a number of aeroplane crashes and near-crashes. Wasn't the Paris airbus crash software related? In fact I just did a quick Yahoo search and came up with Airbus 320 crash at the Paris Airshow, 1988.
return 0; }
I'm sorry Dave I'm afraid I can't do that. (Osprey pitches forward)
How about: 'Hello World, How are you doing?'
In the "software engineering" realm (and I use that term loosely), who gets blamed? Are individual coders going to start taking the fall for software that blows up (literally)? Where might this lead?
I heard about this on the news this morning, and my first thought was "Was this a design or coding error?" Was the software specified incorrectly, or did the programmer implement it incorrectly (i.e. the canonical "it blew up because of an extra comma" error)
In other engineering disciplines, it's usually the case that the designer and the builders are distinctly different people, and it's easier to say whether the problem was a design issue ("They didn't plan to have enough rivets holding the bridge together") or a building issue ("They didn't put in all the rivets that were supposed to be there")
--
The important question to ask is "Why doesn't good software exist?". The reason is that the consumer wants it yesterday, they will pay for an unfinished and incomplete project (nee almost all windows software). This leads to cut & paste programing, re-use of lots of pre-done code supplied by various manufacturers and the like. If the customer demanded well sorted out code, and refused to "upgrade" to the next best thing then you will see better coding.
Last and not least lets not forget the customer, the US govt. The Osprey has always been considered a boondogle from the get go. The pressure from congress and media to get the progect completed has been extremely intense. I'm sure a lot of pressure was put on the coding team to "get it done now". It's too bad that they didn't learn from the Space Shuttle, over budget, and over designed, it works. It has passed all expectations and is doing things now that it was never designed to do.
There is an engineering credo there, the famous "factor of saftey". A number usually applied to equations to take into affect the "unknown". Looks like the Osprey designers didn't make their "factor of saftey" high enough.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
As many of you may remember, back in the old days commercial jetliners had three crewmembers. Pilot, copilot and radio, iirc. But, due to increasing automation and computer control, they were able to reduce it to two people. Now, things are becoming so automatic that Boeing is planning on reducing the crew requirement on their generation of planes to just a pilot and a dog.
Why a dog?
To bite the pilot's hand if he tries to touch anything.
Whoo, I crack myself up.
The only "intuitive" interface is the nipple. After that, it's all learned.
"The question of whether a computer can think is no more interesting than that of whether a submarine can swim" -EWD
and modest too, I see..
moo.
jeez, what were they running? WinCE?
Software through process is the secret.
l
http://slashdot.org/articles/00/05/19/050258.shtm
Government is the abdication of your responsibility to a faceless bureaucracy. Anarchy(absence of government)is the a
Other A320 problems have generally involved having flight deck systems in the wrong mode. This is a recurring problem with complex aircraft.
The Osprey problem, though, may be an out and out bug. That's different.
> Has anybody ever seen a bug-free piece of software of any complexity greater than "Hello World"?"
The answer is "yes" for any piece of code that I have written top to bottom that I have also had the chance to look at twice. It really isn't that difficult if you have been fixing other people's code and writing your own code for almost 20 years. More people would become competent programmers if they didn't become incompetent managers after five years instead.
I tend to write my code in several phases:
Yes, this is generally considered almost completely backwards, but I find it much easier to hold a large design in my head than it is to put it down on paper until after it has been realized. It probably explains why I don't have a crowd of programmers working for me instead of around me. But the programmers around me still ask me questions on how to do things all day long, so I must be doing something right (even though I no longer get anything done during regular work hours because of the continual interruptions).
I would also be putting the external documentation higher on the list if I wasn't currently being forced into using MS Word. Switching back and forth between a Windows box and a Sparc is not conducive to good work on both. The work on one or the other will suffer.
If he had actually had a proof, there couldn't have been any bugs in the program relative to the specifications
"Relative to the specifications" doesn't mean too much in the end, because it assumes that the specifications are the end-all be-all to what goes in the software, and are by definition correct. Of course, we are human, and this is hardly the case. There are sometimes "gotchas" or special cases that come up that aren't in the specs. Someone thought they were being absolutely clear when they weren't, etc. Is that a valid bug when it surfaces in the code? Absolutely.
Then the responsibility is put on the specs, so one may say "well, make sure the specs are right." That's not as easy as it seems, since the English language alone has communication problems. Add on that someone has to read through it all and flush out everything that it says, ensuring that no other person could possibly find something misleading or incorrect in it. This has to be done to a certain extent, but eventually you're going to hit a wall where it doesn't pay to refine the specs any more. Of course, it still won't be perfect, and software that is proven to operate by it still won't necessarily be bug-free.
Don't get me wrong, proofs are fine as a first step, but people make mistakes. Specs can be misleading, cases can be missed, etc. You need to also test, plain and simple.
Not making mistakes is what makes software robust.
It sounds pretty simple doesn't it? Just be perfect, and your software will be robust. That's fine for the gods, now what about us mere mortals?
you're being stupid. the post that started this said something like "proving doesn't work, you need to test". your point is that proving doesn't work because people make mistakes. well, testers make mistakes too, nitwit, so you have no point.
I didn't say testing was perfect, that would be silly. But at this point, you're just being rude.
Let me try to put it in a way that cannot be misconstrued easily. Proving is fine and dandy for those who want to do it. But like anything in software development, it doesn't mean "bug-free", or even excellent code will result. That was my only point that I was trying to make by giving the Naur example. The idea behind the Naur program was very simple, yet it still had errors in it. Personally, I regard proving as less effective (costwise, maybe) than testing. Again, personally, I would appreciate the statement "The software has gone through rigorous testing" more than "The software has been proven to be correct". It's not an either-or situation, I realize, I'm just proving a point. That's my opinion, and everyone has their own, so if you don't like mine, then ignore it. Software methodologies discussions are full of opinions, and mine is just another one of them. Feel free to dismiss it.
Proving software correct shouldn't hold much weight. Testing is really the only way to go.
For instance, here is a pdf that mentions Naur "proving" a very simple ALGOL program correct, but obviously not testing the code. The program was only 25 lines long and reformatted text (basically a word wrapper). Later on there were (at least) 5 bugs found in the code.
Which goes to show that testing is what makes software robust.
as i read it, the hydraulic system degraded, and the pilot hit reset 8-10 times as the plane went down (per the book).
no offense, but given all the problems with the hydraulics on this beast, and the people ordered by the military to lie and falsify records regarding those problems, i think a s/w glitch is a bit later on the list.
i do think it's a shame that the software wasn't written well enough, or tested well enough, to save those people from a mechanical failure.
maybe management is right -- just give it all to microsoft and let the H1-B's deal with it.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
Well, fly-by-wire (completely software controlled) aircraft have been around for about 25 years. Lately, though, the spectactular problems with the software seem to be coming from the government run programs. These problems include: - V-22 crash - F-22 crash - Airbus crashes to numerous to mention Seems that Boeing, though, built the 777, and has had almost no issues... Could it be because they would LOSE THEIR SHIRT in the hyper-competitive PRIVATE market of airliners if they had a single problem? Or maybe that there were no government entities backing them up (Yeah, looking at you, you Airbus people) if they screwed the pooch? Hmmmmm...
A group of technical leaders were at a seminar called "Making Reliable Software". The teacher at the seminar, in order to make the participants appreciate the problems of reliable software, posed this question: "How many of you would be willing to fly in an airplane that was controlled by software that your company created?" The technical leaders thought about it, and looked around at each other. Nobody raised their hands, except for one lone guy in the back. The teacher was suprised. "You, in the back," he asked. "Why are you so sure that it would be safe?" "Simple," replied the programmer. "Knowing how my guys code, the plane wouldn't even be able to pull away from the gate."
When was the last TeX bug award given out?
Lets say that you have 30 million lines of code? Is it possible to say "this code works 99.999% of the time?" What about 300 million? What about 30 billion? Is there some critical mass for software where it then becomes theoretically too complex? Will there be a similar limit for hardware? Any URLs?
A pilot I know says the plane to fly is the 777. Easy to fly, no problems, passengers are always happy. Everything dealt with automatically.
He definitely doesn't like the Airbus.
The Airbus is too buggy.
Cheerio,
Link.
Thing is they don't do software the same way.
:).
:). I believe the world is full of such prototypes.
For civil engineering, I believe you often do the prototype or model first then you build the real thing.
With software the trouble is your model/prototype/blueprint is often fully functional...
Basically architects prepare a blueprint of the building they are going to make, down to every single detail if possible, then they pass it to the engineers who pass it to the contractors, and along the way sometimes things are changed/fixed.
But if you do that with software, the "blueprint" actually "works"
So when you try to do the same thing, the bosses often can't tell the difference between the prototype and the real thing (or don't care), and you are often asked to ship the prototype
Are they going to wait a year or so for your contractors to "rebuild" it for real, brick by brick? If you ask for a year more, they tend to ask for more features.
Of course instead of rebuilding, you could go over your "blueprint" so thoroughly that when it's complete, it's almost perfect. But that still takes time.
Also adding stuff doesn't necessarily make a program more reliable. Whereas you can over-spec buildings by sticking stronger and more materials on them. Then you can be reasonably sure they won't fall down under design conditions.
Cheerio,
Link.
Yeah, I agree with you.
People who put shit in jars and call it art are the ones who lack talent, imagination and creativity. Not those who don't think it's art.
I regularly put shit in a toilet bowl and though the results are unique each time, --insert your favourite blahblahblahblah here--, I don't think it's worth calling art.
There are still lots of artists in the world, but few are found in those "institutions".
If I'm trying to create art, I sure hope it's going to be close to the best I can do. But if the best I can do is put shit in jars, well it's a sad day. Doing your best doesn't necessarily make it good enough. Too often modern culture thinks otherwise.
What those great artists threw away was often better than what some of these "acclaimed" modern artists put out.
Cheerio,
Link.
....keyboard and chair
In as much as we would like to have "fail safe" applications, nothing is without risk. Randomness is a funny thing. When it occurs, and how it occurs, is non-predictable.
Assume that the software is 100% certified bug-free. Ok. What about the hardware running the software? Some lowly $0.01 peice of resistor decides to crap out. Software works fine, too bad the hardware needed to run it has gone tits up.
Entropy. Randomness. Human error (the biggest one).
All these things help keep our world from being a clockwork universe.
Isn't it fun?
It's not possible to have a complex bug free program when users expect software to act unpredictably and just adjust.
E.g., the pilots all learn that pushing reset makes the rotors tilt.
Then they don't like it when you fix it!
So, just what is a bug, anyway???
"I want my job to be the guy who kicks George Bush in the face all day, only stopping to make out with him."
Next question, what would be the point of open-sourcing it? It's not as if you could just port the code from an old aircraft to a new one. It may surprise you, but the code running on a Tornado is not the same as that on a Harrier or Typhoon. Each aircraft has different requirements (those laws of aerodynamics again!) and the control code has to be tested against those requirements.
-- flossie
http telnet
flossie
Write now. Defend liberty
-- flossie
http telnet
flossie
Write now. Defend liberty
In the aerospace industry, even duplex systems are considered too risky. Quadruplex is the norm; with four computers, if one fails the remaining three can still "vote". Safety critical software cannot be trusted to just one computer as there is always the possiblity of failure.
Many modern [unstable,agile] aircraft are not controllable by a human without assistance from the Flight Control Computer, so a total failure of the Flight Control System is unthinkable. As far as pilot intuition is concerned, this can be worse than useless for an unstable airframe. There is a condition, not limited to unstable aircraft, called Pilot Induced Oscillation, where a pilot's "corrective" actions cause unstable dynamics to occur, sending the plane out of control. Just because a human is involved doesn't necessarily mean that s/he has the best solution to some very complex equations of motion
-- flossie
http telnet
flossie
Write now. Defend liberty
-- flossie
http telnet
flossie
Write now. Defend liberty
To the issue at hand, although voting is an integral part of safety/mission critical systems, this pales into insignificance compared to the need for well designed and thoroughly tested code. It is not enough to test components in isolation. In any real-world complex engineering system, it is the interactions between components that are of the greatest importance, not just the individual components themselves. The formal proof of the correctness of a few "key components" is not enough. Would you normally consider a hydraulic line to be a key component of a reset routine?
-- flossie
http telnet
flossie
Write now. Defend liberty
-- flossie
http telnet
flossie
Write now. Defend liberty
Regarding the incomprehensible fragment of code that you are keen to show off, don't bother. Send us the machine code and it can be reverse-engineered well enough.
-- flossie
http telnet
flossie
Write now. Defend liberty
-- flossie
http telnet
flossie
Write now. Defend liberty
Assembler is far to bloated... Much better to use hand tweaked machine code...mmm...pages of hex...
This is a military project that should have died years ago. Politicians want this bird more than the pentagon does. It is build in important political districts, not by accident, so that it can't be killed easily by congress.
/.ers sig, just because the osprey is a possible solution doesn't mean it must be the one used.
The solution is to require every member of congress that supports this fuster-cluck to use one exclusively for all air transport, both for him/her self and their family. How many of those vermin will risk their own families to keep some worthless, unsafe pork barrel project going? And the ones that do will help clean out the gene pool when the next one crashes.
There are better ways to accomplish the same mission the osprey does. Its time to utilize them instead. To paraphrase another
end of rant/tirade against corrupt pols (oops - redundant phrase)
The first thing we do, let's kill all the lawyers. Shakespeare, Henry VI, Part 2, Act 4, Scene 2
This has nothing to do with production schedules. The problem is that a pilot (and presumably other associated induhviduals) were faced with a machine containing a.) a cutting-edge (no pun intended), incredibly complex mechanical plant of a type never attempted before, and b.) a complex but _really_ not leading-edge computer program to help him control all that machinery. When a problem occurred, the pilot apparantly felt, against all logic, that the problem was more likely with the fairly simple computer than the brutally complicated mechanism it was connected to.
Apart from the highly debatable logic of rebooting the computer in mid-flight in a fly-by-wire aircraft, the question we should be asking is "why did this guy automatically assume the computer was at fault?" My theories: a.) Computers have that big a reputation for unreliability. b.) MS software has taught the world of users that ctrl-alt-del is the answer to everything. c.) (this is the worst) our society is so narrowly focused on computers and software that even a Marine, someone who lives his daily life as close to nature and physical reality as you can get and still be in the United States, chose in a moment of crisis to think that it must be the computer's fault.
*** ***
we do control code for radar in military helicopter and the standar and testing force us do be bug free but the cost are way up there...
to sig or not to sig that is the question
enought said.
and when i press my face against the frosted shower stall
Monkey sense
Monkey sense
Monkey sense
http://www.bootyproject.org
OtakuBooty.com: Smart, funny, sexy nerds.
Hello Wor^
Segmentation fault (core dump^
Segmentation fault (core du^
Segmentation faul^
Segment^
oh, fuck it ...
KERNEL PANIC
Many of the small programs that I've written for my computer science courses are more complex than "Hello World" and yet are still bug free.
Now, they occasionally contain undocumented features, but not bugs. No-sir-ee.
--------------------------------------
If Murphy's Law can go wrong, it will.
I would venture to guess that the software controlling many nuclear powerplants and nuclear weapons, while probably not as rigerous, are probably written and monitored quite well.
I'd have to disagree with you. In the time the ISS has been in orbit, there was a major issue with the software that endangered the entire mission. After a module had been added to the structure, the ISS software was not updated with the new weight and center of gravity for the structure, causing a near-miss with a piece of space debris. Check NASA Watch for more information, specifically the letter from Sensenbrenner, the ranking chair of the Committee on Science, to Dan Goldin.
Other systems on the ISS are apparently flawed also. Astronauts have reported many problems with the systems designed to do inventory management, waste disposal, etc..
BAE Systems (http://www.baesystems.com/ and more specifically, their control systems division, http://lmcontrolsystems.com/) is the company that wrote the software that malfunctioned. I interviewed there recently, and they just gave me an offer of employment (I'm just getting out of college). It looks like a good place, I wonder if I should accept their offer now...
I once met a guy who fucked up "Hello, World". He said "Helo". Fucking idiot.
All software should be real-time anyways.
pi=sigma{n:0-infinity}[(1/16)^n][(4/(8n+1))-(2/(8n +4))-(1/ (8n+5))-(1/(8n+6))]
First they crash, then they crash again!
--
Dyolf Knip
Ever seen Pick's D3 database software? By far the most worthless piece of junk I've ever had the displeasure of working with. Didn't do one tenth of what they claimed and failed to do anything on a system, client or server, that was running IE 4.0 or above. What's the connection between a browser and a DB? Beats me, but IE 5.5 came out before they got around to fixing it.
--
Dyolf Knip
maybe a good "Goodbye Cruel World" damn...shoulda posted AC
# Tom von S.
# -------------
# "Nuclear weapons can destroy all life on earth,
no,
features == bugs
but
bugs != features
as
bugs == idiocy
quite often
# Tom von S.
# -------------
# "Nuclear weapons can destroy all life on earth,
"Has anybody ever seen a bug-free piece of software of any complexity greater than 'Hello World'?"
Unforunately, you're making a pretty immature point. In this case, a bug has put human life at risk. And to a further extent, what if it had fallen into the streets of New York?
Certainly nothing is bug-free (maybe), but this did not have to happen, and should not have.
The next comment I write will be ready soon, but subscribers can beat the rush and see it early!
When Fly-by-wire software was first under consideration, one crucial aspect was made abundantly clear: "It must be at least as reliable as the wing spar(the part that holds the wings to the airplane)" With that in mind, the USAF (I think) got some code from NASA that had been developed and used it to control aircraft. I am unaware, until the Osprey crash, of a fly-by-wire software system that had production errors.
Only if they're landing in the water. On land it might be a black, grey, yellow, green, or white screen.
Don't forget red (rookery of penguins or herd of cows).
Yucky
-Christian
our written thoughts are gifts to our future selves
This guy is right.
Having thousands of open source developers collaborate together to improve military software is the best thing that we can do.
Conformity is the jailer of freedom and enemy of growth. -JFK
No, since the GNU General Public License requires that you publish the source code of everything, we would know who had the technology.
The country that 'stole' it would also have to provide the source of any mods that they make.
The is no room in this world for non-Free software.
Conformity is the jailer of freedom and enemy of growth. -JFK
Looks pretty hairy... what is that language? is it for microcode or something?
Conformity is the jailer of freedom and enemy of growth. -JFK
If you're a male, it's unlikely you will ever see that monitor, since it is a fetal heart rate monitor for pregnant women. :)
To be fair, it's been my experience that it's the data acquisition port part of the monitor that's been so atrocious, not so much the "operational" part of the firmware. I'm sure that gets a lot more testing and attention.
What's kind of amusing is that in later versions of the Corometrics monitor they threw away their own protocol and implemented their chief rival's: HP's.
--
Sometimes it's best to just let stupid people be stupid.
But you're assuming that we, as Americans, care about internationalization issues. [RM101 ducks, as the truth of this strikes too close to home...] :)
--
Sometimes it's best to just let stupid people be stupid.
I used to write drivers that communicated with medical monitors. Talk about garbage! It was the exception rather than the rule that the monitors worked exactly how they were documented.
My vote for the medical monitor with the worst software and by far the worst communication protocol has to be the Corometrics 115 monitor. Anyone else ever have to deal with that piece of crap? My condolences if so. It took me literally *years* to get the driver to work perfectly in all situations, because there where so many versions of the firmware that caused it act differently in different situations. It was always fun debugging software running in a live patient environment. :)
--
Sometimes it's best to just let stupid people be stupid.
From the Article: "The software code was written by BAE Systems and was integrated with the Osprey's hardware by Boeing, Pentagon officials said."
In other words All Your BAES Are Belong.. Oh nevermind.
:)
You wouldn't hire a 24-year-old architect to design a million-dollar building. But experienced architects are using software written by 24-year-old programmers to design million dollar buildings.
No offense, but this is a red herring.
The tools used by architects (and other professionals) don't necessarily have to meet the level of sophistication of their users. They only have to meet the requirements for the jobs they do. Programmers don't design buildings, but probably the software the architect uses was programmed under the direction of an experienced architect.
Put it this way, do you expect the low-wage workers who assembled your computer to be replaced by the highly-paid engineers who designed it?
There's also an implication of ageism in your post that disturbs me. Who cares how old the programmer is if he or she is qualified to do the work? Your 24-year-old might have 10 years of coding experience. :)
- MFN
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
Steve Ballmer of Micro$oft couldn't be reached for comment. A PR monkey from the company is saying that he and the developers of the software are currently being court-marshalled for their recent incedent of the Osprey crash. The PR money has been quoted to say, "Geez! First God misses us with that earthquake and now this! Can't we get all get along? It was an accedent! We weren't, like, trying to pressure the government or anything to drop certain anti-trust charges."
At that moment FBI agents charged the podium and arrested the PR monkey for consiring to stop a military mission.
Karma whorin' since 1999
Almost 20 years ago, Don Good's group at UT Austin delivered the Message Flow Modulator to the Navy. The program was basically a technology demonstration: it showed that a nontrivial piece of code could be designed and formally verified to be correct. Written in the Gypsy 2.0 language, and running on an LSI-11, the Message Flow Modulator sits on a serial line and filters message traffic. Messages that match a set of rules (that are defined by the user) are passed through, messages that don't match are dropped. The program was about 1000 lines of executable code, and about 1500 lines of type declarations and specification statements. Gypsy was a PASCAL derivative, carefully pruned and extended so that every statement had precisely-defined semantics, that could be mechanically verified, using an automatic theorem prover. Don's group developed the code, and the formal correctness proof. The acceptance test suite was developed by a different contractor, out on the West Coast. The Message Flow Modulator saw the acceptance test suite for the first time at PAX River NAS, during the actual acceptance test. It passed. No deviations, no waivers, no ifs, ands, or buts. It passed. On the FIRST try. This had NEVER happened before in all the history of military computing. Don's group got a LOT of attention as a result. I worked with Don's group in the late 1970s. I learned a great deal from the experience.
Greater complexity than Hello World? That's nothing! How about concatentation the strings "Hello" and " World!" together and THEN outputting it to the screen! Man, oh man. Still need to do the regression testing, though.
-- dR.fuZZo
the software that NASA uses on satalites, the shuttle and the ISS are the closest to bug free that there is. Software that runs embedded systems like life support and ATM's are also very good. That is the ONE strength of ADA (god help us). Thankfuly the military doesn't have me working on that stuff, I work on the E-3, posibality the greatest computer hack off all time, TD-Gen makes brainf*ck, mindf*ck or what ever it is and intercal look like basic. E-Mail me and i will sent you some source (only for the VERY brave)
Sanchi
"They said we couldn't do it [Athlon]... but we built it, we shipped it... and we didn't have to recall it." Rich Heye
Actualy, the Marines and Navy never realy wanted to use the plane. It was forced on them by congressman who wanted to make a few jobs in his district.
Sanchi
"They said we couldn't do it [Athlon]... but we built it, we shipped it... and we didn't have to recall it." Rich Heye
Hello world is already a pretty complex piece of software...
Think about it : you are actually doing an output to the screen.
What are the chances that the print instruction is completely bug-free ?
Especially if it needs to go through the OS rather than just being a memory copy...
When Dick Cheney was Secretary of Defense the DoD tried to kill the Osprey because it's overpriced and unreliable. Idiots like this guy kept it alive, solely because the plants are in their districts.
sulli
RTFJ.
bugs == features
QED
Testing is a part of software development. I do not do enough testing, and it is painfully obvious that the well-paid professionals also do not. I would hope that before any more of these aircrafts are produced the managers are tied to chair and forced to read a good book on producing quality software.
I was watching a documentry on the stealth bomber. EVERYTHING on that plan is controlled by computer. Infact - none of the control surfaces (including throttle) are physically linked to the cockpit. What do you do when the computer fails?? Eject! What a nice way to blow a billion dollars - software bugs can be expenisve huh? This type of flight design is becoming more and more common in aviation. As a pilot - it scares me to death. So all you hackers out there - DEBUG! A lot! If you don't - you could end up killing someone, like me.
Planes don't "crash" anymore. Now they "blue screen."
Milo
What about adding force feedback to the pilot's controls, to try and simulate what the pilot would feel if the computer wasn't there? I believe that something like that was done with the CF-105 here in Canada (a long time ago).
--
www.scorbett.ca
Actually in my early days I wrote a program that let you choose between saying "Hello World" and "Goodbye World". It had NO BUGS!
Remember, every program can be shortened by at least one line, and every program has at least one bug. So by induction, all programs reduce to one line of code that doesn't work.
IMHO OOP will one of the leading contributors to errors in safety oriented software that's used in advanced hardware-- my reasoning being that most OOP software (like Borland Pascal or Borland C++, for example) use VMT that are basically just pointers to functions that correspond to virtual functions or static functions. One poorly used pointer or overwritten memory address and suddenly you're calling the wrong code.
Sure, memory protection afforded by protected mode (on Intel processors, anyway, others have their own 'protection') can help safeguard some of the data used by classes in OOP, but AFAIK most of these embedded products most likely use nothing more advanced than an 8086 or 80186 (really, how much processor power is needed to control rotors and other externally embedded devices?).
But more to the point again, I think it's only a matter of time before bugs like these are fixed and dealt with, it's just too bad it has to lead to the loss of human life before they're found.
All I know about Bush is I had a good job when Clinton was president.
The cost of developing verifiably bug-free software is not justifiable in some situations. The use of the word many is a value judgement that is at best subjective.
NASA, for example, can ill afford buggy software.
Medical centers and hospitals can ill afford buggy software.
The Army and armed services can ill afford buggy software.
Now the real question is, can the average user afford buggy software?
I dunno, I would much prefer no bugs to bugs. How much would I pay for that?
I don't know.
Geek dating!
GPL Deconstructed
It seems that 99% of the people that come here are bandwagon jumpers with no formal background in C.S. That's fine, however, I am sick and tired of these eejits passing off ill-thought out speculation as fact. I remember a while ago there was a poll on "your favorite algorithm's complexity o(n^2), o (log n) etc. 90% of the nitwit Slahsdot readers thought that the complexity term was the algorithm itself. Anyway, to the issue at hand. Yes, of course it is provably possible to create bug free alorithms of great complexity for a subset of problems. For critical systems key components are designed using formal methods. When the behaviour of a system is not formally provable, a useful approach is that of the "clean room" - give the same spec to several isolated groups of programmers and combine the output of the redundant systems using a heuristic, for example, majority voting.
The Corps wanted the Osprey to replace the aging, complex CH-47 Chinook (Boeing Vertol to the civilian market), as well as the -46. The Chinook has had plenty of problems with its twin rotors, even though it's a "conventional" helicopter.
The V-22 has twice the speed and twice the capacity. Anyone who thinks 4 crashes makes a "deathtrap" is ignorant of the history of aircraft systems development (c.f. Martin B-26, Boeing B-29, Convair F-102, General Dynamics F-111, Harrier, etc.).
Maj. Kong
--
Shoot, a fella' could have a pretty good weekend in Vegas with all that stuff.
I almost clicked on that link wen I realised I was cruising at -1 mode. Tee-hee!
I'm too sexy for you.
Ugh, when the reset button on a computer doesn't work right, you KNOW there's a big problem. And I thought ATX was bad enough with the delayed power-off.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
...Windows bashing begin!!!
Back in early 90's I worked for a defense contractor that was involved with the testing of the V22's engines. I remember sitting in a meeting and looking at some of the mechanical drawings and saying to myself, "glad I'm not the test pilot". It is a very complicated design. Most military aircraft like the V22 have quadruple redundant electronic systems and even the engine ECUs will talk to each other and monitor the one that is currently in charge and if the others determine that the main ECU is malfunctioning the other three will vote to remove it. Very complicated algorithms. Also to maintain that both rotors have power with one engine failing a high speed drive shaft is used to transfer power from the good engine to the transmission on the side that lost power. The drive shaft has a very small diameter but would spin at something like 10,000 rpms. Low torque but high power. The designers are thinking about safety and I think this bird can work its just not being funded with the enthusiasm of the old cold-war projects.
I have yet to call a piece of software complete if it does have a bug in it. Really! Now, I know that certain megalithic sofware companies might not share these values, but I guess I just work harder than they do.
So I really don't think it's fair to blame too much technology here. Maybe the developers. No matter how you look at it, though, it bears remembering that real people died here, which is tragic indeed.
political_news.c: warning: comparison is always true due to limited range of data type
Yeah, you remember the first completely Fly-By-Wire plane? Something called the B2 stealth bomber? We all know how horrible it is. We would be sooooo much better off if we didn't have fly-by-wire and we wouldn't have to put up with planes like the B2 at all.
My initial training at Mother Rucker was in the TH-55, a completely mechanical linkage aircraft. I performed well above average, according to the daily grades and the final checkride grades. Next came the Contact phase of training in the Huey, with hydraulics. On the day when my despondent instructor was ready to finally throw in the towel, convinced that I had never seen an aircraft before, he looks at me and says "You don't seem to have the faintest idea what the aircraft is doing at any moment, you are just chasing it around...".
Determined to try and keep me on syllabus, in case I ever got a clue before I washed out, on the next idiot lap around the stagefield, he started the training for a hydraulics failure. We went through the procedure, including turning the hyrdraulics off... and wow... all of a sudden I could feel the blades again... I started making little circles with the cyclic...adjusting the cyclic... just to prove to myself that I knew what the aircraft was doing.
I made my best approach and landing to that point. The IP looks over at me with this look of "Eureka!" and says "Pick it up to a hover...".
Forty-five minutes of glorious hydraulics off training later, I'm soaked in sweat, with a grin that is only exceeded by the one on my instructor's face. It took a while to feel what hydraulics was dampening, but I made it through.
The Blackhawk (known in the 80s to most Army Aviators as the Crashhawk) hides it even more. I've never flown the V-22, but I do have some time in Bell's simulator, which I am told is very accurate. Couldn't feel a thing about the blades, I'm glad it was the simulator. That aside, I'd go back to Active Duty if they'd promise me the Osprey.
Dave
In all honesty, I think the idea of open-source military aircraft control software is rediculous. Granted, if the software was open-source, you could probably get fixes for bad code syntax, but probably not for slight physics miscalculations unless PhDs enjoy debugging military code in their spare time (the Osprey's thrust vectoring is enormously complex). Also, it would make me uneasy to think that the rival nations of the United States would have access to the software that controls our most sophisticated aircraft. The control software in our aircraft is part of the reason they are superior to most others in the world. I'm not going to get into the politics of saying the U.S. is or should be the biggest and baddest and not share its military technology. But just remember, that there ARE nations that do not favor the United States for whatever reasons that I'm not going to discuss. With that thought, as a citizen of the United States, do you want those nations having access to the technology that gives our aircraft an edge over our enemies'? War is a horrible thing, but is sometimes warranted to protect the lives of those who wish to live peacefully. I hope you will try to see things from my perspective. Eoin Finn PLC, United States Marine Corps
#include int perfection(const int &original, int divisor, int i) { divisor--; if(divisor > 0) i=perfection(original,divisor,i); if(divisor>0) if(original%divisor==0) i+=divisor; return(i); } void main(){ int original,divisor,i,b=0; original = 1; do{original++; divisor = original; i = perfection(original, divisor, b); if(i==original)coutiendl; }while(original 8129); }
Douglas Adams
1952-2001 :(
And /. screws up the formatting.. It thinks iostream is HTML! Blame me for not previewing.
Douglas Adams
1952-2001 :(
I'm a marine avionicsman stationed at mcas new river, home of the osprey. I've seen theh quality of the software that comes out of china lake (our test site) and it's usually a pain in the ass to get new systems up and running with the basic software used on the huey's and cobra's that I work with. I dare not imagine the crap that the avi guys have to put up with in a "glass cockpit" integrated software package. eeugh. add to that the idea's of working with an airframe that NOONE has experience with, from the pfc's to the gunnery sergeants, and it sounds like a recipie for disaster. And on a side note, I saw an osprey up close in a hanger on base the other day when I went to the battery locker, and I'm amased the things even get off the ground, weather they stay that way or not.
All production software of any complexity can be rewritten to be one line shorter.
All production software of any complexity has at least one bug.
By iterating the two statements, we reach the conclusion that all production software of any complexity can be reduced to one line of code, that has a bug in it.
Maybe so, but since they haven't got any new helicopters since the Blackhawk (30 years old?), they do really need the Osprey now.
I did mix up the dates a bit. It's at least 20 years since the first Blackhawk protos flew, and over 15 since they started using them -- however it wasn't flying right until 1988 or so, and I know that because I was peripherally involved in a critical avionics fix. The tail-plane was electronically controlled, the cable to that controller wasn't adequately shielded and filtered, and radio signals in the military voice band could be picked up and jam the tail-plane controller to full nose-down. In the typical Blackhawk mission, it would be at 100 foot or so above ground, and so it was almost impossible for the pilot to pull it out -- and difficult afterwards to tell whether something malfunctioned or the pilot just misestimated wind and trees... There were a number of crashes before the Army would admit there was a problem. I think a system I was working on in 1987 forced them to fix it -- it included a transmitter powerful enough to would drive the chopper full nosedown every time, and because it was usually fired up at 5,000 feet there was time to turn off the transmitter and recover control, so the pilots got back alive to report. And there is nothing angrier than a pilot whose aircraft just tried to kill him...
You wouldn't hire a 24-year-old architect to design a million-dollar building. But experienced architects are using software written by 24-year-old programmers to design million dollar buildings.
The quote isn't mine, but I don't recall where I saw it.
The Osprey has always been considered a boondogle from the get go
Not by those who badly need it's capabilities. Nor by those with airframes desperately in need of replacement.
Only by those politicians who don't have part of it in their districts.
Personally it sounds to me like the marines are just trying to cover-up the larger problems with this aircraft. As I'm sure all of you know, this aircraft has been under attack my many prominent people in the aviation industry as being unsafe and not suitable to fly. The marines have, of course, vehemently denied all these charges to conceal the fact that they have wasted millions of taxpayer's dollars to develop an unsafe aircraft. The problem is, while I support the armed services and their funding of projects like this, I do not support blaming some poor programmer for a crash of what is a know to be unsafe aircraft. It's like building a boat with holes in the bottom and then blaming the engine manufacturer when in sinks.
Keep Austin Weird!
We need a better model or computers will remain the elusive and vile creatures that, to the masses, they are...
you think it's easy, but you're wrong...
In the "software engineering" realm (and I use that term loosely), who gets blamed? Are individual coders going to start taking the fall for software that blows up (literally)? Where might this lead?
All of a sudden, I'm glad I'm one of the good coders... :)
Ryan T. Sammartino
Ryan T. Sammartino
"Ancora imparo"
Atomic Energy of Canada, Ltd. (AECL) built a medical radiation device called the THERAC that had a major software bug in it that killed at least three people. If the operator hit the keys on the keyboard in the wrong sequence, the machine would deliver 1,000,000 times the dose displayed on the screen. Massive radiation poisoning, and the victims died in a few days. They finally traced the problem to a coding error made by a contractor.
This, of course, is a massive over-simplification of the problem. The full story can be found here
-----------------
www.lucernesys.comHorizon: Calendar-based personal finance
newbie
it's time to progress to the next level
{ //Rant
Sigh... There was a time when artists had to know a substantial amount of geometry, anatomy color theory and even history to be considered worthy of the title. Art was considered the height of discipline, not some random spasms put on display.
And no, I'm not against modernism, or certain things called postmodern. I just have standards, deconstruct them at your own peril.
} //Rant
"Hardly used" will not fetch you a better price for your brain.
Software Problem Linked to Osprey Crash
I read this and instantly think of the Osprey pilot, playing Solitare on the WinNT box running the system when all of a sudden in blue screens. =)
1. The Osprey has three hydraulic systems that control properller pitch. Any one should be able to provide adequate control in case the other two fail.
2. The three systems are not completely independent - in some places they share lines with one of the other systems.
3. In the report - they found that the ruptured line cauesd a complete failure in one of the systems - a second system was compromised but an isolation valve cut it off so that it would not leak - but the isolation valve activation meant that this particular hydraulic system was no longer providing power to control prop pitch in one of the engines. So, one of the props pitch controls is getting powered by two systems, the other only by one.
4. When the pilot pressed the reset button, the computer attempted to change prop pitch - the software did not account for the fact that the isolation valve caused more power to change the pitch of the props in one of the engines than in the other - so the props changed pitch at uneven rates - this is very bad since one prop is now generating more thrust than the other - this asymetrical thrust caused unwanted yawing of the aircraft - whatever the computer did to correct this unwanted yawing didn't help - but this also probably included changing the pitch of the props some more which likely compounded the problem.
Understanding is a three edged sword. - Ambassador Kosh Naranek, Babylon 5
Incidentally, I've seen a buggy "Hello World" program before.
Error 404 - Sig Not Found
Oh sure!
Lots....during my tenure as lab tech I saw lots of C and Fortran problems with no bugs. But to get there I saw CS majors working 40 hours a week on them, some code only 75 lines long!
You CAN get bugless code! But, you have to put solid code as top priority, over the deadlines, over the bottom line. You aren't going to see much in corporate and even scientific america because the deadline has become the all important factor.
Also, the fewer people who work on the code the better. I believe the best set up is tandem coding, two people working together and checking each other. More than that and you get committees designing giraffes.
Looking into The Mythical Man Month by Fred Brooks and Refactoring by Martin Fowler for ideas on how to better your code.
"Are these questions testing whether I'm a replicant or a lesbian, Mr. Deckard?" -Rachael Tyrell