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,59dddae4a1f01e1a X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: Need help with PowerPC/Ada and realtime tasking Date: 1996/05/31 Message-ID: <31AEC06C.1EB@lmtas.lmco.com>#1/1 X-Deja-AN: 157751530 references: <63085717wnr@diphi.demon.co.uk> <31AC0712.29DF@lmtas.lmco.com> <292872602wnr@diphi.demon.co.uk> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.01 (Macintosh; I; 68K) Date: 1996-05-31T00:00:00+00:00 List-Id: JP Thornley wrote: > If you demand a correct/safe implementation in code of a flight control > system from requirements that are incorrect/unsafe then what steps > would you take to achieve it? Actually, there are some things that can be _attempted_ at the implementation level, although your results may vary: 1. You can have the system stop processing when an unexpected event occurs, such as an Ada exception or a hardware interrupt. This assumes that denial of service is not a safety-critical event in itself, of course. 2. You can create a "kernel mode," representing a subset of the requirements that are absolutely necessary for safe operation. Using some means, such as an operator input, you can cause the system to stop processing all code not in the "kernel" when a fault is detected. This approach works on the theory that the code in the "kernel" is used frequently, and so have a lot of test and operational time. Conversely, the "non-kernel" code is used less frequently, and therefore might have a potentially higher risk of a fault (either due to code error or requirements error) than the "kernel." Clearly, the reversion to the "kernel" must be done in an orderly fashion, with appropriate operator feedback. 3. You can use checkpoint/rollback techniques to try to overcome input errors that were not adequately caught by the required input checking. I'm skeptical of this approach in a dynamic environment, but there's a lot of literature available on this type of technique. Personally, I think it's better to use failure modes and effects analysis on the requirements, and do FMET testing after development, than to depend on this stuff. However, some of this might work in some areas. -- LMTAS - "Our Brand Means Quality"