[SystemSafety] Software Safety Assessment

[Nick Tudor]

Hi Carl

If the standard is obsolete, then it has been superseded and the new
version should be used; suggest it's not [subsequently] defendable to do
otherwise.  An obsolete standard can only be 'valid' if it is being used on
a project upgrade, ie the software has already been fielded/certified using
the now 'obsolete' standard.  As I understand your issue, the software has
not previously been fielded.

Nick Tudor
Tudor Associates Ltd
Mobile: +44(0)7412 074654
www.tudorassoc.com

*77 Barnards Green Road*
*Malvern*
*Worcestershire*
*WR14 3LR*
*Company No. 07642673*
*VAT No:116495996*

*www.aeronautique-associates.com <http://www.aeronautique-associates.com>*

On 8 July 2015 at 14:19, RICQUE Bertrand (SAGEM DEFENSE SECURITE) <
bertrand.ricque at sagem.com> wrote:

> Then it is in anyway obsolete …
>
>
>
> Bertrand Ricque
>
> Program Manager
>
> Optronics and Defence Division
>
> Sights Program
>
> Mob : +33 6 87 47 84 64
>
> Tel : +33 1 58 11 96 82
>
> Bertrand.ricque at sagem.com
>
>
>
> *From:* systemsafety-bounces at lists.techfak.uni-bielefeld.de [mailto:
> systemsafety-bounces at lists.techfak.uni-bielefeld.de] *On Behalf Of *Carl
> Sandom
> *Sent:* Wednesday, July 08, 2015 3:16 PM
> *To:* systemsafety at lists.techfak.uni-bielefeld.de
> *Subject:* Re: [SystemSafety] Software Safety Assessment
>
>
>
> valid technically but not superseded
>
>
>
> *From:* RICQUE Bertrand (SAGEM DEFENSE SECURITE) [
> mailto:bertrand.ricque at sagem.com <bertrand.ricque at sagem.com>]
> *Sent:* 08 July 2015 14:10
> *To:* Carl Sandom; systemsafety at lists.techfak.uni-bielefeld.de
> *Subject:* RE: [SystemSafety] Software Safety Assessment
>
>
>
> Another answer :
>
> 1. Is it acceptable to use an obsolete (but still valid) safety standard
> to assess new software?
>
> Obsolete technically or because superseded by a more recent document ?
> Still valid technically or because not superseded ?
>
>
>
> 2. Is the SIL1 claim for 10 year old Project A invalid because the
> checklist could have been better?
>
> SIL1 is so loose that I don’t see how to differentiate it from non safety
> SW developed under reasonable QA
>
>
>
> 3. If Project B used the old checklist from Project A would that be
> adequate?
>
> If standard A is not technically obsolete AND superseded by a new document
> (which would mean that the context is technically and from a
> regulatory/contractual point view so loose that nobody really cares), you
> might use the old checklist.
>
>
>
> Bertrand Ricque
>
> Program Manager
>
> Optronics and Defence Division
>
> Sights Program
>
> Mob : +33 6 87 47 84 64
>
> Tel : +33 1 58 11 96 82
>
> Bertrand.ricque at sagem.com
>
>
>
> *From:* systemsafety-bounces at lists.techfak.uni-bielefeld.de [
> mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de
> <systemsafety-bounces at lists.techfak.uni-bielefeld.de>] *On Behalf Of *Carl
> Sandom
> *Sent:* Wednesday, July 08, 2015 2:36 PM
> *To:* systemsafety at lists.techfak.uni-bielefeld.de
> *Subject:* Re: [SystemSafety] Software Safety Assessment
>
>
>
> It's complicated and I was trying to avoid too much detail to get to the
> central questions.
>
>
>
> It has been 'fielded' and is being 'used' during extended V&V activities
> (in parallel with the old system) but it is not yet considered fully
> operational. Safety assessment of some software aspects continues on
> Program A but not the 'process-based' software development assessment which
> was the subject of Standard X and the original checklist in 2004. For the
> scenario, take it as read that Standard X tools and techniques *are still
> valid* even though it is now obsolete.
>
>
>
> My original questions slightly modified are:
>
>
>
> 1. Is it acceptable to use an obsolete (but still valid) safety standard
> to assess new 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?
>
>
>
> Cheers
>
> Carl
>
>
>
> *From:* Drew Rae [mailto:d.rae at griffith.edu.au <d.rae at griffith.edu.au>]
> *Sent:* 08 July 2015 13:15
> *To:* Carl Sandom
> *Subject:* Re: [SystemSafety] Software Safety Assessment
>
>
>
> Carl,
>
> You may need to clarify here.
>
>
>
> The software was assessed 10 years ago.
>
> The project has not yet been fielded.
>
>
>
> There must be a missing detail for this not to be 10 year old unused code.
> Has it been used in some context other than Project A during that time?
>
>
>
> * This message is from my work email
>
> * I can also be contacted on andrew at ajrae.com
>
> * My mobile number is 0450 161 361
>
> * My desk phone is 07 37359764
>
> * My safety podcast is DisasterCast.co.uk
>
>
>
>
>
>
>
>
>
> On 08/07/2015, at 10:08 PM, Carl Sandom wrote:
>
>
>
> 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 X......at 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.
>
>
>
> Cheers
>
> Carl
>
>
>
> *From:* Drew Rae [mailto:d.rae at griffith.edu.au <d.rae at griffith.edu.au>]
> *Sent:* 08 July 2015 12:57
> *To:* Carl Sandom
> *Cc:* systemsafety at lists.techfak.uni-bielefeld.de
> *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?
>
>
>
>
>
> * This message is from my work email
>
> * I can also be contacted on andrew at ajrae.com
>
> * My mobile number is 0450 161 361
>
> * My desk phone is 07 37359764
>
> * My safety podcast is DisasterCast.co.uk
>
>
>
>
>
>
>
>
>
> 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?
>
>
>
> Regards
>
> Carl
>
> _________________________________
>
> Dr. Carl Sandom CErgHF CEng PhD
>
> Director
>
> iSys Integrity Ltd.
>
> +44 7967 672560
>
> carl at isys-integrity.com
>
> www.isys-integrity.com
>
> _________________________________
>
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>
>
>
> #
> " 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."
> #
>
> #
> " 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 TechFak.Uni-Bielefeld.DE
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20150708/7d514664/attachment-0001.html>