Big Chemical Encyclopedia

Chemical substances, components, reactions, process design ...

Articles Figures Tables About

Fault tolerance hardware redundancy

Several of FM s Loss Prevention Data Publications (1, 17B, 17C) discuss the concept of triply-redundant, fault-tolerant, high-reliability hardware/software systems for manufacturing operations. Risk analysis and systems reliability research is currently underway to develop better guidelines for the design and application of reliable process control systems. [Pg.132]

The requirements for hardware fault tolerance can apply to individual components or subsystems required to perform a SIF. For example, in the case of a sensor subsystem comprising a number of redundant sensors, the fault tolerance requirement applies to the sensor subsystem in total, not to individual sensors. [Pg.41]

Problem A set of non-redundant (hardware fault tolerance = 0) safety equipment is used to perform a safety instrumented function in continuous demand mode. Diagnostic time is given as one second. The following failure rate data is obtained when adding the failure rates of the categories of all components ... [Pg.103]

ANSl/lSA-84.00.01-2004 (lEC 61511 Mod) has a requirement for nainimum levels of "hardware fault tolerance" as a function of SIL level. This means that redundancy for purposes of achieving the safety function must be done depending on the SIL level target of the SIF. For field instruments and non-programmable logic solvers, the chart is shown in Figure 7-6. [Pg.103]

Sometimes the hardware fault tolerance is confused with redimdancy. They are not necessarily the same thing. Sometimes redundant instruments are used to maintain process operation, not to perform the safety function. In those cases, redundancy is not the same as hardware... [Pg.109]

The 3051S SIS has a 61508 assessment certificate states that the product can be used in SIL 2 applications as a single transmitter and SIL 3 applications if more than one transmitter is used in an identical redundant (hardware fault tolerance > 0) architecture. This helps point out the differences between random and systematic failures. The design process used to create the transmitter and its software met the more rigorous criteria of SIL 3. The chance of a systematic fault is lower. [Pg.136]

The aim of the first steps of designing a dependable control system consists in determining the best instrumentation, that is to say, a set of sensors and actuators that, with the lowest cost, allows the system to perform its mission despite the failure of one or several of its components. This activity is generally complex, because two antagonist aspects have to he taken into account (Conrard and Bayart, 2003) The system has to be inexpensive thanks to the minimisation of the number of components and it has to be fault tolerant which generally implies hardware redundancies. [Pg.1322]

Tolerate the Hazard. The design needs to be fault tolerant. That means, in the presence of a hardware/software fault, the software still provides continuous correct execution. Consider hazard conditions to software logic created by equipment wear and tear, or unexpected failures. Consider alternate approaches to minimize risk from hazards that cannot be eliminated. Such approaches include interlocks, redundancy, fail-safe design, system protection, and procedures. [Pg.53]

Hardware fault tolerance Systems must have a certain level of resilience to random hardware faults, depending on the SIL specification. This may be achieved using a combination of redundant components and sub-systems, frequent manual testing and repair and computer-automated testing ( diagnostics ). [Pg.235]

NOTE 3 It is important to note that the hardware fault tolerance requirements represent the minimum component or subsystem redundancy. Depending on the application, component failure rate and proof-testing interval, additional redundancy may be required to satisfy the SIL of the SIF according to 11.9. [Pg.59]

Hardware redundancy In hardware redundancy a set of hardware components needs to be introduced into the system to provide fault tolerance with respect to operational faults. These components are a duplication or triplication of the original set of components hence when there is no fault these are superfluous or redundant. Obviously, removal of the components in the absence of faults has no real impact on system performance. As discussed earlier, for hardware fault tolerance, the most reliable components avaUahle should be used. However, increased component reliability has hardly any impact on fault tolerance if the fault is an operational one. Hardware redundancy is more important in recovery than in prevention. [Pg.814]

Design diversity This approach is rather costly. It combines hardware and software fault tolerance in different sets of computing channels. Each channel is developed in different hardware and software in redundant mode to provide the same function. This method is deployed to identify deviation of a channel from the others. The goal is to tolerate both hardware and software design faults [7]. After developing a fault tolerant design it is necessary to validate it from a reliability point of view, discussed later. [Pg.820]

