Re: Need help with PowerPC/Ada and realtime tasking

[Ken Garlington <garlingtonke@lmtas.lmco.com>]

JP Thornley wrote:
> 
> But I am talking only about those software components of the system that
> have been rated as safety-critical - so, by definition, a failure of
> that component to meet its requirements creates an uncontrolled risk of
> a hazard occuring.  I would be surprised if the exact shade of green
> on a display were to be rated safety-critical.  (I suspect that it is
> unusual for any part of a display to be rated as safety-critical as
> there will always be multiple independent sources of information).

Keen! A discussion of software safety in an Ada conference! :)

Actually, I have seen displays rated safety-critical, even in the presence
of multiple sources of information. For example, if a head-up display
shows critical flight information, the HUD might be safety-critical even
in the presence of backup displays, since the pilot may be in a regime where
reference to head-down information is impractical. There may also be a safety
risk if the pilot is presented with conflicting data from multiple displays
(one correct, one failed).

> Clearly it is a software engineering responsibility to check the
> requirements for incompleteness and ambiguity but, for example, if an
> algorithm is specified incorrectly and this results in a valve opening
> instead of it remaining closed, I do not see what is gained by claiming
> that the software which implements that algorithm is unsafe.  As another
> way of looking at this, what actions can a software engineer take to
> create safe sofware from potentially incorrect requirements (apart from
> being a better domain expert than the systems engineer and getting the
> requirements changed).

The claim Dr. Levison makes in "Safeware" is that the protection is provided
by having independent hardware fail-safes for safety-critical software. For
example, in the Therac-25 example, having a hardware device that shuts down
the beam automatically after a fixed time limit. The fail-safe doesn't have
to duplicate the function of the software; it just has to provide a minimal
shutdown capacity. I still haven't figured out a practical way to do this for
my system, but I'm sure it's a good idea for certain systems. At least
in my environment, the software engineer provides feedback to the domain
engineer, so I suppose it is a software engineering job to get requirements
changed, suggest additional safety features, etc.

It sounds like the point has already been made, but it is also good to
remmeber that, technically, correctness and safety don't have to be related.
You can have correct software that is unsafe, and incorrect software that
is safe.

-- 
LMTAS - "Our Brand Means Quality"