Software Problem Linked to Osprey Crash 338
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"?"
[Not OT] That Shasldot banner ad... (Score:2)
"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?
Re:Previous versions (Score:2)
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
Re:Nuclear Powerplants, ICBM systems (Score:2)
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.)
Re:Proofs (Score:2)
I suppose it can be useful to formulate a program in a thoughtful, formalized system. But that's what good code is anyway, so...
Re:Good Software Exists (Score:3)
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.
Still hosed! Hash/pound character is not portable! (Score:2)
??=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).
Re:define "bug" (Score:2)
define "bug" (Score:4)
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. .
Not in this case ... (Score:2)
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
Re:Yes, goddamn it (Score:2)
--
Re:Yes, goddamn it (Score:2)
--
Yes, goddamn it (Score:4)
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.
--
Re:Return Value? n/t (Score:2)
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
Re:Return Value? n/t (Score:2)
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
Re:RTOS has to reboot? (Score:2)
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.
Re:Software (Score:2)
Re: (Score:2)
Re:Still bad. You forgot to check validity of stdo (Score:2)
Re:Hello World is buggy (Score:2)
Re:Design vs. coding (Score:2)
Re:Hello World is buggy (Score:3)
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);
}
In Knuth's defense (Score:5)
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"
This is why we need to stratify software. (Score:2)
#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.
Can't autorotate (Score:2)
--
Re:Can't autorotate (Score:2)
No, the articles I have read specifically said autorotate. It was my naive read-between-the-lines guess that maybe they meant the rotor diameter was so small for the weight that the autorotation speed would be so high as to make it effectively incapable of autorotation. Remember, the rotor diameter is artificially small for its weight because it has to be able to land on a carrier. Presumably they compensate for this by making them spin faster.
--
Re:Good Software Exists (Score:3)
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.
--
Re:Good Software Exists (Score:5)
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...
--
Re:I think it's expensive, not too expensive. (Score:3)
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.
Bugfree, hello world? (Score:2)
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...
Perfect software is too expensive (Score:3)
You try building something under that kind of methodology, and see what the cost to your productivity is.
Go you big red fire engine!
Not only that... (Score:3)
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.
Re:This is true (Score:2)
And you stayed on it? Of the four passengers to board that plane, we know which one isn't the smart one!
--Jim
Knuth! (Score:5)
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 [stanford.edu], under the heading "Rewards".
--Jim
Re:Return Value? n/t (Score:2)
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.
---
Fly-by-wire systems are very complicated (Score:3)
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.
most peoples posts are going to be about.. (Score:3)
---
Re:Bridges (Score:2)
5% of bugs are system bugs (Score:2)
Re:5% of bugs are system bugs (Score:2)
For example, I stumbled upon a socket bug in NT4. I can't just ignore this bug and pretend my software is correct because users expect my program's features to work on Windows 95, 98, NT4, and 2000. So now my code has a hack to workaround this NT4 bug. btw, the bug was that WSAEnumNetworkEvents() always returns with the FD_CONNECT bit set for sockets, even after my code already finished connecting the socket.
Life-critical versus money-critical code (Score:2)
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.
Software often gets in the way of piloting anyway (Score:3)
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.
Re:Good Software Exists (Score:5)
Medical Software (Score:2)
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!
----------------------
Even "Hello World!" not immune. (Score:2)
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.
I am going out on a limb here... (Score:3)
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 [worldcom.com] - Generation Duh!
Re:V22 (Score:2)
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.
Re:This is true (Score:2)
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...
Re:Finish the story (Score:2)
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.
This is true (Score:3)
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...
Re:Return Value? n/t (Score:2)
8. No return value from main specified.
Re:Holy shit (Score:2)
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!
Re:Cover-up (Score:2)
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!
Re:"one reason to fear too much technology" (Score:2)
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
Holy shit (Score:2)
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?
crack! goes the whip (Score:2)
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
Re:most peoples posts are going to be about.. (Score:2)
F) People who will say that the gov't should open-source the Osprey drivers, magically fixing all bugs in the code.
Can you believe this guy? (Score:2)
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.
Re:Why "Hello World"? (Score:2)
Re:In other news... (Score:2)
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.
NASA Software (Score:2)
That has a good article on how the programmers at NASA write their software. They're on budget and on time.
Bug Free (Score:3)
I once wrote a "Hello Universe" that I was fairly confident was relatively bug free.
Re:Software often gets in the way of piloting anyw (Score:2)
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.
Re:Perfect software is too expensive (Score:2)
I can think of a few reasons:
professionalism
responsibility/liability
methodical
standardized etc etc.
In another post, someone compared the two possible faults, design/implementation - i.e. a design fault would be the designer didn't specify enough rivets for the load, an implementation fault would be if not all the rivets that were listed in the design were installed.
I'm not sure how we can apply this idea to code, but if people's lives are on the line, we must find a way.
Re:"one reason to fear too much technology" (Score:2)
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. ;-)
"one reason to fear too much technology" (Score:3)
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.
Re:Crash (Score:2)
Only if they're landing in the water. On land it might be a black, grey, yellow, green, or white screen.
Good Software Exists (Score:4)
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.
Automation in piloting (Score:2)
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.
Re:Previous versions (Score:2)
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.
Proofs (Score:2)
Proving software correct shouldn't hold much weight. Testing is really the only way to go.
For instance, here [cdt.luth.se] 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.
bug exposed by mechanical failure... (Score:2)
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.
Re:bug exposed by mechanical failure... (Score:2)
doubt it, i worked on a project awhile ago -- had to interface to a bunch of data from a aircraft -- it was mostly ADA structures. they claimed it was 40 millions lines of code overall.
Microsoft and NASA are working on a project to autopilot aircraft through takeoff, cruise and landing -- with minimal interaction with the pilot.
It's called Highway In The Sky [nasa.gov]
Greatest Programming Joke ever (Score:5)
Is it possible??? (Score:2)
Re:OOP (Score:2)
Re:NASA Software (Score:2)
Finish the story (Score:2)
http://www.bootyproject.org [bootyproject.org]
Re:Crash (Score:2)
First they crash, then they crash again!
--
Re:I think it's expensive, not too expensive. (Score:2)
--
Re:This is true (Score:2)
When I was working on the Systems Requirements for the EELV [af.mil] program, I recall that the Ariane 5 [hud.ac.uk] struck us all with a horrific sense of dread. This dread comes about when you realize that, no matter how hard you try, you cannot simulate all conditions that software must function in and all situations that it must respond to. The SRS (Software Requirements Specification) tries to cover all the bases, but while you can specify environments for hardware (temperature, humidity, acceleration, vibration, etc...), you cannot often provide a spec for all that might happen to software. In the Ariane 5 case, they changed the hardware; I believe that they upgraded to a new main booster whose horizontal velocity capability exceeded that of the previous booster, but they decided to re-use the software from the old one. When the rocket started going sideways, the value exceeded the bounds and the s/w crashed. Ahhh, here [eiffel.com].
I am writing this for a reason: Engineers and software developers often scoff at requirements, preferring to design rather than focus on What they are Designing To. Without a proper SRS, you really don't know if you've covered all bases. Even with one you don't.
But this stuff ain't web pages, man, it's Serious Stuff! And a big portion of the budget needs to go into Requirements Development, at least 25% (actually I once read that the Japanese put 40% into up-front requirements and conceptualization, thus eating our lunch in the automotive industry).
What you don't spend in up-front requirements development you spend in test and verification. What you don't spend in either, well, you spend that in environmental clean-up, insurance costs, and lives.
Sounds like the Osprey folks should have paid a little more attention to their SRA (Systems Requirements Analysis).
Incidentally, while I Understand the massive cost savings (up front!) available through Object Oriented Systems Analysis (emphasis on reuse!), remember that there are no easy shortcuts, and be aware of the dangers inherent in cutting and pasting!
Re:RTOS has to reboot? (Score:2)
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.
You are happy to sit back and say "You try to write a program so it boots up and takes control of an on-going process without glitches", defending the team that designed the software. Yet you question the pilot's intelligence for following his procedures during a few split-second moments of time.
It's a shame that young Marines and aircrew need to die because overpaid 'engineers' who fuck up the design of systems sit back and collect their consulting fees. If a civil engineer designed a bridge which collapsed under the weight of passenger traffic, he would lose his license and possibly face criminal charges. Software 'engineers' get to continue the project and collect more fees.
Re:Why "Hello World"? (Score:2)
Very good! That has a very high density of bugs, I would say. I count at least 5 bugs in that code (4 if it's pre-ANSI C):
1. "void" rather than "int" on main.
2. Need to include "stdio.h".
3. Invalid declaration of main (which is not illegal in pre-ANSI C)
4. Use of "\r" rather than "\n".
5. Need to return a status code.
Any bugs that I missed? Any way to get an even higher bug density (while still displaying "Hello World")?
I guess you could do 'puts("Hello World\r")', which not only has the "\r" rather than "\n", but is also redundant! That counts as another bug in my book.
--
Re:Hello World is buggy (Score:2)
Er, 'printf' doesn't return a status, it returns the number of characters printed. You don't need to check it.
--
Re:Still hosed! Hash/pound character is not portab (Score:2)
But you're assuming that we, as Americans, care about internationalization issues. [RM101 ducks, as the truth of this strikes too close to home...] :)
--
Buggy software (Score:3)
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. :)
--
Re:Good Software Exists (Score:2)
Re:Good Software Exists (Score:3)
CMM [cmu.edu]
Yes! (Score:3)
your tax dollars at work (Score:2)
Crash (Score:3)
Re:Why "Hello World"? (Score:3)
Jeez, some people!
Re:Good Software Exists (Score:2)
http://shop.barnesandnoble.com/textbooks/bookse
Re:Good Software Exists (Score:2)
sorry, link [barnesandnoble.com]
Re:hello world (Score:2)
This is why I shudder when I think about these same companies rewriting the air traffic control system. Yes, it has to be done, but I worry that some people are going to be unwittingly involved in some "real world testing."
Re:RTOS has to reboot? (Score:2)
No human being is panic-proof when falling from the sky. You can train 'em all you want, and they will do as their told, but they still get scared.
Re:RTOS has to reboot? (Score:2)
I think it's expensive, not too expensive. (Score:2)
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! [bunnyhop.com]
V22 (Score:5)
Re:RTOS has to reboot? (Score:4)
As I see it (and I'm not claiming expertise), the problems were, in descending order of importance:
1. The designers failed to route and fasten hydraulic lines so they wouldn't chafe.
2. The Marine Corps and aircraft mfg both ignored warnings about chafing lines.
3. The system for some reason told the pilot he needed to reset the computers although the computer had nothing to do with the hydraulics failure.
4. The software changed propellor settings erratically while booting up.
5. They didn't give the pilot an effective manual override for any controls the computer might be messing up.
6. The pilot panicked a little. Understandable, but pilots and Marines are supposed to be panic-proof...
Anyone else remember the THERAC? (Score:3)
This, of course, is a massive over-simplification of the problem. The full story can be found here [vt.edu]
-----------------