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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: JP Thornley Subject: Re: Need help with PowerPC/Ada and realtime tasking Date: 1996/06/02 Message-ID: <845806664wnr@diphi.demon.co.uk>#1/1 X-Deja-AN: 158175634 x-nntp-posting-host: diphi.demon.co.uk references: <63085717wnr@diphi.demon.co.uk> <31AC0712.29DF@lmtas.lmco.com> <292872602wnr@diphi.demon.co.uk> <31AEC06C.1EB@lmtas.lmco.com> x-mail2news-path: disperse.demon.co.uk!post.demon.co.uk!diphi.demon.co.uk organization: None reply-to: jpt@diphi.demon.co.uk newsgroups: comp.lang.ada Date: 1996-06-02T00:00:00+00:00 List-Id: Ken Garlington writes: > 1. You can have the system stop processing when an unexpected event > occurs, ... > 2. You can create a "kernel mode," representing a subset of the > requirements that are absolutely necessary for safe operation. ... > 3. You can use checkpoint/rollback techniques ... > and Robert I. Eachus writes: > ...... I much prefer > the design philoshy that things can go wrong, and you do want sanity > checks in the software. 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 that cannot be defined solely by the software engineer - the resulting system states must be visible in the system description and an obvious place is the software requirements. If they are not in there as written then they should be introduced as the software implementation creates the need/opportunity to define them. One certain sure route to unsafe systems is allowing the software to create undocumented system states that have not featured in the system safety analysis. 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. Ken Garlington also writes: > Personally, I think it's better to use failure modes and effects > analysis on the requirements, Agree absolutely - so this stuff has to *be* in the requirements - > and do FMET testing after development, than to depend on this > stuff. 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. -- ------------------------------------------------------------------------ | JP Thornley EMail jpt@diphi.demon.co.uk | ------------------------------------------------------------------------