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

[M Mencke]

Dear René,

It is difficult for me to answer your question, both because we are at an
early design stage and because it depends on which elements you include in
the CI. It is likely that the non-critical CSCIs will be separate from the
critical CSCIs, so yes, this may offer some advantages. However, in that
case it will be of utmost importance to define the CI correctly.

Regarding reuse with(out) modifications, newly developed modules, etc., we
are talking about all of the above. Though I must admit, my intuitive
answer to your email was “it depends what you define as a SW component and
as a SW module”.

As you mention, it always remains an evaluation on a case-by-case basis,
and yer answers have considerably helped me in identifying the issues to
take into account while evaluating this case. Thank you,

Groeten,

Myriam


2013/7/25 René Senden <rene.senden at gmail.com>

> Dear Myriam,****
>
> ** **
>
> In your example, are we talking about sw-modules
> (safety-critical/non-safety-critical) which are part of the same
> sw-component? ****
>
> For example do these modules correspond to (or are they part of) CSCs
> within the same CSCI… ? ****
>
> Also, in both cases (critical vs non-critical), are we talking about newly
> developed modules, reuse with(out) modifications, or perhaps all of the
> “above”?****
>
> ** **
>
> It always remains an evaluation on a case-by-case-basis, at the same time
> the criteria for such evaluations are simply not very clear or perhaps not
> very generic.. ****
>
> One could probably argue successfully/convincingly for and against
> “sufficient independence” or “freedom from interference” in a significant
> amount of cases..  ****
>
> The efforts involving thorough analyses, as far as this is possible, are
> often quite significant to the point that they rival the efforts following
> the conclusion that ****
>
> the non-critical modules are not quite so non-critical… Unfortunately,
> some consider that such efforts are to be commensurate with the “level of
> criticality” ****
>
> involved, which is not defendable in my view… still it turns out to be
> deceptively rational in practice…****
>
> ** **
>
> Should we be talking about critical CSCIs vs non-critical CSCIs, this may
> offer some advantages since the corresponding interfaces (dependencies) are
> (or will be)****
>
> assumed to be transparent (appropriately documented) and under
> configuration/change-control, which of course facilitates the required
> analyses for independence… ****
>
> The higher up in the hierarchy the separation of critical from
> non-critical can be made, the better…but I suppose that probably goes
> without saying…****
>
> ** **
>
> I am not so sure this is helpful to you…****
>
> Best regards,****
>
> Rene ****
>
> ** **
>
> *From:* systemsafety-bounces at techfak.uni-bielefeld.de [mailto:
> systemsafety-bounces at techfak.uni-bielefeld.de] *On Behalf Of *M Mencke
> *Sent:* dinsdag 23 juli 2013 10:22
> *To:* systemsafety at techfak.uni-bielefeld.de,
> *Subject:* [SystemSafety] Separating critical software modules from
> non-critical software modules****
>
> ** **
>
> 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.****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20130726/7998e681/attachment.html>