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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: "Marin David Condic, 561.796.8997, M/S 731-96" Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/21 Message-ID: <97072111025086@psavax.pwfl.com>#1/1 X-Deja-AN: 258004994 Sender: Ada programming language Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU X-Vms-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" Newsgroups: comp.lang.ada X-Vms-Cc: CONDIC Date: 1997-07-21T00:00:00+00:00 List-Id: Ken Garlington writes: >> Depends on the application. Generally they print an error report, dump >> stack information to a file, and ask the user to phone the vendor. Note >> that I am not proposing this for real-time embedded applications. However >> there are safety-critical applications which are not real-time. > >True. Furthermore, there are safety-critical real-time applications that >are not required to be fail-operational. In both cases, I can at least >see >the glimmer of hope that assertions might have some value. (However, >even >a non-real-time system monitoring a nuclear power plant, for example, >might >not want to print out a message saying "phone the vendor, and I hope the >reactor doesn't go supercritical while you're on hold :) > >However, for _at least_ certain classes of safety-critical systems, this >behavior is completely unacceptable. Unfortunately, most people who >advocate >liberal use of exceptions are working on systems where it is quite >acceptable. > Well, here's one way of dealing with exceptions in a real-time safety critical application: If you have a control loop executing code, say, every 5mSec, sensing some inputs and doing some loop closure, you know by the rules of Ada that there are some exception possibilities you can't disable. Hence they could be raised by code beyond your control. You insert an exception handler in the loop to catch any of these, possibly logging them for telemetry (or at least ticking off a counter somewhere so you know it happened in lab testing!) then allow the loop to restart. What you're saying is this: "On pass N everything was fine. On pass N+1, something went haywire and interrupted normal execution. Because quitting operation is not an acceptable alternative, what I'm betting on is that on pass N+2, the problem will clear itself." This would potentially give you a viable use for raising exceptions on the fly. Granted, you wouldn't do this for any sort of expected conditions with planned for accommodations, but strictly for those sorts of errors that should never occur, but might just do so anyway. Your accommodation at that point might be something like resetting all of memory to its initial state and hoping that the next batch of inputs gets you back to where you should be. MDC Marin David Condic, Senior Computer Engineer ATT: 561.796.8997 Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600 Fax: 561.796.4669 West Palm Beach, FL, 33410-9600 Internet: CONDICMA@PWFL.COM =============================================================================== "You spend a billion here and a billion there. Sooner or later it adds up to real money." -- Everett Dirksen ===============================================================================