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

[M Mencke]

Thanks Ignacio,



That's what I'm currently contemplating. Particularly for lower SILs, the
amount of time and effort required to develop the entire software according
to, say, SIL 2 requirements may be almost lower than the effort required to
demonstrate that the probability of dependent failure between components is
sufficiently low by means of FMECAs, etc.



However, where the software is not new or it is modified, a significant
effort may be required to adapt it to the new requirements, if it is even
possible.



I also have to consider some practical issues - some software programmers
may not be accustomed to applying safety critical programming standards and
may not be familiar with methods for achieving and justifying independence.
Particularly in fields such as Railway, where, it seems to me, the “safety
critical” culture has taken longer to grow than in, say, Aeronautics.



Just out of interest, are there any other guidelines regarding the
justification of independence other than Section 7.2.4.3 of IEC 61508-2
(2010)? If I have to go by the standard which applies to my field, if I’m
not mistaken, this is what I get (without further details):



*Where the software consists of components of different software safety
integrity levels then all of the software components shall be treated as
belonging to the highest of these levels unless there is evidence of
independence between the higher software safety integrity level components
and the lower software safety integrity level components. This evidence
shall be recorded in the Software Architecture Specification.*



2013/7/23 Ignacio González (Eliop) <igtorque.eliop at googlemail.com>

> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20130723/758e792d/attachment-0001.html>