Safety Considerations Guide for Triconex General ... - ICEWeb
Safety Considerations Guide for Triconex General ... - ICEWeb Safety Considerations Guide for Triconex General ... - ICEWeb
26 Chapter 2 Application Guidelines Table 4 describes the operating requirements for handling maintenance overrides when using Triconex communication capabilities. Table 4 Operating Requirements for Maintenance Override Handling Operating Requirements Maintenance overrides are enabled for an entire controller or for a subsystem (process unit). Controller activates an override. The operator should confirm the override condition. Controller removes an override. DCS Operator, Maintenance Engineer Operator, Maintenance Engineer Operator, Maintenance Engineer Responsible Person TriStation 1131 Software Maintenance Engineer, Type Approval Maintenance Engineer, Type Approval Maintenance Engineer Additional Recommendations These procedures are recommended in addition to the recommendations described in the tables on page 25 and page 26: • A DCS program should regularly verify that no discrepancies exist between the override command signals issued by a DCS and override-activated signals received by a DCS from a PES. This figure shows the procedure: Safety-Instrumented System Controller Sensors Safeguarding Application Program Actuators Hard- Wired Switch Maintenance Override Handling (Application Program) Operator Warning Distributed Control System Inputs Engineering Workstation Figure 6 PES Block Diagram Safety Considerations Guide for Triconex General Purpose v2 Systems
Guidelines for Triconex Controllers 27 • Use of the maintenance override capability should be documented in a DCS or TriStation 1131 log. The documentation should include: — Begin- and end-time stamps of the maintenance override. — Identification of the maintenance engineer or operator who activates a maintenance override. If the information cannot be printed, it should be entered in a workpermit or maintenance log. — Tag name of the signal being overridden. — Communication packages that are different from a type-approved Modbus should include CRC, address check, and check of the communication time frame. — Loss of communication should lead to a warning to the operator and maintenance engineer. After loss of communication, a time-delayed removal of the override should occur after a warning to the operator. • For more information about maintenance override operation, please see the TÜV web site at http://www.tuv-fs.com/m_o202.pdf. Safety Controller Boundary The boundary of the safety controller includes the External Termination Panels (ETPs) and interconnecting cables. Triconex safety controllers must be used with approved ETPs and cables only. The use of unapproved, unauthorized cables and/or ETPs compromises the TÜV safety certification and potentially the ability of the logic solver to respond to safety demands. False trips resulting from the use of unapproved components can cause end-user economic loss. CAUTION When using fanned-out interface cables or third-party ETPs—such as those from P&F or MTL—please consult the Invensys Global Customer Support (GCS) center for the safety-boundary impact of using such cables or ETPs. Background IEC 61508 and IEC 61511 define a programmable electronic Safety Instrumented System (SIS) as consisting of sensors, logic solvers, and final control elements, as shown in this figure. Sensors Logic Solver Final Elements Figure 7 Simplified SIS Together, these elements implement Safety Instrumented Functions (SIF) of the target Safety Integrity Level (SIL). In order to implement a safety-certified SIF, the system designer must choose safety-certified loop elements, including sensors, final elements, logic solvers, and other interconnecting components. Safety Considerations Guide for Triconex General Purpose v2 Systems
- Page 1 and 2: Triconex General Purpose v2 Systems
- Page 3 and 4: Contents Preface vii Summary of Sec
- Page 5 and 6: Contents v Partitioned Processes. .
- Page 7 and 8: Preface This guide provides informa
- Page 9 and 10: Preface ix • All other requests a
- Page 11 and 12: 1 Safety Concepts Overview 2 Hazard
- Page 13 and 14: Overview 3 Protection Layers Method
- Page 15 and 16: Hazard and Risk Analysis 5 Hazard a
- Page 17 and 18: Hazard and Risk Analysis 7 Sample S
- Page 19 and 20: Hazard and Risk Analysis 9 Safety L
- Page 21 and 22: Hazard and Risk Analysis 11 • Eac
- Page 23 and 24: Safety Standards 13 CAN/CSA-C22.2 N
- Page 25 and 26: 2 Application Guidelines Overview 1
- Page 27 and 28: General Guidelines 17 General Guide
- Page 29 and 30: Guidelines for Triconex Controllers
- Page 31 and 32: Guidelines for Triconex Controllers
- Page 33 and 34: Guidelines for Triconex Controllers
- Page 35: Guidelines for Triconex Controllers
- Page 39 and 40: Guidelines for Triconex Controllers
- Page 41 and 42: 3 Fault Management Overview 32 Syst
- Page 43 and 44: System Diagnostics 33 System Diagno
- Page 45 and 46: Operating Modes 35 Operating Modes
- Page 47 and 48: Module Diagnostics 37 Analog Output
- Page 49 and 50: Module Diagnostics 39 Calculation f
- Page 51 and 52: Module Diagnostics 41 External Comm
- Page 53 and 54: 4 Application Development Developme
- Page 55 and 56: Development Guidelines 45 Array Ind
- Page 57 and 58: Setting Scan Time 47 application. T
- Page 59 and 60: Sample Safety-Shutdown Programs 49
- Page 61 and 62: Sample Safety-Shutdown Programs 51
- Page 63 and 64: Sample Safety-Shutdown Programs 53
- Page 65 and 66: Sample Safety-Shutdown Programs 55
- Page 67 and 68: Sample Safety-Shutdown Programs 57
- Page 69 and 70: Alarm Usage 59 Alarm Usage To imple
- Page 71 and 72: A Triconex Peer-to-Peer Communicati
- Page 73 and 74: Data Transfer Time 63 Data Transfer
- Page 75 and 76: Data Transfer Time 65 A typical dat
- Page 77 and 78: Examples of Peer-to-Peer Applicatio
- Page 79 and 80: B HART Communication Overview 70 HA
- Page 81 and 82: HART Position Paper from TÜV Rhein
- Page 83 and 84: HART Position Paper from TÜV Rhein
- Page 85 and 86: HART Position Paper from TÜV Rhein
<strong>Guide</strong>lines <strong>for</strong> <strong>Triconex</strong> Controllers 27<br />
• Use of the maintenance override capability should be documented in a DCS or<br />
TriStation 1131 log. The documentation should include:<br />
— Begin- and end-time stamps of the maintenance override.<br />
— Identification of the maintenance engineer or operator who activates a maintenance<br />
override. If the in<strong>for</strong>mation cannot be printed, it should be entered in a workpermit<br />
or maintenance log.<br />
— Tag name of the signal being overridden.<br />
— Communication packages that are different from a type-approved Modbus should<br />
include CRC, address check, and check of the communication time frame.<br />
— Loss of communication should lead to a warning to the operator and maintenance<br />
engineer. After loss of communication, a time-delayed removal of the override<br />
should occur after a warning to the operator.<br />
• For more in<strong>for</strong>mation about maintenance override operation, please see the TÜV web<br />
site at http://www.tuv-fs.com/m_o202.pdf.<br />
<strong>Safety</strong> Controller Boundary<br />
The boundary of the safety controller includes the External Termination Panels (ETPs) and<br />
interconnecting cables. <strong>Triconex</strong> safety controllers must be used with approved ETPs and cables<br />
only. The use of unapproved, unauthorized cables and/or ETPs compromises the TÜV safety<br />
certification and potentially the ability of the logic solver to respond to safety demands. False<br />
trips resulting from the use of unapproved components can cause end-user economic loss.<br />
CAUTION<br />
When using fanned-out interface cables or third-party ETPs—such as<br />
those from P&F or MTL—please consult the Invensys Global Customer<br />
Support (GCS) center <strong>for</strong> the safety-boundary impact of using such cables<br />
or ETPs.<br />
Background<br />
IEC 61508 and IEC 61511 define a programmable electronic <strong>Safety</strong> Instrumented System (SIS) as<br />
consisting of sensors, logic solvers, and final control elements, as shown in this figure.<br />
Sensors<br />
Logic<br />
Solver<br />
Final<br />
Elements<br />
Figure 7<br />
Simplified SIS<br />
Together, these elements implement <strong>Safety</strong> Instrumented Functions (SIF) of the target <strong>Safety</strong><br />
Integrity Level (SIL). In order to implement a safety-certified SIF, the system designer must<br />
choose safety-certified loop elements, including sensors, final elements, logic solvers, and other<br />
interconnecting components.<br />
<strong>Safety</strong> <strong>Considerations</strong> <strong>Guide</strong> <strong>for</strong> <strong>Triconex</strong> <strong>General</strong> Purpose v2 Systems
Change language