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

From: jean-louis Boulanger < >
Date: Tue, 24 Sep 2013 12:03:33 +0200


2013/9/24 SPRIGGS, John J <John.SPRIGGS_at_xxxxxx

> > 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.
>

Yes some people or company are wrong, the SIL alone is not the top level safety req but the SIL is related to some fear event and to some safety analysis ...

But from customer/client relation, the client can request a SIL for the product. In case of sub-contract the main customer can request a specific SIL for the equipment and/or for the product .... but normally the main requirement should be : some safety requirement some THR, some fear event and a proposition of SIL and during the study the sub-contractor need to identify the SIL and verify that it's the same that input SIL

If your have a SIL objective you have some safety requirement link to some risk

> ****
>
> 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.
>

Just a joke. I discuss with a ch... company and the question is :  If you assess SIL2 the product my company developed, do you give me a certificate that say "all the product my company will develop are SIL2"

> ****
>
> ** **
>
> *From:* systemsafety-bounces_at_xxxxxx > systemsafety-bounces_at_xxxxxx > Jens
> *Sent:* 24 September 2013 10:28
> *To:* systemsafety_at_xxxxxx > *Cc:* vincenzo.deflorio_at_xxxxxx > *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_xxxxxx > [mailto:systemsafety-bounces_at_xxxxxx > von *Vincenzo De Florio
> *Gesendet:* Freitag, 13. September 2013 12:45
> *An:* systemsafety_at_xxxxxx > *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_xxxxxx > (T) +32 3 265 3905 (F) +32
> 3 265 3777
> (Twitter) https://twitter.com/EnzoDeFlorio
> (_at_xxxxxx > (Gtalk) vincenzo.deflorio (WWW) www.pats.ua.ac.be/vincenzo.deflorio ***
> *
>
> ** **
>
> ** **
>
>
> ------------------------------
> If you are not the intended recipient, please notify our Help Desk at
> Email Information.Solutions_at_xxxxxx > 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.
> ------------------------------
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx >
>

-- 
Mr Jean-louis Boulanger



_______________________________________________ The System Safety Mailing List systemsafety_at_xxxxxx
Received on Tue Sep 24 2013 - 12:07:22 CEST

This archive was generated by hypermail 2.3.0 : Wed Feb 20 2019 - 20:17:05 CET