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/06/03 Message-ID: <31B2C140.7A29@lmtas.lmco.com>#1/1 X-Deja-AN: 158245420 references: <63085717wnr@diphi.demon.co.uk> <31AC0712.29DF@lmtas.lmco.com> <292872602wnr@diphi.demon.co.uk> <31AEC06C.1EB@lmtas.lmco.com> <845806664wnr@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-06-03T00:00:00+00:00 List-Id: JP Thornley wrote: > > I have no problem in agreeing with any of this, and would expect to see > appropriate safeguards such as these and others being built into the > software, but all of these techniques create system level behaviours... Actually, it depends on your definition of "system behavior." Depending upon the nature of the system, some of these recovery techniques may be performed without a change in the externally visible state of the system. Granted, this is not usually the case for real-time systems, but it is possible. Nonetheless, I concur that they should be specified at the appropriate requirements level. > A factor that has not been mentioned yet is traceability, and I had > rather assumed that everyone else was in a situation where every feature > of the software is required to be traceable to a software requirement. > So a correct (in my terms) implementation would also include the safe > (in your terms) features that you are both asking for. However, at the system level, the requirement may be very generic (e.g. "the system will attempt to recover from invalid states,") while the specific means used to do this (kernel mode, etc.) may be left to design. For the system to be fully analyzed (e.g. in terms of MIL-STD-882B), the design and implementation must also be considered. There is also considerable leeway in the implementation, given such a generic requirement. > FMET is a new one on me (?Failure Modes Effect Testing??). If that > guess is right then I must admit to feeling uneasy about the ability > of anyone to test thoroughly for all the effects of various wierd > failures. Failures Modes Effects Testing looks at the system effect of various failures and combinations of failures. While FMET is generally limited to a fixed number of combinations, it is different from (and complementary with) requirements-oriented testing in that it does not use requirements as a driver - only a list of system inputs, and sufficient architectual information to determine which failure modes are possible. Each system reaction to a failure mode is independently evaluated as to its "reasonableness," particularly from a safety standpoint. Although FMET is not a guarantee as to safety (for that matter, nothing is), we've found it to be a useful tool in safety evaluations. -- LMTAS - "Our Brand Means Quality"