23.03.2017 Views

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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

21-12 Industrial Communication Systems<br />

In literature such as [GIE95] or [LIG02], failure rates for standard hardware components are listed.<br />

Failure rates are available for resistors, diodes, transistors or capacitors, and the like, and are quantified<br />

in failure in time (FIT), which equals a risk of 10 −9 h −1 . They are used to perform the risk analysis. For<br />

example, a risk resulting from the input device is a combination of failures rates of different components<br />

finally leading to a quantified risk value for the complete circuit. The same is true for the CPU, or nonvolatile<br />

and volatile memory. See [BOE04] for examples on how to calculate failures rates of circuits.<br />

In conclusion, the hazard and risk analysis is the base for two types of requirements:<br />

• Hazards shall be addressed by adequate safety function requirements.<br />

• The risk resulting from the hazards has an impact on the safety integrity requirements. The lower<br />

the residual risk shall be, the higher and stricter the safety integrity requirements are.<br />

Both requirements have an impact on the type of safety measures used to reach the target SIL. The<br />

first defines what measures are required while the latter specifies the safety performance of the measures<br />

(e.g., what type of faults can be detected).<br />

21.5.3 Failure Mitigation<br />

Failure mitigation comprises all activities in the safety lifecycle relating to the identification of<br />

safety functions and safety integrity requirements as well as derivation of safety measures from the<br />

requirements.<br />

As mentioned before, both types of requirements are a result of the hazard and risk analysis. It is<br />

separated into two parts: network (cf. Table 21.6) and node hardware (cf. Table 21.7). Typical hazards<br />

and measures to detect them are listed in Table 21.8.<br />

Table 21.8 shows that eight safety measures are specified to address the various hazards resulting<br />

from network failures. The measures result in a generic safety-related message format: in a specific <strong>communication</strong><br />

model and a required hardware architecture.<br />

As in most cases, the standard protocol shall not be altered (black-channel approach), the safetyrelated<br />

protocol is embedded into the payload field of the <strong>communication</strong> protocol. And it shall be different<br />

from the standard protocol to reduce the likelihood of coupling between non-safety-related and<br />

safety-related messages. As shown in Figure 21.6, the safety-related message has the following structure:<br />

• ID (Identifier) consists of length field and a version field: Version denotes the version of the protocol.<br />

It is possible that different types of safety-related message structures are used. The identifier<br />

is a means of detecting insertion of a message by a faulty node.<br />

• Safe address: Safety-critical and non-safety-critical services shall be provided by the system.<br />

Therefore, safety- and non-safety-related messages coexist in the same network. To guarantee<br />

absence of reaction between them explicitly, every safety-related message includes a safe address.<br />

Data sent from a safe output data point (called producer) to a safe input data point (called consumer)<br />

is only processed if the safe address of the producer is known to the consumer.<br />

• Timestamp: A timestamp is the only means to detect the delay between sending at the sender<br />

side and receiving at the receiver. In case of event-triggered <strong>communication</strong> and devices storing<br />

messages temporarily (e.g., routers), congestion on the network, or wrong routing, a message can<br />

be delayed and therefore outdated. Additionally, wrong sequence of a message and repetition of<br />

the same message is detected. However, a timestamp mechanism requires time synchronization<br />

among the different nodes, which is an additional effort to be considered.<br />

• Safety-related data: Sensor and actuator data is embedded into that field.<br />

• Cyclic redundancy check: The measures mentioned before are implemented to detect systematic<br />

faults (faults that cannot be quantified). The CRC is a means against stochastic faults like a bit<br />

fault leading to a corruption of the message, and it ensures the integrity of the safety-related<br />

message. Depending on the medium of the network (twisted pair, powerline, …), different CRC<br />

polynomials have to be chosen [KOO04].<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!