[SystemSafety] ARRL: A Criterion for Composable Safety and Systems Engineering

SPRIGGS, John J John.SPRIGGS at nats.co.uk
Tue Sep 24 11:42:16 CEST 2013


> A SIL level alone is not the top level safety requirement.
It is worrying how often I come across people who are focused on their integrity level or assurance level to the exclusion of all else.
Recently, for example, I was told by a supplier that they could not perform a required analysis because the "SWAL" they were using did not provide the data needed for it.  The data were available but not listed as required for assurance in the EUROCONTROL development lifecycle, so they could not use them for assurance...
I was not assured.

From: systemsafety-bounces at lists.techfak.uni-bielefeld.de [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Braband, Jens
Sent: 24 September 2013 10:28
To: systemsafety at techfak.uni-bielefeld.de
Cc: vincenzo.deflorio at ua.ac.be
Subject: Re: [SystemSafety] ARRL: A Criterion for Composable Safety and Systems Engineering

Thanks for sharing your preprint. I read it with great interest but IMHO it contains a lot of unfounded statements and also some obvious errors, of which I state only the most important here:


-          Table 1 is completely wrong. SIL does NOT correspond directly to consequence only. Part 5 of IEC 61508 shows different ways of SIL allocation, none of them corresponds to table 1. It is also wrong that SIL depends on average statistical values, see part also 5.

-          Also table 2 is oversimplified, e. g. neither does ASIL-D correspond completely to SIL 3 or DAL B nor does SIL 4 to DAL A

-          A SIL is not a system property, but relates to a safety function. A system may deliver many different functions, of which only a subset may be safety-relevant. E. g. a monocoded processor system may run safety and non-safety functions.

-          A SIL level alone is not the top level safety requirement. More important are the functional safety requirements

-          If a residual risk is low and its probability is high then its severity should also be low.  So where's the beef in your Murphy example?

-          No justification on the definition of ARRL and its relation to SIL is given. The "rule" is not justified

-          Quality cannot be equaled with reliability alone and even less with MTBF. Have a closer look into Nancy's books ...

Best regards

Jens Braband

PS These are my personal views and not necessarily that of my employer or other organizations that I sometimes represent.


Von: systemsafety-bounces at lists.techfak.uni-bielefeld.de<mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de> [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de]<mailto:[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de]> Im Auftrag von Vincenzo De Florio
Gesendet: Freitag, 13. September 2013 12:45
An: systemsafety at techfak.uni-bielefeld.de<mailto:systemsafety at techfak.uni-bielefeld.de>
Betreff: [SystemSafety] ARRL: A Criterion for Composable Safety and Systems Engineering

Dear Madams, dear Sirs,

I'd like to draw your attention to the following paper: "ARRL: A Criterion for Composable Safety and Systems Engineering", which will be presented at the SASSUR (Next Generation of System Assurance Approaches for Safety-Critical Systems) workshop<http://conf.laas.fr/SAFECOMP2013/?q=node/26> of SAFECOMP2013 on 24th September in Toulouse, France. The paper is authored by Eric Verhulst and Bernhard Sputh (Altreonic, Belgium), Jose Luis de la Vara (the Simula Research Lab, Norway), and Vincenzo De Florio (University of Antwerp, Belgium). The abstract is as follows:

"While safety engineering standards define rigorous and controllable
processes for system development, safety standards' differences in distinct
domains are non-negligible. This paper focuses in particular on the aviation,
automotive, and railway standards, all related to the transportation market.
Many are the reasons for the said differences, ranging from historical reasons,
heuristic and established practices, and legal frameworks, but also from the
psychological perception of the safety risks. In particular we argue that the
Safety Integrity Levels are not sufficient to be used as a top level requirement
for developing a safety-critical system. We argue that Quality of Service is a
more generic criterion that takes the trustworthiness as perceived by users better
into account. In addition, safety engineering standards provide very little
guidance on how to compose safe systems from components, while this is the
established engineering practice. In this paper we develop a novel concept
called Assured Reliability and Resilience Level as a criterion that takes the
industrial practice into account and show how it complements the Safety
Integrity Level concept."
Kind regards,
Vincenzo De Florio


--
Vincenzo De Florio
---------------------------------------------------------------------------------
PATS Research Group, University of Antwerp & iMinds Research Institute
Middelheimlaan 1, Building G, Room G1.11, B-2020 Antwerp
---------------------------------------------------------------------------------
New e-mail address:                       vincenzo.deflorio at uantwerpen.be<mailto:vincenzo.deflorio at uantwerpen.be>
(T) +32 3 265 3905                                               (F) +32 3 265 3777
(Twitter) https://twitter.com/EnzoDeFlorio                   (@EnzoDeFlorio)
(Gtalk) vincenzo.deflorio    (WWW) www.pats.ua.ac.be/vincenzo.deflorio<http://www.pats.ua.ac.be/vincenzo.deflorio>

***************************************************************************
If you are not the intended recipient, please notify our Help Desk at Email isproduction at nats.co.uk
immediately. You should not copy or use this email or attachment(s) for any purpose nor disclose
their contents to any other person.

NATS computer systems may be monitored and communications carried on them recorded, to 
secure the effective operation of the system.

Please note that neither NATS nor the sender accepts any responsibility for viruses or any losses
caused as a result of viruses and it is your responsibility to scan or otherwise check this email
and any attachments.

NATS means NATS (En Route) plc (company number: 4129273), NATS (Services) Ltd 
(company number 4129270), NATSNAV Ltd (company number: 4164590) 
or NATS Ltd (company number 3155567) or NATS Holdings Ltd (company number 4138218). 
All companies are registered in England and their registered office is at 4000 Parkway, 
Whiteley, Fareham, Hampshire, PO15 7FL.

***************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20130924/248b48ee/attachment-0001.html>


More information about the systemsafety mailing list