wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

Functional Safety 21-5
safety engineer looks at the system in its present stage (this may be only the documented architecture
and design, or the fully implemented system, depending on the state of the development) and analyses
potential scenarios that lead to hazards. Most analyses in this stage are concerned with faults and failures
that may occur. These analyses present a core of the work of a safety engineer.
Safety validation, as the final step, summarizes all the results and evidences. During this phase, it has
to be shown that all hazards are mitigated and that all safety requirements have been met. This is usually
done in the form of a “safety case.” A safety case is a sound and rigorous argument, which clearly
demonstrates sufficient safety of a system in a given context. The safety case document references and
uses all previously obtained results in order to construct this proof. All these building blocks, which are
necessary for this proof, are usually called “evidences.” A notation how such a safety case can be constructed
is presented later in this section.
The safety lifecycle generally continues until the end of life of the system. The full lifecycle can be
found in [IEC61508]. However, for brevity, we have concentrated on the major stages.
All methods that are shown in the following sections are to be used during the safety lifecycle. A reference
to the relevant stage of the lifecycle as shown in Figure 21.2 will be made. Generally, the project
safety manager is responsible for the conduct of the analyses and executes them together with the
project safety engineer and relevant team members. In smaller projects, the role of safety management
and safety engineering can be combined. In larger projects, there may be more than one safety engineer.
The methods presented here are only a selection of possible methods. [IEC61508], part 7, annexes A,
B, and C contain a comprehensive list of methods with brief descriptions and further references.
21.4.2 HAZOP
Hazard and Operability Study (HAZOP) is a method to identify hazards. It should therefore be used
at the very beginning of the safety lifecycle, during the hazard and risk analysis phase. Although this
method originates from the process industry, it is very generic and can therefore be applied broadly.
For electronic systems, it is standardized in [DS00-58].
The intention of the HAZOP is to analyze all possible functions of a given system and examine
all credible malfunctions or deviations from the correct function. In order to identify all potential
hazards, this method suggests the use of a given set of guide words that shall be applied to functions
(Table 21.2).
All these guide words shall be systematically applied to all functions. It remains to be decided what
the “functions” of a system are. Basically, the functions should be defined in a system description or
TABLE 21.2
No
More
Less
As well as
Part of
Reverse
Other than
Early
Late
Before
After
HAZOP Guide Words
This is the complete negation of the design intention. No part of the intention is achieved
and nothing else happens.
This is a quantitative increase.
This is a quantitative decrease.
All the design intention is achieved together with additions.
Only some of the design intention is achieved.
The logical opposite of the intention is achieved.
Complete substitution, where no part of the original intention is achieved but something
quite different happens.
Something happens earlier than expected relative to clock time.
Something happens later than expected relative to clock time.
Something happens before it is expected, relating to order or sequence.
Something happens after it is expected, relating to order or sequence.
Source: Ministry of Defence, HAZOP Studies on Systems Containing Programmable Electronics, U.K.
Defence Standard, Def Stan 00-58, Ministry of Defence, Glasgow, U.K., 2000, Part 1, p. 14. With permission.
© 2011 by Taylor and Francis Group, LLC