23.03.2017 Views

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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

21-2 Industrial Communication Systems<br />

contexts, such as electrical safety, personal safety, safety on the streets, system safety, or functional safety.<br />

In this chapter, we are exclusively concerned with the latter.<br />

We use the definitions according to [IEC61508]. Safety is defined as “freedom from unacceptable risk<br />

of harm.” and functional safety is the part of the overall safety that relates to the correct functioning<br />

of some system (e.g., a control system or an <strong>industrial</strong> <strong>communication</strong> system) to maintain safety.<br />

The functions that need to be performed correctly in order to achieve safety can hence be classified as<br />

safety related.<br />

Generally, safety is not an absolute property. To state that the risk related to a specific system has been<br />

reduced to zero is generally not a realistic statement. Risk—measured as a combination of probability<br />

and severity of an undesired event—is something that we are confronted with continuously. The crucial<br />

question is the risk acceptability. What level of risk are we willing to accept. This complex question will<br />

not be delved into here, but it should be said that this depends on society, on time, and on the domain<br />

in question. Luckily, for <strong>industrial</strong> <strong>communication</strong> and control <strong>systems</strong>, this question has already been<br />

posed and answered many times, such that reference can be made to these results.<br />

Safety should not be confused with security: Security is concerned with the protection against<br />

intentional attacks, in order to safeguard integrity, confidentiality, and availability of services. Safety<br />

is concerned with the avoidance of unintended accidents involving harm to people and the environment.<br />

A common denominator is that both disciplines—safety and security—have the goal of avoiding<br />

unwanted events. This also makes it hard to determine the success of safety (and security) measures,<br />

since they were successful if something unwanted does not happen.<br />

A basic concept in safety engineering is the concept of a hazard. A hazard is defined as a “potential<br />

source of harm” [IEC61508]. If all hazards are identified and corrected and adequate measures are taken<br />

to control and mitigate the hazards, safety is achieved. This is the reason why the identification of hazards<br />

has to be done at the very beginning of system development. Typical hazards for <strong>industrial</strong> <strong>communication</strong><br />

<strong>systems</strong> would be the loss or corruption of a message.<br />

The importance of hazards and their identification before they actually cause an accident also highlights<br />

the proactive nature of safety. Safety engineering is concerned with predicting unwanted events<br />

before they happen, not (only) to learn from failures.<br />

21.3 Safety Standards<br />

In order to guarantee the achievement of a well-defined goal, in our case sufficient safety, standardization<br />

plays an important role. Standardization helps to make <strong>systems</strong> interoperable and comparable. The<br />

goal of safety standards is to devise generally applicable rules and recommendations, in order to be able<br />

to build, operate, and maintain a safety-related system.<br />

21.3.1 Overview of Safety Standards<br />

The general problem with standards is that they must achieve a compromise between general applicability<br />

and practical usefulness for specific <strong>systems</strong> giving concrete guidance. A high-level standard<br />

may be applicable to a wide range of <strong>systems</strong>, but in order to be applicable to such a large group<br />

of <strong>systems</strong>, it must make several generalizations, which make the standard less understandable<br />

for the engineers building a system in a specific domain. Standards that contain a lot of specific<br />

information are on the other hand only applicable for a small number of <strong>systems</strong> and applications.<br />

In order to handle this compromise, standards are often classified as generic, domain specific, and<br />

application specific.<br />

Standards are abundant, and there is no exception in the domain of safety-critical and safety-related<br />

<strong>systems</strong>. A selection of some standards that are all concerned with safety-related <strong>systems</strong> can be found<br />

in Figure 21.1. Bear in mind that this is surely not a comprehensive figure, but it illustrates the proliferation<br />

of safety standards.<br />

© <strong>2011</strong> by Taylor and Francis Group, LLC

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!