From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,FROM_WORDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,af986aa93b89733e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-08 07:46:08 PST Path: supernews.google.com!sn-xit-02!supernews.com!nntp-relay.ihug.net!ihug.co.nz!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!newscon06.news.prodigy.com!prodigy.com!newsmst01!postmaster.news.prodigy.com!newssvr10-int.news.prodigy.com.POSTED!not-for-mail From: "Ken Garlington" Newsgroups: comp.lang.ada References: Subject: Re: V-22 Osprey and exception handling Organization: ex-FlashNet, now Prodigy X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: <1Q_z6.474$VI4.153258056@newssvr10-int.news.prodigy.com> NNTP-Posting-Host: 65.67.100.44 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr10-int.news.prodigy.com 986741117 6207069 65.67.100.44 (Sun, 08 Apr 2001 10:45:17 EDT) NNTP-Posting-Date: Sun, 08 Apr 2001 10:45:17 EDT Date: Sun, 08 Apr 2001 14:45:17 GMT Xref: supernews.google.com comp.lang.ada:6645 Date: 2001-04-08T14:45:17+00:00 List-Id: 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.