Re: "Safety is a system property"

Paul Albertella

Hi Elana,

On 15/02/2021 15:03, Elana Copperman wrote:
/>> Safety experts cannot define the core of their art?  Isn't there some accepted definition for the most basic terminology ("safe")?/
Safety experts have *plenty* of definitions: the problem is that they don't all agree, and the rest of us have a frustrating tendency to use those terms to mean something subtly (but crucially) different!

/>> Deleting the word safe is just avoiding the problem./
As I understand it, Lukas is not saying that we should just delete the word safe; he is noting that, by arbitrarily applying the 'safe' label to things, we can cause confusion and misunderstandings.

There is no such thing as safe software (or systems), but it is possible to use and develop them with safety in mind, provided that we define what 'unsafe' means in our considered context.

Labelling specific features or characteristics of software (or hardware, tools, or systems) as 'safe' can be counter-productive, because it implies that they may be used 'safely' without examining *how* they contribute to the safety of the ultimate product, *and* how they may potentially contribute to 'unsafe' outcomes.

/>> Section 1 of ISO26262 defines safety as "absence of unreasonable risk" (3.132)./
/>> Unreasonable risk is also defined (3.176) as "Risk (3.128) judged to be unacceptable in a certain context according to valid societal moral concepts"./
/>> Which means we now have a string of new terms to be defined (judged? unacceptable?  context?  valid?  societal moral concepts?)/
This is one of the challenges with safety, and the reason I believe that we need not just mutually-agreed terminology, but a set of inter-related terms that clearly define the context for our work.

The ISO 26262 definitions [1] that you quote, as you have found, include some subjective terms that appear to be unhelpful from an engineering perspective. They are also explicitly framed for the context of a vehicle, and for the way that the automotive supply-chain model expects components to be developed.

Part of the problem here is that the precise meaning of 'safe' and 'safety' is entirely dependent on context. The STPA Handbook [2] confronts this problem head on: the first step in the first stage of analysis is to identify the 'losses' that we are trying to prevent, where the meaning of 'loss' is defined like this:

"A loss involves something of value to stakeholders. Losses may include a loss of human life or human injury, property damage, environmental pollution, loss of mission, loss of reputation, loss or leak of sensitive information, or any other loss that is unacceptable to the stakeholders."

It goes on to define 'hazard' in reference to 'loss'. I very highly recommend reading it as a

/>> Is there any hope to get out of this quicksand/deadlock?/
Yes! But I do not believe that we can do so by agreeing to ignore the quicksand.




Join { to automatically receive all group messages.