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

[Gerry R Creech]

Myriam,

The analysis of independence would also need to prove that any failure of 
the SIL 0 software could not affect the operation of the safety software.

Since the none safety software does not have a systematic capability 
rating, it must be assumed that the non safety software could do anything 
(not just what the programmer has designed) and hence protection 
mechanisms must be applied around the safety software.

For example, the memory used for the safety software would need to be 
protected to ensure that it was not possible for the non safety software 
to write into the safety area.
There would need to be measures to ensure that failure of the non safety 
software could not take resources away from the safety software, for 
example if the non safety software went into a loop the safety software 
would still need to operate. 

 
Best regards,
 
Gerry Creech

Web:    www.rockwellautomation.com



From:   M Mencke <menckem at gmail.com>
To:     "systemsafety at techfak.uni-bielefeld.de" 
<systemsafety at techfak.uni-bielefeld.de>
Date:   23/07/2013 09:21
Subject:        [SystemSafety] Separating critical software modules from 
non-critical software modules
Sent by:        systemsafety-bounces at techfak.uni-bielefeld.de



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

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