Re: [SystemSafety] Safety Cases

From: Peter Bishop < >
Date: Fri, 07 Feb 2014 16:18:43 +0000


I like the way you put that.

Genuine certainty is hard (impossible?) to achieve, but attempting to falsify your claims/goals or whatever and not succeeding can help to increase your confidence in the case.

This is the approach advocated by the UK nuclear regulators (ONR) where "independent confidence building measures" are required (separate from the supplier) which could in principle break the claim that the system is acceptable.

Peter Bishop
Adelard

Andrew Rae wrote:
> If I can slightly reframe from Martin's points, the real problem is
> asking these questions in the negative. If the system _didn't_ have the
> properties it needs, what activities or tests would be adequate to
> reveal the problems?
>
> Whenever there is a focus on providing evidence that something is true,
> this is antithetical to a proper search for evidence that contradicts.
> As Martin points out, most evidence is not fully adequate to show that
> properties are true. The best we can do is selecting evidence that would
> have a good chance of revealing that the properties were not true.
>
> (Note: not all safety activities are about evidence. Most of them are
> about getting the design right so that there _aren't_ safety problems
> that need to be revealed).
>
> Simple question for the list (not directly related to safety cases):
>
> How often have you seen a safety analysis that was:
> a) Conducted for a completed or near completed design
> b) Revealed that the design was insufficiently safe
> c) Resulted in the design being corrected in a way that addressed
> the revealed problem(s)
>
> Supplementary question:
> What was the activity?
>
> [Not so hidden motive for asking, just so the question doesn't look like
> a trap - I've seen a lot of QRA type analysis that meets (a), but the
> only times I've seen (b) and (c) follow on are when the analysis is
> reviewed, not when the analysis is conducted]
>
> Drew
>
>
>
>
> 1 What properties does the system need to have in order for it to be
> adequately dependable for its intended use? (and how do you know that
> these properties will be adequate?)
> 2 What evidence would be adequate to show that it had these properties?
> 3 It it practical to aquire that evidence and, if not, what is the
> strongest related property for which it would be practical to provide
> strong evidence that the property was true?
> 4 What are we going to do about the gap between 1 and 3?
>
> My system safety podcast: http://disastercast.co.uk
> My phone number: +44 (0) 7783 446 814
> University of York disclaimer:
> http://www.york.ac.uk/docs/disclaimer/email.htm
>
>
> On 7 February 2014 12:05, RICQUE Bertrand (SAGEM DEFENSE SECURITE)
>
> It seems to me that at the end of the reasoning, the standard xyz
> (e.g. IEC 61508) requests some work to be done available in
> documents (whatever the name). Standard xyz contains (strong)
> requirements on 1 and (weaker) requirements on 2 but at least
> requirements on the means and methods to achieve 1.____
>
> __ __
>
> It looks circular.____
>
> __ __
>
> In the understanding of stakeholders being compliant to standard xyz
> means not doing a lot of engineering stuff that is unfortunately
> explicit or implicit in the standard xyz. But most often they even
> never read it. This is also an explanation about the observed gap in
> the industry.____
>
> __ __
>
> Bertrand Ricque____
>
> Program Manager____
>
> Optronics and Defence Division____
>
> Sights Program____
>
> Mob : +33 6 87 47 84 64 <tel:%2B33%206%2087%2047%2084%2064>____
>
> Tel : +33 1 59 11 96 82 <tel:%2B33%201%2059%2011%2096%2082>____
>
>
> __ __
>
> __ __
>
> __ __
>
> *From:* systemsafety-bounces_at_xxxxxx > <mailto:systemsafety-bounces_at_xxxxxx > [mailto:systemsafety-bounces_at_xxxxxx > <mailto:systemsafety-bounces_at_xxxxxx > Behalf Of *Martyn Thomas
> *Sent:* Friday, February 07, 2014 12:16 PM
> *To:* systemsafety_at_xxxxxx > <mailto:systemsafety_at_xxxxxx > *Subject:* [SystemSafety] Safety Cases____
>
> __ __
>
> In the National Academies / CSTB Report /Software for Dependable
> Systems: Sufficient Evidence?/
> (http://sites.nationalacademies.org/cstb/CompletedProjects/CSTB_042247)
> we said that every claim about the properties of a software-based
> system that made it dependable in its intended application should be
> stated unambiguously, and that every such claim should be shown to
> be true through scientifically valid evidence that was made
> available for expert review.
>
> It seems to me that this was a reasonable position, but I recognise
> that it is a position that cannot be adopted by anyone whose
> livelihood depends on making claims for which thay have insufficient
> evidence (or for which no scientifically valid evidence /could/ be
> provided). Unfortunately, much of the safety-related systems
> industry is in this position (and the same is true, /mutatis
> mutandis/, for security).
>
> It seems to me that some important questions about dependability are
> these:
>
> 1 What properties does the system need to have in order for it to
> be adequately dependable for its intended use? (and how do you know
> that these properties will be adequate?)
> 2 What evidence would be adequate to show that it had these
> properties?
> 3 It it practical to aquire that evidence and, if not, what is
> the strongest related property for which it would be practical to
> provide strong evidence that the property was true?
> 4 What are we going to do about the gap between 1 and 3?
>
> The usual answer to 4 is "rely on having followed best practice, as
> described in Standard XYZ". That's an understandable position to
> take, for practical reasons, but I suggest that professional
> ingegrity requires that the (customer, regulator or other
> stakeholder) should be shown the chain of reasoning 1-4 (and the
> evidence for all the required properties for which strong evidence
> can be provided) and asked to acknowledge that this is good enough
> for their purposes.
>
> I don't care what you choose to call the document in which this
> information is given, so long as you don't cause confusion by
> overloading some name that the industry is using for something else.
>
> I might refer to the answers to question 1 as a "goal", if I were
> trying to be provocative.
>
> Martyn
>
>
>
> ____
>
> #
> " Ce courriel et les documents qui lui sont joints peuvent contenir
> des informations confidentielles, être soumis aux règlementations
> relatives au contrôle des exportations ou ayant un caractère privé.
> S'ils ne vous sont pas destinés, nous vous signalons qu'il est
> strictement interdit de les divulguer, de les reproduire ou d'en
> utiliser de quelque manière que ce soit le contenu. Toute
> exportation ou réexportation non autorisée est interdite.Si ce
> message vous a été transmis par erreur, merci d'en informer
> l'expéditeur et de supprimer immédiatement de votre système
> informatique ce courriel ainsi que tous les documents qui y sont
> attachés."
> ******
> " This e-mail and any attached documents may contain confidential or
> proprietary information and may be subject to export control laws
> and regulations. If you are not the intended recipient, you are
> notified that any dissemination, copying of this e-mail and any
> attachments thereto or use of their contents by any means whatsoever
> is strictly prohibited. Unauthorized export or re-export is
> prohibited. If you have received this e-mail in error, please advise
> the sender immediately and delete this e-mail and all attached
> documents from your computer system."
> #
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx > <mailto:systemsafety_at_xxxxxx >
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx

-- 

Peter Bishop
Chief Scientist
Adelard LLP
Exmouth House, 3-11 Pine Street, London,EC1R 0JH
http://www.adelard.com
Recep:  +44-(0)20-7832 5850
Direct: +44-(0)20-7832 5855
_______________________________________________
The System Safety Mailing List
systemsafety_at_xxxxxx
Received on Fri Feb 07 2014 - 17:18:53 CET

This archive was generated by hypermail 2.3.0 : Sun Feb 17 2019 - 20:17:06 CET