Background - Using Event-B for Critical Device Software Systems - page 14

these techniques is given in [ 70 , 77 ]. Software quality has been promoted in the
software architecture analysis domain. The software architecture is an important
process that helps to predict important qualities of a system and to identify the po-
tential risks [ 29 ]. To provide an early reliability analysis that covers software com-
ponents, it is advantageous to utilise both results from software architecture analysis
and conventional reliability analysis approaches [ 101 ].
According to the IEEE, software safety can be defined as “freedom from software
hazard,” where software hazard is defined as “a software condition that is a prereq-
uisite to an accident,” and an accident is defined as “an unplanned event or series
of events that results in death, injury, illness, environmental damage, or damage
to or loss of equipment or property” [ 54 ]. The use of formal methods in software
development process provides safety assurance that the software does not show any
failure cases. There are several techniques that are used to identify the software bugs
at the early stage of the system development. Each phase of the software develop-
ment is verified and validated using several techniques from requirements analysis
to code generation [ 54 , 55 ].
International regulatory standards provide guidelines for designing, operating
and maintaining the critical systems [ 48 ]. To analyse the reliability, the hardware
and software barriers must take into account. However, hardware barriers are more
reliable than the software barriers according to the past history of the system func-
tionality in terms of performance, proof-checking, and regress testing of the hard-
ware components [ 32 ]. In a complex system, self-test are not sufficient to identify
potential failures. Therefore, proof-checks are used to perform at regular intervals
to cope with undetected hardware failures.
The hardware systems are subject to ageing and wear. Ageing and wear char-
acteristics of the hardware systems provide a way to calculate the reliability using
MTBF. However, the software systems are not applicable to use statistical technique
like MTBF for reliability calculation, because software systems are not subject to
ageing and wear. Tools and techniques related to the software failures are not similar
to the hardware failures due to different characteristics of both software and hard-
ware systems. The software systems do not follow the physical laws of degradation
or failure as per the hardware systems [ 116 ].
The software reliability is an important challenge in the area of safety critical
systems, where software may be used to control the hardware components. The soft-
ware failures can be identified using software-centric approach and system-centric
viewpoint. The software-centric approach looks for failure modes and to evaluate
their probabilities, and the system-centric viewpoint is based on practical obser-
vation related to the specifications and requirements, which encapsulate software
design failures.
The fault injection method is a technique for quantitative analysis of the software
failure that deliberately inject faults in the software and count the number of times
that the software maintains its function in spite of the injected fault [ 1 , 46 , 105 ].
However, this approach is not effective to discover all hidden failures. Hence, an-
other feasible approach to building the reliable software is to use the systematic
software development process. The main objective is to evaluate different fault tol-
erant approaches throughout the software development process [ 116 ].