Re: [SystemSafety] Software Safety Assessment

From: SPRIGGS, John J < >
Date: Wed, 8 Jul 2015 11:58:11 +0000

In my industry, in both the UK and France, the law is (EC) No 482/2008, as amended. It basically says “Show the ‘competent authority’ that your software satisfies valid safety requirements that were derived from system-level requirements; that you can trace between those requirements and the tests/analyses you did; that it has no hazardous behaviour; and that all the evidence you presented to support your argument is pertinent to the build state you intend to deploy.” The argument could be transformed into a very big checklist if you must. No standards are specified.


From: systemsafety-bounces_at_xxxxxx Sent: 08 July 2015 12:50
Subject: Re: [SystemSafety] Software Safety Assessment

This is the same in France roughly. In addition it is probable that if checklist for A was produced, it would be understood as a proof of negligence.

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 1:48 PM
Subject: Re: [SystemSafety] Software Safety Assessment

In the UK, the governing legislation is the 1974 HSWA. As a duty holder, one is required to assess the risks to workers and the general public and to reduce those that are not and to mitigate those risksso far as reasonably practicable (i.e. to the point where the cost of further risk reduction would be very disproportionate to the benefit realised).

If standard X was replaced because it was considered inadequate to satisfy the duty under the Act, then it should no longer be used. Moreover, if Project A is still in use, then the duty holders must question whether they have fulfilled their duties under the Act by following Standard X - in particular, it may be considered negligent if they have not reassessed A against the revised standard to establish whether the risks of continued operation are still ALARP. If the "improved checklist" is an internal company document, then both the checklist and the revised standard would seem to be significant documents that a reasonable person would take into account in assessing whether the duties had been fulfilled.

A reassessment should also follow any material changes to the operating environment.

These are my personal views only. I am not a lawyer and the views of HSE or a UK Court may well differ from mine.


On 08/07/2015 10:53, 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."

If you are not the intended recipient, please notify our Help Desk at Email information.solutions_at_xxxxxx immediately. You should not copy or use this email or attachment(s) for any purpose nor disclose their contents to any other person.

NATS computer systems may be monitored and communications carried on them recorded, to secure the effective operation of the system.

Please note that neither NATS nor the sender accepts any responsibility for viruses or any losses caused as a result of viruses and it is your responsibility to scan or otherwise check this email and any attachments.

NATS means NATS (En Route) plc (company number: 4129273), NATS (Services) Ltd (company number 4129270), NATSNAV Ltd (company number: 4164590) or NATS Ltd (company number 3155567) or NATS Holdings Ltd (company number 4138218). All companies are registered in England and their registered office is at 4000 Parkway, Whiteley, Fareham, Hampshire, PO15 7FL.

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Wed Jul 08 2015 - 13:58:21 CEST

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