comp.lang.ada
 help / color / mirror / Atom feed
From: <pab49162@hotmail.com>
Subject: Re: V-22 Osprey and exception handling
Date: Sat, 7 Apr 2001 20:39:16 -0500
Date: 2001-04-07T20:39:16-05:00	[thread overview]
Message-ID: <djPz6.9$kb.47845@news1.i1.net> (raw)
In-Reply-To: e1Mz6.1876$WR.520125570@newssvr16.news.prodigy.com

After reviewing the briefing side on the primary flight control system (FCS)
software anomaly
(http://www.defenselink.mil/news/Apr2001/010405-D-6570C-003.jpg), I have a
couple comments I would like to share on this subject:

1.  In reviewing the information on the slide, I personally would disagree
that this was a "software" anomaly.  I strongly suspect that the software
operated exactly as the system requirement specified.  In other words, the
FCS software implemented the specified system-level design correctly.  The
root cause was most likely that the FCS requirements were incorrect and did
not correctly accommodate the hydraulics system first failure.

2. The use of  the term "reset" may be a little misleading to some people.
In most fly-by-wire flight control systems, the reset button (if it even
exists) does not do a "hard reset" such as the CTRL-ALT-DEL sequence on a
PC.  Rather, the reset signal is an input fed into various part of the
software to reset latched failures in the signal management voters/monitors
and to reset the control laws to some predetermined condition.

3. In most systems, the occurrence of such failures is accommodated by the
FCS design and does not constitute what I would consider to the appropriate
use of Ada's exception handling mechanism.  (In the design of a typical FCS
system, most of the effort is spent addressing the common "bad day"
scenarios in which there are one or more failures in the system.)  Normally,
I use exception handling for conditions that should "never" happen like
maybe a floating point overflow.  In an FCS, the accommodation of a
hydraulic failure does not fall into that category.

4. I would probably disagree with your comment "this breaks a pretty
impressive string of successes by the industry".  Over the last ten years or
so, there have been a fair number of incidents which were the direct result
of the errors in the system-level design of an air vehicle's flight control
system.  The ones that come immediately to mind include the crash of the
YF-22 prototype in 1992, the crash of the JAS-39 Gripen on flight 6 in 1989,
the crash of a second JAS-39 at an air show in 1993 and the crash of the
DarkStar unmanned aerial vehicle (UAV) on flight 2 in 1996.

As a final note, I should probably state that while I have 15+ years in
software development of fly-by-wire flight control systems for military
aircraft, I am not directly involved in the V-22 program.





  reply	other threads:[~2001-04-08  1:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-07 21:55 V-22 Osprey and exception handling Ken Garlington
2001-04-08  1:39 ` pab49162 [this message]
2001-04-08 14:45   ` Ken Garlington
2001-04-09 14:08     ` Ted Dennison
2001-04-10  1:24       ` Ken Garlington
2001-04-10 16:01         ` Ted Dennison
2001-04-12 13:06           ` Ken Garlington
2001-04-08 16:58   ` singlespeeder
2001-04-09  1:44     ` Ken Garlington
2001-04-10 20:04       ` V-22 Osprey and exception handling - warning very little ada content singlespeeder
2001-04-11  0:34         ` Ken Garlington
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox