The safety life cycle is the series of phases from initiation and specifications of safety requirements, covering design and development of safety features in a safety-critical system, and ending in decommissioning of that system. This article uses software as the context but the safety life cycle applies to other areas such as construction of buildings, for example. In software development, a process is used and this process consists of a few phases, typically covering initiation, analysis, design, programming, testing and implementation. The focus is to build the software. Some software have safety concerns while others do not. For example, a Leave Application System does not have safety requirements. But we are concerned about safety if a software that is used to control the components in a plane fails. So for the latter, the question is how safety, being so important, should be managed within the software life cycle.
What is the Safety Life Cycle?
The basic concept in building software safety, i.e. safety features in software, is that safety characteristics and behaviour of the software and system must be specified and designed into the system. The problem for any systems designer lies in reducing the risk to an acceptable level and of course, the risk tolerated will vary between applications. When a software application is to be used in a safety-related system, then this must be borne in mind at all stages in the software life cycle. The process of safety specification and assurance throughout the development and operational phases is sometimes called the ‘safety life cycle’.
The first stages of the life cycle involve assessing the potential system hazards and estimating the risk they pose. One such method is fault tree analysis. This is followed by a safety requirements specification which is concerned with identifying safety-critical functions and the safety integrity level for each of these functions. The specification may either describe how the software should behave to minimize the risk or might require that the hazard should never arise. A ‘normal’ process model is then followed with particular attention paid to the validation of the system. Part of that validation should be an explicit safety validation activity.
