[SystemSafety] Safety Case Standards and Experience

René Senden rene.senden at gmail.com
Mon Feb 17 11:02:07 CET 2014


Patrick,

The work products (including scope, contents) are prescribed in much detail
so any "safety argument" is already pretty much set.
Your reference to part 10 (informative) is not valid because part 10 is not
included in the formally released standard, it was only 
included in a draft version (submitted for review) that preceded the formal
release.

There is an argument involved here, there always is, but it is not the
strict safety argument we find in goal-based/safety-case-oriented standards.
It is not a structured argument to justify that a system/item is reasonably
safe, it is an argument that the safety requirements for an item are
complete 
and satisfied by evidence compiled from work products.

Rene


-----Original Message-----
From: Patrick Graydon [mailto:patrick.graydon at mdh.se] 
Sent: maandag 17 februari 2014 6:48
To: René Senden; systemsafety at lists.techfak.uni-bielefeld.de
Cc: Patrick Graydon
Subject: Re: [SystemSafety] Safety Case Standards and Experience


On 17 Feb 2014, at 00:42, René Senden <rene.senden at gmail.com> wrote:

> In the automotive domain, ISO 26262 is applicable which is an adaptation
of IEC-61508. ISO 26262 does not adopt the safety case concept in the sense
of a safety argument, backing evidence etc.
> ISO26262 prescribes the development of a whole range of Work Products, 
> this collection of WPs is considered the safety case (evidence), it does
not however prescribe the development of a safety argument.

Sorry to disagree, but while I am not completely happy with the way ISO
26262 uses safety arguments, I don’t think it is accurate to say that ‘ISO
26262 does not adopt the safety case concept in the sense of a safety
argument, backing evidence etc.’

It is true that the clause that directs you to build a safety case (Part 2,
clause 6.4.6) does not say ‘thou shalt build a safety argument’.  It says,
‘this requirement shall be complied with for items that have at least one
safety goal with an ASIL (A), B, C or D: a safety case shall be developed in
accordance with the safety plan’ and this safety case ‘should progressively
compile the work products that are generated during the safety lifecycle’.
However, the definitions in Part 1 say that a safety case is an ‘argument
that the safety requirements for an item (1.69) are complete and satisfied
by evidence compiled from work products of the safety activities during
development’.  Since Part 2 makes these definitions normative in section 2,
clause 6.4.6 must be understood as requiring creation of an argument.  Any
group that does not produce one is not conforming to the standard.

If there was any doubt about what ISO 26262 means by safety cases, the
informative section 5.3 of Part 10 makes it crystal clear: ‘a safety case
requires communicating a clear, comprehensive and defensible argument
(supported by evidence) that a system is free of unreasonable risk to
operate in a particular context.  The following are important considerations
for the purpose defined above:

	• Above all, the safety case exists to communicate an argument.

	• It is used to demonstrate how it is possible to reasonably
conclude that a system is free of unreasonable risk based on the available
evidence.

	• A safety case is a device for communicating ideas and information,
usually to a third party.’

‘There are three principal elements of a safety case, namely:

		• the requirements;

		• the argument; and

		• the evidence.’

You might quibble that the argument ISO 26262 requires is not a ‘safety
argument’ since it is at the level of an item, not a system, and thus has
satisfaction of the item’s safety requirements, not overall system safety,
as its top-level goal.  But we speak of ‘software safety arguments’ which
have exactly this limitation.  I may not be happy with everything it says on
the subject, but by every reasonable interpretation ISO 26262 does require
creation of a safety argument.

Kind regards,
— Patrick

Dr Patrick John Graydon
Postdoctoral Research Fellow
School of Innovation, Design, and Engineering (IDT) Mälardalens Högskola
(MDH), Västerås, Sweden




More information about the systemsafety mailing list