[SystemSafety] Safety Case Standards and Experience

[Bridal Olof]

Part 10 is actually a part of the formally released standard, although the official version part 10 was released in 2012 while parts 1-9 were released in 2011. Part 10 makes the purpose of the safety case very clear, as Patrick has pointed out.

However, it should be kept in mind that ISO 26262 only addresses that part of safety that is related to potential malfunctions of electrical/electronic systems. There are of course other safety aspects to consider in a complete safety case.

Best regards,

Olle
_________________________________________________
Dr Olle Bridal
Senior Engineering Specialist - Functional Safety
Systems and Architecture

Volvo Group Trucks Technology
Advanced Technology & Research
Dept BF40740, M1.3
405 08 Gothenburg, Sweden
Telephone:    +46-31-323 30 16
SMS/Text:            +46-76-553 30 16
E-mail: olof.bridal at volvo.com
www.volvogroup.com


-----Original Message-----
From: systemsafety-bounces at lists.techfak.uni-bielefeld.de [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of René Senden
Sent: den 17 februari 2014 11:02
To: 'Patrick Graydon'; systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Safety Case Standards and Experience

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


_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE