Re: Need help with PowerPC/Ada and realtime tasking

[JP Thornley <jpt@diphi.demon.co.uk>]

Richard Riehle <rriehle@nunic.nu.edu> 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                           |
------------------------------------------------------------------------