It is difficult to talk about in the abstract, but to answer questions 1 & 3, one may need to consider the motivation for the issue of the original standard and its subsequent obsolescence, and the reason that the standard is called up on a given project. Standards may become “obsolete” purely because the issuing organisation says they are. They may do so because they no longer want the expense of maintaining the standard (e.g. if its contents have become standard custom and practice), or because they no longer want to do business in the way suggested by the standard. These reasons do not (necessarily) mean that the things suggested by the standard are a bad idea, or obsolete in a practical sense. Whether such “administrative obsolescence” is a problem depends on the contractual and regulatory framework of the project you are dealing with, and how close your context of use is to that envisaged by the standard’s authors.

For question 2, I would argue that the claim of SIL1 against the old checklist might be valid in the context of a system where everything was developed against the same (old) standard, and this is understood by the stakeholders. However, I would not see it as a valid claim when the rest of the system is developed against a newer version of the checklists. In Carl’s context, where Project B is being developed with an enhanced checklist, but is only a small portion of the overall codebase, one might claim SIL1 against the old standard for the whole system, with the warm fuzzy feeling that some parts have better assurance than you are claiming. Then you get back into the argument about whether the old SIL1 is good enough now, and whether it is proportionate to re-work Project A.

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.

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.

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:

Is it acceptable to use an obsolete (but still valid) safety standard to assess new software?

Is the SIL1 claim for 10 year old Project A invalid because the checklist could have been better?

If Project B used the old checklist from Project A would that be adequate?

"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?

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:

Is it acceptable to use an obsolete safety standard to assess software?

Is the SIL1 claim for 10 year old Project A invalid because the checklist could have been better?

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?

" 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."
#

" 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
The System Safety Mailing List
systemsafety_at_xxxxxx
Received on Wed Jul 08 2015 - 19:53:17 CEST