[SystemSafety] Software Safety Requirements according to IEC 61508

[Matthew Squair]

Hi Peter,

I think that the 61508 statement regarding validation simply reflects a
prevalent world view. That view being, rightly or wrongly, that we do
accept that a set of tests at the end validate the safety properties. I'm
not saying this is a good thing, just reflecting that this is the way we
behave.

>From a Bayesian perspective, for this behaviour to be rational we would
need to start with a very high prior probability (belief) that our system
under test delivers the safety function and associated properties. So yes
validating through testing is rational, as long as we have that extreme
level of confidence. Or alternatively it appears rational as long as we
don't question too closely why we should hold such a strong prior belief in
the first place.

Regards,



On Sat, May 21, 2016 at 5:56 PM, Peter Bernard Ladkin <
ladkin at rvs.uni-bielefeld.de> wrote:

> Being as I'm on the Maintenance Team, I thought it was about time that I
> figured out what software
> safety requirements are, according to IEC 61508. It took me a few hours. I
> thought I'd share the
> derivation to save others the effort.
>
> The answer is that they are a given reliability with which safety
> functions are executed, expressed
> to a given confidence.
>
> For those not familiar with the way safety is construed in IEC 61508,
> there is stuff being done in
> an engineered system, called the Equipment Under Control (or EUC). The EUC
> does stuff, which might
> result in harm (either because the actions undertaken can be dangerous, or
> because failure behaviour
> might be dangerous, or both). So a robot arm mucking around doing its
> thing might take your head
> off. Or a pipe containing superheated liquids might burst and boil
> everything in its vicinity.
>
> So there are risks (defined in the usual way). Somewhere magically from
> outside the system comes a
> specification as to what are acceptable risks. If all of the risks posed
> by the EUC are acceptable,
> there is nothing extra to be done. If some of the risks posed by the EUC
> are inacceptable, then
> so-called safety functions must be implemented, which reduce those risks
> (per risk, through
> mitigation or avoidance) to a level deemed acceptable. So a sensor is
> placed in the vicinity of the
> robot which will shut the robot off if a person is detected in the
> vicinity (a "virtual cage").
> Cladding (with an expansion space) is added around the pipe which may
> burst.
>
> It's a very industrial-process-oriented conception. But it's been tweaked
> enough to be deemed to be
> generally applicable. But some things which you think should be up-front
> and center aren't. Like
> what a software safety requirements specification is.
>
> Here is the answer as an attached paper. The meat is in the first section
> of about 2pp, the
> "Analytical Table of Contents", which consists of my observations from
> textual investigation. The
> rest consists of those observations taken individually, along with the
> citations from IEC 61508
> which constitute the proof. So if you just want to know the answer to the
> question "what is a
> software safety requirements specification?" then the first section will
> give that.
>
> I am distributing it this way because I can't get at our RVS WWW server at
> the moment. I'll be able
> to at some point over this weekend. We are in the process of rehosting our
> WWW pages with a
> commercial provider (they are already up at rvs-bi.de).
>
> PBL
>
> Prof. Peter Bernard Ladkin, Faculty of Technology, University of
> Bielefeld, 33594 Bielefeld, Germany
> Je suis Charlie
> Tel+msg +49 (0)521 880 7319  www.rvs.uni-bielefeld.de
>
>
>
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>
>


-- 
*Matthew Squair*
BEng (Mech) MSysEng
MIEAust CPEng

Mob: +61 488770655
Email: MattSquair at gmail.com
Website: www.criticaluncertainties.com <http://criticaluncertainties.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160522/ad4cf918/attachment.html>