comp.lang.ada
 help / color / mirror / Atom feed
From: "Ken Garlington" <Ken.Garlington@computer.org>
Subject: Re: V-22 Osprey and exception handling
Date: Sun, 08 Apr 2001 14:45:17 GMT
Date: 2001-04-08T14:45:17+00:00	[thread overview]
Message-ID: <1Q_z6.474$VI4.153258056@newssvr10-int.news.prodigy.com> (raw)
In-Reply-To: djPz6.9$kb.47845@news1.i1.net

<pab49162@hotmail.com> wrote in message
news:djPz6.9$kb.47845@news1.i1.net...
: 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.

Well, it's an interesting argument as to whether this is a "requirement" or
"design" failure; it depends upon how the requirements are specified. Since
this is probably not a function described in the control laws, I suspect the
requirements description was fairly general. Speculating further, I would
guess that when the reset button was pressed, some failed value was fed back
into the system

: 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.

Actually, there can be levels of resets. For example, on the F-16, there is
a pilot reset which works somewhat as you describe (it removes one level of
latched failures, but does not send the control laws into fixed gains or
anything like that). There is also a "global reset" (not recommeded for
in-air use) that clears *all* latched failures. Finally, there is a DBU
switch that can be used similarly to a CTRL-ALT-DEL. It's not clear to me
which reset was involved here.

: 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.

I think my point was more along the lines that this is another case where a
function that was part of the failure handling requirements, actually
contributed to an accident instead.

So, what *do* you use in your Ada exception handlers, that adds more benefit
than risk?

: 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.

All of these (except perhaps for the second JAS-39 crash, and I was thinking
that that one also fell into this category) happened while the aircraft was
still in a flight test program. I specifically excluded those from my answer
("post-test" being my exact words). Furthermore, IIRC, none of these "led to
a fatality", as I also noted. For that matter, I wouldn't even count the
YF-22 prototype as a software fault, since it was operated outside its
defined envelope.

The V-22, however, was a low-rate initial production (LRIP) configuration
accepted for use in August 2000, according to the briefing. It was presumed
to be a fully-tested article.

: 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.

16+ and me neither.





  reply	other threads:[~2001-04-08 14:45 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
2001-04-08 14:45   ` Ken Garlington [this message]
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