[SystemSafety] Separating critical software modules from non-critical software modules

Tue Jul 23 11:24:14 CEST 2013

Until we live in a perfect world, then I think at a pragmatic level, there 
will always be <less than SIL 4 code> intermixed with SIL 4 code.  Why? 
Well in my opinion, very rarely do we ever start from a totally clean 
sheet of paper, so all requirements specifications and software have some 
"carry over" from previous projects and rather than rewriting code, the 
last module is reused.  I have been involved in the railway signalling 
industry since 1983 and I've also sat on the RIA23 committee.  I have 
watched these standards develop, I have assessed EN50128 compliance 
reports where most of them are retrospective (in other words the software 
already exists, so let's see how best it matches to the standard).

With the latest EN50128, we now have the role of "tester", do we have to 
go back and retest all previous software versions to meet EN50128:2011, of 
course we don't, we accept it was designed to "best practice" at that 
time.  In the same way, I doubt if any software in any railway system wont 
have some "legacy" modules in there somewhere, it's human nature and 
commercial pressure.

I can see the theory, but there is also the real world and I personally 
don't think we will ever achieve 100% separation, neither should we want 
to.  I see EN50128 as guidance as much as a standard, there has be huge 
doses of pragmatism associated with it's application.

My approach is that satisfying EN50128 (2001 or 2011) is necessary, but 
not sufficient to demonstrate you have achieved an acceptable level of 
safety.  In reality there is likely to be many more things in your system 
that will trip you up, apart from the software.

Cheers

Peter

Peter Sheppard
Senior Safety Engineer and Validator

Mobile: +44 7920 247931

Please consider the environment before you print / Merci de penser à 
l'environnement avant d'imprimer / Bitte denken Sie an die Umwelt bevor 
Sie drucken 

Bombardier Transportation UK Ltd 
Registered Office: Litchurch Lane, Derby, DE24 8AD, England 
TEL +44 1332 344666, FAX +44 1332 266271 
Registered in England 
Registration No. 2235994 

Ignacio González (Eliop) <igtorque.eliop at googlemail.com>
Sent by: systemsafety-bounces at techfak.uni-bielefeld.de
23/07/2013 09:55

To
M Mencke <menckem at gmail.com>
cc
"systemsafety at techfak.uni-bielefeld.de" 
<systemsafety at techfak.uni-bielefeld.de>
Subject
Re: [SystemSafety] Separating critical software modules from non-critical 
software modules

Hello, Myriam.
Just one remark (though many could be made): I have sometimes found that, 
if the amount of non-safety related software is not big, and the 
development team is small, it is better (cheaper) to develop the whole of 
it as if every function were SIL 4. Using a unique process, methodology, 
set of tools, and set of practices is a big advantage, even if it would 
not be necessary for every function / component.

2013/7/23 M Mencke <menckem at gmail.com>
Dear All,
For any software development project, many software modules are involved, 
where some are defined as safety critical, others are not. For example, in 
railway signaling, communications modules are likely to be defined as 
critical, whereas other modules such as those involving data storage or 
other basic functions are not. An analysis may be performed with the 
objective of demonstrating that the safety critical modules are entirely 
independent from the non critical modules, leading to the conclusion that 
the application of a programming standard for safety critical software is 
only required for those modules defined as safety critical (note the 
phrase ?with the objective of demonstrating??; I would hesitate before 
drawing the conclusion that the analysis really demonstrates what it is 
supposed to demonstrate). 
In my field the EN 50128 would be applied, however, it could be any 
standard for safety critical software. Thus, the software is developed 
applying the standard only to the modules which have been defined as 
?safety critical?. In order to supposedly save time/money, etc., the rest 
of the modules are developed as non-critical software, either as SIL 0 
functions or according to a standard programming standard. My question is 
whether such an approach is really valid, given that the application of a 
safety critical standard does not only involve the application of specific 
language features, it involves an entire development life cycle, and I 
find it difficult to see how the modules defined as ?non-critical? then do 
not form part of that life cycle. I?m not saying it is not valid, but I 
would like to know how others see this. 
Additionally, if the same programmers are involved in the programming of 
both critical and non-critical modules, does it really make sense that 
they only pay attention to the features required for safety critical 
software when programming the critical modules, and modify their 
programming style for the rest of the modules (or revert back to their 
?usual? style)? These questions also depend on what you consider as 
critical, for example, for a control system with a HMI, you could only 
consider communication modules critical, however, you need a GUI to 
display the status of the elements an operator has to control correctly. 
Some operations performed by the operator may not have the potential to 
generate a hazard with a high severity level, because there are 
mitigations in place. However, that doesn?t necessarily mean that the 
software responsible for displaying the information should not be 
programmed according to a safety critical standard. I am aware that these 
questions don?t have an ?easy? answer; any opinions would be appreciated.
Kind Regards,
Myriam.

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE

_______________________________________________________________________________________________________________ 

This e-mail communication (and any attachment/s) may contain confidential 
or privileged information and is intended only for the individual(s) or 
entity named above and to others who have been specifically authorized to 
receive it. If you are not the intended recipient, please do not read, 
copy, use or disclose the contents of this communication to others. Please 
notify the sender that you have received this e-mail in error by reply 
e-mail, and delete the e-mail subsequently. Please note that in order to 
protect the security of our information systems an AntiSPAM solution is in 
use and will browse through incoming emails. 
Thank you. 
_________________________________________________________________________________________________________________ 

Ce message (ainsi que le(s) fichier(s)), transmis par courriel, peut 
contenir des renseignements confidentiels ou protégés et est destiné à 
l?usage exclusif du destinataire ci-dessus. Toute autre personne est, par 
les présentes, avisée qu?il est strictement interdit de le diffuser, le 
distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, 
veuillez nous en aviser et détruire ce message. Veuillez prendre note 
qu'une solution antipollupostage (AntiSPAM) est utilisée afin d'assurer la 
sécurité de nos systèmes d'information et qu'elle furètera les courriels 
entrants.
Merci. 
_________________________________________________________________________________________________________________ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20130723/761d9176/attachment.html>