DO-178B, which regulates flight software certification in the US, has 5
levels of criticality, from level E (the software could fail and the
pilot wouldn't even need to be told) to level A (the software fails and
the pilot is part of a smoking hole in the ground). Fly-by-wire
systems, needless to say, are considered to be level A criticality.
I used to work for a guy who managed a team that wrote some fly-by-wire
software for a Saab jet fighter. That's not a civilian application, but
the level of testing and certification was equivalent to the DO-178
procedures. He had the "honor" of watching a video of the jet, with his
software, crashing at an airshow.
It turned out that it wasn't the fault of his team -- someone had given
them an incorrect specification, and that's what they tested to.
So it bears out your point, even though line for line you spend about
2500 times more effort and money on DO-178B level A rated code than you
do for code for a windows application.
That Saab fighter is the Grippen (originally known as the Jars 39). I
remember that crash very well. As I recall, during a landing sequence the
aircraft cart wheeled on it's wings and burst into flames. The cause was
determined to be an overly sensitive aircraft control system. The pilot
survived the crash.
Spent a lot of time on that application during the aircraft development
program. If you want to see a control system that will boggle your mind this
is one of them. Share a patent on the control system that puts an imaginary
line in the sky--Altitude and Mach No. and then modulates several engine
parameters (when left of that line) to prevent engine stall after it has
been commanded to decelerate to Idle. Single engine application so there are
a number of control system fail safe, backup modes.
As related to me it was the chief test pilot, either for Saab or for the
program, who had never flown the aircraft before and didn't listen
closely enough to the guy wha actually _had_ flown the thing when told
it was really sensitive on the controls. It went into pilot-induced
oscillations on the landing pattern -- they guy walked away with a
It's one of those "multiple failures" scenarios that so often result in
death & destruction -- the boss wants to fly even though he's not
checked out on the aircraft, the runway's short and surrounded by
viewing stands (did I say it was an airshow?), the guy who _had_ been
flying it knew about the control problem and gave warning, and finally
the controls themselves were set up to be very sensitive. The result?
Incidentally, the fellow who related this story was also responsible for
recoding the software with the new control laws that made the aircraft
less sensitive -- after that was changed the thing flew just fine.
As a side note, you can search on the Gee-Bee R1 & R2 racers from the
30's -- the air-race historians are divided on whether it's a mankiller
or the worlds best racer. The most balanced opinion I've seen on it
points out that all the air-race pilots believed that they had Really
Big Balls and wanted an aircraft that was maneuverable to the point of
instability. Whenever the aircraft builders caved in and delivered a
plane with an itty bitty tail and a rearward center of gravity the
resulting aircraft was an absolute world-beater until it fell out of the
sky -- so it's not just software.
A device designed by a team that I managed (20 years ago) caught fire, and
destroyed a major refinery, burning two people to death. Turned out to be
the fault of a bad hose fitting (and not on "our hose"), but I didn't sleep
for a few weeks afterward. It COULD HAVE BEEN the software.
This was for an application that knowone had really thought of a safety
critical. Since then, I see almost every piece of "industrial" code as
capable of killing a human being.
That was my question... and rest assured that project is not going to happen
unless and until we qualify it every which way possible.
The project proposal was originally hard rail guidance, but the organization
writing the spec. is one of those always reaching for new innovation and
AGV's actually pull as much, or more weight in a lot of applications... they
just don't lend themselves to operation in a foundry environment.
In this project I believe we'll probably end up with festooned break-away
control cabling,dead-reckoning and a accepted, fail safe bumper safety.
Wireless is just a little to extravagant for the benefits involved.
On Mon, 27 Dec 2004 15:30:03 GMT, "Hershel Roberson"
Similar experience: As the instrument tech at a new production
facility, I was on a wee-hours trouble call that required massaging
one line of PLC code in each of twelve units to fix the problem. At
the very moment (it seems) I completed the edit on the last unit, a
large fireball erupted in the production area. It was immediately
outside of the window in the office where I was sitting. Fortunately
no one was injured.
In the end, the investigation concluded the event had absolutely no
connection to my work. But the timing, and the fact that the systems I
was working on were loosely interfaced to flame control systems,
resulted in a few weeks of sleepless nights. Happened right before a
week long vacation, too.
I can see several places to put the pid loop in a simple remote controlled
car.... pid the steering position to the commanded angle, pid the speed to the
commanded speed, and finally, in autonomous mode, pid the position to the
As I've said before: In theory there's not difference between theory
and practice but in practice there is.
I'm testing my Google Posting access so I'm not sure where this will
pop up, if at all. I note there is no spell checking. That is going
to be tough.
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.