Re: [SystemSafety] Safety Case Standards and Experience

From: René Senden < >
Date: Mon, 17 Feb 2014 11:02:07 +0100


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_xxxxxx Sent: maandag 17 februari 2014 6:48
To: René Senden; systemsafety_at_xxxxxx Cc: Patrick Graydon
Subject: Re: [SystemSafety] Safety Case Standards and Experience

On 17 Feb 2014, at 00:42, René Senden <rene.senden_at_xxxxxx

> 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_xxxxxx Received on Mon Feb 17 2014 - 11:02:17 CET

This archive was generated by hypermail 2.3.0 : Mon Apr 22 2019 - 19:17:07 CEST