Random hardware failure

Users and designers should refer to Annex A of this standard for guidance in techniques available to ensure SIS design satisfies performance relating to random hardware failures. 

It should be emphasized that a FMEDA provides failure rates, failure modes and diagnostic coverage effectiveness for random hardware failures. If done properly, it does not include failure rates due to "systematic" causes including incorrect installation, inadvertent damage, incorrect calibration or any other human error. 

To protect against random hardware failures, a safety PLC wiU emphasize internal automatic diagnostics, a combination of hardware and software... 

Systematic failures, e.g. failures that relate to the inherent design of the system rather than random hardware failures. 

The requirements for hardware safety integrity contain architectural constraints and random hardware failure quantification. The former are based on ... 

Reliability data may be obtained from manufacturers, the operator s own experience, generic data sources (e.g., OREDA (2002)), from expert judgements, and so on. In most cases, the data only reflects random hardware failures, that are caused by normal degradation, while systematic failures are not taken into account. Systematic failures are due to inadequate design, operation, maintenance, or exposure outside the design envelope, and do not have the same statistical properties as random hardware failures. 

Probability and frequency of random hardware failure Numerical ranges are specified for each SIL. The designed system probabihty is calculated using component failure mode and failure rate data. 

Much of the functional safety practitioner s work involves random hardware failure modes and failure rates as a way of providing quantitative information to support claims that a SIL specification has been met. This is accompanied by rehabihty engineering calculations, as described in detail in lEC 61508. Standard software packages have eased the calculation burden, particularly with fault tree analysis and probabihty of failure estimates. 

Information about deterministic or non-random failures may be difficult to extract from accident or incident scenario analyses. Unhke random hardware failures, deterministic faults maybe present from the outset and will not necessarily reveal themselves until a particular set of circumstances occurs. Apphcation software specification and implementation errors (bugs) are typical examples of faults that may remain unrevealed for years. In this context, a fault is the loss of capability to perform a function, while a failure would mean that the function has not been performed at all, when cahed upon to do so. 

Most of these are systematic issues. It could well be the case that they result in greater and more frequent loss than would be caused by random hardware failures. Other standards offer guidance for simple design concepts such as zero energy safe states, dual electrical circuits, direct acting mechanical arrangements and the hke. 

The collision was not caused by a random hardware failure, nor was it simply an error or oversight on the part of the persons performing the work. Instead there was a systematic culture of not conducting wire counts on devices, an action which would have revealed the rogue... 

Calculation of subsystems FFH (Probabihty of dangerous random hardware Failure per Hour) value is made by the proposed simplified approach for estimation. Four different subsystem architectures with five formulas available to use ... 

NOTE 2 A major distinguishing feature between random hardware faiiures and systematic failures (see 3.2.85) is that system faiiure rates (or other appropriate measures), arising from random hardware failures, can be predicted but systematic faiiures, by their very nature, cannot be predicted. That is, system failure rates arising from random hardware faiiures can be quantified but those arising from systematic failures cannot be statistically quantified because the events ieading to them cannot easily be predicted. 

NOTE 3 In determining safety integrity, all causes of failures (both random hardware failures and systematic failures) which lead to an unsafe state should be included for example, hardware failures, software induced failures and failures due to electrical interference. Some of these types of failure, in particular random hardware failures, may be quantified using such measures as the failure rate in the dangerous mode of failure or the probability of a safety instrumented function failing to operate on demand. However, the safety integrity of an SIF also depends on many factors, which cannot be accurately quantified but can only be considered qualitatively. 

Industry-published data, as well as manufacturer data, has shown that the random, hardware failure rate is in the range of 10-5/hr and 10-6/hr for typical BPCS hardware (e.g., DCSs and PLCs). 

The HSE study demonstrates that attention to detail is essential in the design and management of SIF. Inadequate procedures, training, and MOC contribute to SIF failure as readily as random hardware failure. Improper operational or maintenance activities can completely disable an SIF, no matter how fault tolerant the SIF design. To combat these errors, operation and maintenance procedures should be clear and consistent with operator or maintenance technician expectations to reduce the potential for error. Back-checks and independent confirmation should be used to verify that the SIF is operational after any maintenance activity. Design practices can also reduce operator or maintenance technician errors that could potentially lead to failure. 

It may also be able to justify less fault tolerance than required by Table 6, when the dangerous failure modes of the SIF devices and associated process interfaces are well understood. Clause 11.4.4 states that if the selection of a device is based on prior use, then, under specific conditions, the fault tolerance for sensors, final control elements, and non-PE logic solvers can be reduced by 1. The reduction of fault tolerance is acceptable, since prior use establishes the field application data, which includes the random hardware failures for the device itself and the random failures due to the process and field device interfaces. 

Safe-Failure Fraction - The fraction of the overall random hardware failure rate of a device that results in either a safe failure or a detected dangerous failure. 

An assessment has been completed documenting the device random hardware failure rates using Failure Mode Effect Analysis (FMEA). The results are documented and available to owners/operators in the following format ... 

The random hardware failure results are also used to calculate the Safe Failure Fraction (SFF) of the device and the PFDavg or Frequency of Failure for continuous-mode devices. The PFDavg provided by the manufacturer is based upon specific proof-test intervals and the mean time to repair specified by the manufacturer. For different assumptions, the user can use the fundamental failure rates provided and determine a PFDavg for their specific application. Details on SFF and PFDavg are included in Annex K. 

The first architecture addressed by Clause 11.3 is that of a fault-tolerant SIS that can perform its function in the presence of a single dangerous fault. Continued operation within the MTTR is taken into account in the calculation of the probability of random hardware failure. Consequently, the risk is increased slightly due to a single period of degraded state in the life of the device. It is important to monitor the cumulative out-of-service period or the number of failures per year because the risk is increased with each additional out-of-service period. Compensating measures are generally not required when fault tolerance is implemented, and repair is completed within the MTTR. 

The second case considered by the standard is where the SIS is not fault tolerant and is providing protection in a demand mode. Continued operation within the MTTR is taken into account in the calculation of the probability of random hardware failure. However, in this case, there is no protection until the faulted device is repaired and returned to service. Therefore, when continuing operation with a disabled SIF, compensating measures should be identified that provide risk reduction equivalent to that provided by the SIF in the absence of the fault. These compensating measures should be documented in the operation and maintenance procedures so that personnel are trained on their appropriate use. To continue operation beyond the MTTR, a management of change review should be conducted to ensure that the compensating measures identified are sufficient for extended operation and that priority has been placed on the repair. 

The failure categories in lEC 61508 relate to failures arising from both random hardware failures and systematic failures. The challenge to anyone designing a... 

There are four types of random hardware failures ... 

Part 7 Part 7 contains important information for those doing product development work on equipment to be certified per lEC 61508. Annex A addresses control of random hardware failures. Annex B covers the avoidance of systematic failures through the different phases of the safety life cycle. Annex C provides a detailed overview of techniques for achieve high software integrity. 

---