A journey across domains and safety standards
The position of software regarding the global system safety is subject to significant variations among the various application domains and their safety standards. As a consequence, the position regarding whether, how and to which extent software safety analyses could or should contribute to the global safety assessment also varies. In Civil Aviation [ARP 4754A; ARP 4761; DO 178C] Nuclear [IEC 61513, IEC 60880] and to some extent Space [ECSS Q40; ECSS Q80] safety analyses are performed at system level and on functions, sub systems and equipment, but not under the form of dedicated safety analyses applied to software. In these domains, the rationale is that software contributes to system safety through adherence to software development and validation rules i.e. through an argument on confidence in software correctness to an extent adapted to the consequences of failures. However it is worth noting that the assessment of the consequences of failures, and hence the determination of the Development Assurance Level, or Software Criticality Category, etc. result from safety omnibet analyses performed at system and not at software level. Conversely in domains such as railway [EN 50129] or automotive [ISO 26262] whereas the overall safety rationale is very similar, it is still required to perform in addition dedicated safety analyses applied to software. In the Base Safety Standard [IEC 61508] the software safety analysis encompasses a set of normative means supporting the functional safety assessment. In the process industries domain [IEC 61511] the concept is only emerging. In this paper, from our experience in safety practice and standard in several domains and discussions within a working group dedicated to cross domains comparison of safety standards, we propose a description of classical software safety analysis techniques and discuss the nature of arguments they can provide, according to their various objectives and situation in the global process and safety argumentation. We also discuss why software complexity increase has progressively made completeness of system functional safety requirements an important issue. Inspired by STPA and contract based design in software engineering, we make constructive propositions to mitigate the incompleteness risk. We sketch out a general specification setting, in which another kind of "software safety" analysis would come into play. We conclude on whether and how this could fit in the global system safety assessment.