Re: [SystemSafety] Software Safety Assessment

Date: Wed, 8 Jul 2015 14:14:39 +0200

It is said SIL. So the standard(s) is almost identified.

Now if you look at a "SIL" checklist in say the food industry and the checklist for the same "SIL" in the railway or aerospace industry, the gap looks like a joke. Guess which one (taking out sector biases such as vocabulary and tools) reflects the best the "real" state of the art.

Bertrand Ricque
Program Manager
Optronics and Defence Division
Sights Program
Mob : +33 6 87 47 84 64
Tel : +33 1 58 11 96 82

Sent: Wednesday, July 08, 2015 2:09 PM
To: systemsafety_at_xxxxxx Subject: Re: [SystemSafety] Software Safety Assessment

Some important clarifications:

Project A has not yet been fielded but the software was assessed against Standard X 10 years ago.

The techniques applied to Project A were appropriate and fulfilled the requirements of Standard that time and now. But the evidence from the checklist could have been better.

No idea why you assumed unused 10 year old code but that's not the case here.


From: Drew Rae [mailto:d.rae_at_xxxxxx Sent: 08 July 2015 12:57
To: Carl Sandom
Cc: systemsafety_at_xxxxxx Subject: Re: [SystemSafety] Software Safety Assessment

"Acceptable" either comes from some form of social consensus, or from a belief that the particular techniques applied are appropriate for that particular piece of software. The way you've phrased the question, it sounds like there is significant doubt that the techniques applied on Project A were appropriate for Project A. If Project A hasn't been previously deployed, that's like saying

"I've got this piece of old flex cable sitting under the house. It doesn't meet current electrical safety standards - in fact it wouldn't have met 10 year old safety standards except they were a bit vague and there was a loophole - but I should be allowed to use it anyway. And since I'm using dodgy flex anyway, you don't mind if I apply the same standards to my new wiring as well, do you?".

Compliance with a standard is typically the _minimum_ required for safety. Safety requires compliance, but compliance doesn't give safety. If there's doubt that the checklist for Project A was good enough, no amount of weaselling about standards is going to make it good enough.

As others have said though, if you just want acceptability as a social consensus, then it's not a question that can be answered in the abstract, only in terms of the supplier, customer, and any contract or regulator involved.

Incidentally - someone is resurrecting 10 year old code that's been sitting unused, and significantly hacking it around, and they intend to use it for a safety application? And that's not enough to make people run screaming for cover? I can understand a need to modify legacy embedded code that's been in use, but unused 10 year old code?

On 08/07/2015, at 7:53 PM, Carl Sandom wrote:

Consider the following scenario:

In 2004 Project A software was assessed against a safety standard (let's call it Standard X). Standard X had a very prescriptive list of software safety requirements and a simple checklist was used for assessing SIL1 compliance.

In 2014, Project B began to integrate significant new functionality into Project A. Standard X, which was by 2014 an obsolete standard, was used to assess the significantly smaller software baseline of Project B. Under modern scrutiny, the simple Standard X checklist used for Project A in 2004 was not as explicit as it could have been and it was decided to use an improved checklist for Project B.

A couple of important questions can be raised with this scenario:

  1. Is it acceptable to use an obsolete safety standard to assess software?
  2. Is the SIL1 claim for 10 year old Project A invalid because the checklist could have been better?
  3. If Project B used the old checklist from Project A would that be adequate?

I've been having some interesting discussions with the Project Managers involved, any thoughts?


Dr. Carl Sandom CErgHF CEng PhD
iSys Integrity Ltd.
+44 7967 672560

The System Safety Mailing List

" 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 Received on Wed Jul 08 2015 - 14:14:53 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:07 CEST