Defects or faults in any component of the loop can develop into malfunctions. Faults are not always visible to the operator immediately, but may appear in such a way that they give rise to complete loop failure. In safety-critical applications, no failure can be tolerated [3]. Redundancies in hardware and software facilitate fault recovery. So, for increased dependability fault tolerant control (PTC) is an ideal solution. In critical controls it may be disastrous to tolerate any failure of control systems. In PTC the system continues to operate with single failure in components and/or subsystems. Also in cases of critical controls, FTC will make a controlled shutdown to a safe state in a critical situation. FTC systems use the help of redundancies in hardware and software, discussed earlier, and fault diagnostics and intelligent software to monitor health and behavior of components and function blocks and take remedial action. With these tools the faults are isolated and suitable... [Pg.820]

Hardware failure and software failure are two kinds of failures encountered in programmable systems, as already discussed. In cases of hardware failure, fault tolerant designs such as redundancy could be applied. Software failure, as discussed, has to overcome certain procedures, but certain failures (design failure) could include behaviors that can be unsafe. A new technique known as system theoretic process analysis is applied in nuclear installations. This is required to identify the control requirements and then check conditions caused hy inadequate control actions such as ... [Pg.890]

Regardless of the hardware reliability calculated for the design, the Standard specifies minimum levels of redundancy coupled with given levels of fault tolerance (described by the SFF). This can be estimated as shown in Appendix 4. [Pg.63]

In the following tables m refers to the number of failures which lead to system failure. The tables provide the maximum SIL which can be claimed for eaeh SFF case. The expression m + 1 implies redundancy whereby there are (m + 1) elements and m failures are sufficient to cause system failure. The term Hardware Fault Tolerance (HFT) is commonly used. An HFT of 0 implies simplex (i.e., no failures tolerated). An HFT of one implies m out of (m + 1) (i.e., one failure tolerated) and so on. [Pg.64]

Simplex infers no redundancy and is referred to as Hardware Fault Tolerance 0... [Pg.150]

Route 2h allows the safe failure fraction requirements to lapse providing that amount of redundancy (so-called hardware fault tolerance) meets a minimum requirement AND there is adequate user-based information providing failure rate data. [Pg.314]

The simplest - and poorest - choice for fault tolerant architecture would have been a dual modular redundant system with an external human decision scheme. In case of a failure, this would activate a spare counterpart via high-priority (hardware decoded) telecommanding after behaviour evaluation of off-line data. [Pg.27]

Various types of ship-control systems are used in submarines. The ship-control system used in the Seawolf submarine represents the state of the art for such sysfems. This sysfem incorporates various features, including a fault-tolerant computer, automatic modes of control for steering, and flat-panel operator displays [23]. High-speed data buses permit the ship control to interface effectively with the data distrihution system, gyrocompass inertial sensors, and the combat system. Furthermore, hardware redundancy and performance-monitoring software permit the system to function after experiencing malfunctions of ship sensors, control electronics, and the actuation systems it controls. [Pg.83]

In the interests of availability, the centralised equipment is fault-tolerant, with active redundant l-out-of-2 and 2-out-of-3 hardware configurations used for nonsafety and safety portions of the system respectively. [Pg.177]


See other pages where Fault tolerance hardware redundancy is mentioned: [Pg.282]    [Pg.28]    [Pg.132]    [Pg.253]    [Pg.104]    [Pg.36]    [Pg.16]    [Pg.183]    [Pg.1]    [Pg.6]    [Pg.282]    [Pg.80]    [Pg.168]    [Pg.250]    [Pg.814]    [Pg.814]    [Pg.817]    [Pg.818]    [Pg.195]    [Pg.196]    [Pg.12]    [Pg.109]    [Pg.26]    [Pg.27]    [Pg.219]    [Pg.78]   
See also in sourсe #XX -- [ Pg.814 ]




SEARCH



Fault tolerance

Fault tolerance redundancy

Fault tolerant

Hardware

Hardware fault tolerance

Hardware redundancy

Redundancy

Redundant

© 2024 chempedia.info