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

From: Gerry R Creech < >
Date: Tue, 23 Jul 2013 09:43:41 +0100


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


From: M Mencke <menckem_at_xxxxxx
To: "systemsafety_at_xxxxxx <systemsafety_at_xxxxxx Date: 23/07/2013 09:21
Subject: [SystemSafety] Separating critical software modules from non-critical software modules
Sent by: systemsafety-bounces_at_xxxxxx

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,

The System Safety Mailing List

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Tue Jul 23 2013 - 10:46:02 CEST

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