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.3 required=5.0 tests=BAYES_00, 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/05/25 Message-ID: <122916091wnr@diphi.demon.co.uk> X-Deja-AN: 156720871 x-nntp-posting-host: diphi.demon.co.uk references: <1026696wnr@diphi.demon.co.uk> 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-05-25T00:00:00+00:00 List-Id: Richard Riehle writes: > > On Sat, 18 May 1996, JP Thornley wrote: [in response to a question about a "life critical application" which has both interrupts and tasking] > > My first response is that safety-critical software does not go well > > with interrupts and the use of tasking. The main requirement of > > safety-critical code is predictability, which is made impossible if > > you are coping with unpredictable interrupts and with hard-to-analyse > > tasking syncronisations. > > I would like to offer a slightly different view of this. > [well argued case for tasking mostly snipped] Perhaps I am guilty of using the predictability argument to stand in for all the reasons for not using tasking in safety-critical code. So I'll describe some more here. Several studies into safety-critical subsets have all rejected tasking:- Safe Ada SPARK Ada High Integrity Ada Study (YSE/BAe) CSMART Ada so there is going to be a major credibility problem convincing a qualification authority to go along with tasking. Allow also for the relevant personnel from that authority to have an unknown level of mathematical and computer system literacy. (Furthermore, arguments which talk about high priority tasks being blocked by low priority tasks can be expected to bring on a severe fit of the vapours.) Tasks in the application require tasking run-time support. This will therefore need to be qualified to safety-critical standards (ie reasonable expectation of zero failures, see other post in this thread). Since I've never done it, I don't know what it would take in terms of effort, but it can't be anything other that a very major undertaking. I would guess that most of the tasking part of the run-time will be written in Ada - so will be required to either conform to the safety-critical subset in use or be re-written to that sub-set. Common restrictions include no access types and no heap usage - is this likely to be a problem? [One problem of working with small subsets is that you end up knowing nothing about the rest of the language, it's about six years since I last saw an Ada task anywhere other than a text-book or journal.] > A cyclic executive does not guarantee schedulability. It does not even > guarantee predictability. In fact, a cyclic executive can guarantee > that one actually fails to trap events as they occur. But safety-critical systems I'm talking about have *no* interrupts (see my original response - perhaps not sufficiently emphasised) so this argument does not apply. (Actually there is one - the timer that drives the minor cycle - and this has to be explicitly justified in the safety case.) > An additional problem with the cyclic executive model is ist lack of > portability. Since it is dependent on the timings of the platform to > which it is targeted, it can fail to meet its goals when ported to a > new platform. Agreed - any hardware or software change that affects the timing analysis means that you have to do it all again, and you may have to redesign the schedule. (But if it comes to a trade-off between safety and portability there's not much doubt as to which way I'd go.) There is a related issue that doesn't come up very often when discussing scheduling strategies, which is the accuracy of the worst-case execution times used in the analysis. Deriving these figures requires a major effort, with substantial error bounds on the resulting timings. I believe that the figures that I currently use are typically in the range 10%-30% pessimistic and I wouldn't be happy to use figures with a lower margin of error unless I can believe that their accuracy is improved. I can't get excited about more elaborate scheduling strategies to sqeeze another 5% out of the processor with safety margins like this (I'd sooner put it into more accurate timing figures). > .... Remember that I speak here of Ada 95 tasking. I was beginning to wonder whether I was the only reader of cla still using Ada 83 until there were some recent posts from others in the same situation in another thread. To put my situation more clearly, there is one safety-critical system going into system design later this year, first trails to be run in 1998 and delivery to the customer in 2000 onwards - this system will use Ada 83 as the Ada 95 compilers won't be usable in that timescale. [I feel yet another post coming on, about compiler validation for safety-critical code, but it's time to go and cut the grass before it rains again.] > Richard Riehle > Phil Thornley -- ------------------------------------------------------------------------ | JP Thornley EMail jpt@diphi.demon.co.uk | ------------------------------------------------------------------------