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

21-4 Industrial Communication Systems
Depending on the required SIL, there are constraints regarding the system architecture. For example,
the higher the SIL, the more fault tolerance is required, which is reflected in the number of redundancies
a system must possess.
Depending on the SIL, the methods used for the design and development of the system are also
different. The higher the SIL, the more rigorous are the methods that must be used. This is especially
crucial for the software, since the used methods play an important role in the achieved software quality.
Software developed with more rigorous methods are less likely to contain undetected faults.
In addition to architecture constraints and required methods, the standard calls for adequate documentation
to be produced. The documentation is necessary in order to be able to verify if the system
has actually achieved the claimed SIL. The “proof of safety,” often in the form of a so-called safety case,
summarizes all this evidence. The safety case must then be approved by some regulatory agency before
the system goes into operation.
21.4 the Safety Lifecycle and Safety Methods
This section introduces the safety lifecycle and then presents some of the methods that may be used
during this lifecycle.
21.4.1 Generic Lifecycle
The safety lifecycle specifies what has to be done in the course of the life of a system from the safety point
of view, from initial conception until the disposal. All safety standards specify such a lifecycle, with the
principles being comparable in all of them. For this reason, we will present here a generic safety lifecycle
(Figure 21.2).
The first step, the hazard and risk analysis starts with an identification of the hazards the system may
pose. At this time, there should already be a rough requirements specification of the system, and the
major functions should be defined. Based on this information, the potential hazards should be identified.
This step is crucial: all theoretical hazards have to be identified, otherwise it is impossible to devise
the right methods and countermeasures for them. Hazards that are not identified at this step will not
be considered adequately during the remainder of the safety lifecycle and may later pose a risk during
system operation. After the identification of the hazards, the hazards must be classified according to
their severity and probability, so that the resulting risk can be determined.
The next step in the safety lifecycle of Figure 21.2 is the safety requirements specification. Based on
the results of the risk analysis, it is generally necessary to define requirements to ensure that the risks
are mitigated to a level so that they are acceptable. The safety requirements can be of various types. They
can either be functional requirements, which require an additional implementation of some kind, or
they may be nonfunctional requirements, such as the requirement to perform a certain specific analysis,
or the requirement to use certain processes during the development. For example, a functional safety
requirement in a communication system may specify a checksum with certain failure detection and/or
correction properties. A nonfunctional safety requirement may specify the need to perform a commonmode
failure analysis on the design of the system. The specified safety requirements should be included
in the requirement specification of the complete system.
The third step in the safety lifecycle consists of the performance of all the safety analyses. These analyses
can be of various types, and some of them will be described in the following sections. In general, the
Hazard and risk
analysis
Safety requirements
specification
Safety analyses
Safety validation
FIGURE 21.2
Generic safety lifecycle.
© 2011 by Taylor and Francis Group, LLC