Safety Considerations Guide

Transcription

1 Trident System Version 1.2 Safety Considerations Guide Triconex An Invensys Company

2 Information in this document is subject to change without notice. Companies, names and data used in examples herein are fictitious unless otherwise noted. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Invensys Systems, Inc Invensys Systems, Inc. All Rights Reserved. Microsoft, Windows, and Windows NT are registered trademarks of Microsoft Corporation. Modbus is a registered trademark of Modicon Corporation. Triconex is a registered trademark of Invensys Systems, Inc.n in the USA and other countries. Cause & Effect Matrix Programming Language Editor (CEMPLE), TriStation 1131, TriStation MSW, Tricon, and Trident are trademarks of Invensys Systems, Inc. in the USA and other countries. All other brands or product names may be trademarks or registered trademarks of their respective owners. Document No Printed in the United States of America.

3 Acknowledgement Triconex acknowledges the generous assistance of TÜV Rheinland/Berlin- Brandenburg in the development of this guide. Their efforts have contributed to the overall quality and integrity of the Trident system. TÜV Rheinland/Berlin-Brandenburg aims to shape technology so that it does not put people and the environment at risk but is of the greatest benefit to them. To achieve this aim, TÜV offers support during the complete life cycle of a product, from concept through development and testing to certification.

4

5 CONTENTS Preface... ix How This Guide Is Organized... ix Related Documents... x Abbreviations Used... xi How to Contact Triconex... xii Requesting Technical Support... xii Gathering Supporting Documentation... xii Contacting Triconex Technical Support... xiii Telephone... xiii Fax... xiii ... xiii Training... xiv Chapter 1 Safety Concepts... 1 Safety Overview... 2 Protection Layers... 3 SIS Factors... 4 SIL Factors... 4 Hazard and Risk Analysis... 5 Safety Integrity Levels... 6 Determining a Safety Integrity Level... 6 Example SIL Calculation... 8 Safety Life Cycle Model Safety Standards General Safety Standards DIN V DIN V VDE IEC 61508, Parts ANSI/ISA S Draft IEC 61511, parts

6 vi Application-Specific Standards DIN VDE EN 54, Part NFPA NFPA NFPA CSA C22.2 NO Chapter 2 Application Guidelines TÜV Rheinland Certification General Guidelines All Safety Systems Emergency Shutdown Systems Burner Management Systems Fire and Gas Systems Guidelines for Trident Controllers Safety-Critical Modules Safety-Shutdown Response Time and Scan Time Disabled Points Alarm Disabled Output Voter Diagnostic Download All at Completion of Project Modbus Master Functions Triconex Peer-to-Peer Communication Sending Node Receiving Node SIL3/AK5 Guidelines Additional Fire and Gas Guidelines SIL3/AK6 Guidelines Additional Fire and Gas Guidelines Project Change and Control Maintenance Overrides Using Serial Communication Additional Recommendations Chapter 3 Fault Management System Architecture System Diagnostics Types of Faults External Faults Internal Faults Operating Modes... 41

7 vii Module Diagnostics Analog Input Modules Analog Input Module Alarms Analog Output Modules Analog Output Module Field Alarms Digital Input Modules Digital Input Module Alarms Digital Output Modules Digital Output Module Alarms Pulse Input Module Pulse Input Module Alarms Solid-State Relay Output Modules Solid-State Relay Output Module Alarms Calculation for Diagnostic Fault Reporting Time Input/Output Processing I/O Module Alarms Main Processor and TriBus External Communication Semaphores MP System Attributes CM System Attributes Chapter 4 Application Development Development Guidelines TriStation Install Check Important TriStation Commands Download Change Upload and Verify Compare to Last Download Setting Scan Time Scan Time Scan Surplus Scan Overrun Sample Safety-Shutdown Programs All I/O Modules Safety-Critical Program EX01_SHUTDOWN Some I/O Modules Safety-Critical Program EX02_SHUTDOWN Defining Function Blocks Partitioned Processes Program EX03_SHUTDOWN... 69

8 viii Alarm Usage Programming Permitted Alarm Remote Access Alarm Response Time Alarm Disabled Points Alarm Appendix A Triconex Peer-to-Peer Communication Data Transfer Time Examples of Peer-to-Peer Applications Fast Send to One Triconex Node Sending Data Every Second to One Node Controlled Use of TR_USEND/TR_URCV Function Blocks Using TR_USEND/TR_URCV Function Blocks for Safety-Critical Data. 75 Sending Node #1 Parameters Receiving Node #3 Parameters Appendix B Function Blocks SYS_CRITICAL_IO Function Block Instructions for Use Structured Text SYS_SHUTDOWN Function Block Structured Text SYS_VOTE_MODE Function Block Structured Text Index... 95

9 Preface This manual provides information about safety concepts and standards that apply to the Trident controller. How This Guide Is Organized This manual is organized as follows: Chapter 1, Safety Concepts Describes safety issues, safety standards, and implementation of safety measures. Chapter 2, Application Guidelines Provides information on industry guidelines and recommendations. Chapter 3, Fault Management Discusses fault tolerance and fault detection. Chapter 4, Application Development Discusses methods for developing applications properly to avoid application faults. Appendix B, Function Blocks Describes the function blocks intended for use in safety-critical applications and shows their Structured Text code.

10 x Related Documents Related Documents The following manuals contain information that is relevant to the use of the system. Trident Planning and Installation Guide TriStation 1131 Developer's Guide for Trident Systems TriStation 1131 Getting Started for Trident Users TriStation 1131 Triconex Libraries Reference

11 Abbreviations Used xi Abbreviations Used The controller is hereafter called Trident, except in cases where the full name must be used to ensure clarity. The TriStation 1131 Developer s Workbench is hereafter called TriStation. The following list provides full names for abbreviations of safety terms used in this guide. BPCS ESD HAZOP MOC MTBF PES PFD PHA PSM RMP RRF SIL SIS SOV SRS SV Basic process control system Emergency shutdown Hazard and operability study Management of change Mean time between failure Programmable electronic system Probability to fail on demand Process hazard analysis Process safety management Risk management program Risk reduction factor Safety integrity level Safety-instrumented system Solenoid-operated valve Safety requirements specification Safety (relief) valve Preface

12 xii How to Contact Triconex How to Contact Triconex You can obtain sales information and technical support for Triconex products from any regional customer center or from corporate headquarters. To locate regional centers, go to the Global Locator page on the Triconex Web site at: Requesting Technical Support You can obtain technical support from any regional center and from offices in Irvine, California and Houston, Texas. If you require emergency or immediate response and are not a participant in the System Maintenance Program (SMP), you may incur a charge. After-hours technical support is billed at the rate specified in the current Customer Satisfaction Price List. Requests for support are prioritized as follows: Emergency requests are given the highest priority Requests from SMP participants and customers with purchase order or charge card authorization are given next priority All other requests are handled on a time-available basis Gathering Supporting Documentation Before contacting corporate technical support, please try to solve the problem by referring to the Triconex documentation. If you are unable to solve the problem, obtain the following information: Error messages and other indications of the problem Sequence of actions leading to the problem Actions taken after the problem occurred If the problem involves a Triconex controller, obtain the model numbers and revision levels for all affected items. This information can be found on the modules, in the System Log Book, or on the TriStation Diagnostic Panel. If the problem involves software, obtain the product version number by selecting the About topic from the Help menu.

13 Requesting Technical Support xiii Contacting Triconex Technical Support If possible, you should contact your regional customer center for assistance. If you cannot contact your regional center, contact technical support for the type of system you are using, either ESD systems or Turbomachinery systems. Please include the following information in your message: Your name and your company name Your location (city, state, and country) Your phone number (area code and country code, if applicable) The time you called Whether this is an emergency Note If you require emergency support and are not an SMP participant, please have a purchase order or credit card available for billing. Emergency calls are responded to on a 24-hour daily basis. Telephone Toll-free number 866-PHON IPS ( ), or Toll number Fax Send your request to the Technical Support Manager. Toll-free number , or Toll number ips.csc@invensys.com Preface

14 xiv Training Training In addition to this documentation, Triconex offers in-house and on-site training. For information on available courses, please contact your regional customer center.

15 CHAPTER 1 Safety Concepts This chapter describes background information about safety concepts and standards. Topics include: Safety Overview Hazard and Risk Analysis Safety Standards Application-Specific Standards

16 2 Safety Overview Safety Overview Modern industrial processes tend to be technically complex, involve substantial energies, and have the potential to inflict serious harm to persons or property during a mishap. The IEC standard defines safety as freedom from unacceptable risk. In other words, absolute safety can never be achieved; risk can only be reduced to an acceptable level. Safety methods to mitigate harm and reduce risk include: Changing the process or mechanical design, including plant or equipment layout Increasing the mechanical integrity of equipment Improving the basic process control system (BPCS) Developing additional or more detailed training procedures for operations and maintenance Increasing the testing frequency of critical components Using a SIS (safety-instrumented system) Installing mitigating equipment to reduce harmful consequences; for example, explosion walls, foams, impoundments, and pressure relief systems Methods that provide layers of protection should be: Independent Verifiable Dependable Designed for the specific safety risk

17 Safety Overview 3 Protection Layers The figure below shows how layers of protection can be used to reduce unacceptable risk to an acceptable level. The amount of risk reduction for each layer is dependent on the specific nature of the safety risk and the impact of the layer on the risk. Economic analysis should be used to determine the appropriate combination of layers for mitigating safety risks. Acceptable Risk Level Mechanical Integrity Inherent Process Risk SV SIS BPCS* Effect of Protection Layers on Process Risk 0 Lower Risk Process Higher Risk * BPCS Basic process control system SIS Safety-instrumented system SV Safety (relief) valve When an SIS is required, one of the following should be determined: Level of risk reduction assigned to the SIS Safety integrity level (SIL) of the SIS Typically, a determination is made according to the requirements of the ANSI/ISA S84.01 or IEC standards during a process hazard analysis (PHA). A process demand is defined as the occurrence of a process deviation that causes an SIS to transition a process to a safe state. Chapter 1 Safety Concepts

18 4 Safety Overview SIS Factors According to the ANSI/ISA S84.01 and IEC standards, the scope of an SIS is restricted to the instrumentation or controls that are responsible for bringing a process to a safe state in the event of a failure. The availability of an SIS is dependent upon: Failure rates and modes of components Installed instrumentation Redundancy Voting Diagnostic coverage Testing frequency SIL Factors A SIL can be considered a statistical representation of the availability of an SIS at the time of a process demand. A SIL is the litmus test of acceptable SIS design and includes the following factors: Device integrity Diagnostics Systematic and common cause failures Testing Operation Maintenance In modern applications, a programmable electronic system (PES) is used as the core of a SIS. The Triconex controller is a state-of-the-art PES optimized for safety-critical applications.

19 Hazard and Risk Analysis 5 Hazard and Risk Analysis In the United States, OSHA Process Safety Management (PSM) and EPA Risk Management Program (RMP) regulations dictate that a PHA be used to identify potential hazards in the operation of a chemical process and to determine the protective measures necessary to protect workers, the community, and the environment. The scope of a PHA may range from a very simple screening analysis to a complex hazard and operability study (HAZOP). A HAZOP is a systematic, methodical examination of a process design that uses a multi-disciplinary team to identify hazards or operability problems that could result in an accident. A HAZOP provides a prioritized basis for the implementation of risk mitigation strategies, such as SISs or ESDs. If a PHA determines that the mechanical integrity of a process and the process control are insufficient to mitigate the potential hazard, an SIS is required. An SIS consists of the instrumentation or controls that are installed for the purpose of mitigating a hazard or bringing a process to a safe state in the event of a process upset. A compliant program incorporates good engineering practice. This means that the program follows the codes and standards published by such organizations as the American Society of Mechanical Engineers, American Petroleum Institute, American National Standards Institute, National Fire Protection Association, American Society for Testing and Materials, and National Board of Boiler and Pressure Vessel Inspectors. Other countries have similar requirements. Chapter 1 Safety Concepts

20 6 Hazard and Risk Analysis Safety Integrity Levels The figure below shows the relationship of DIN V classes and SILs (safety integrity levels). As a required SIL increases, SIS integrity increases as measured by: System availability (expressed as a percentage) Average probability to fail on demand (PFD avg ) Risk reduction factor (RRF, reciprocal of PFD avg ) The relationship between AK class and SIL is extremely important and should not be overlooked. These designations were developed in response to serious incidents that resulted in the loss of life, and are intended to serve as a foundation for the effective selection and appropriate design of safety-instrumented systems. R i s k >10,000 SIL 4 AK 8 AK 7 Standards and Risk Measures R e d u c t I o n Percent Availability PFD avg 10,000 1,000 1, RRF SIL 3 SIL 3 SIL 2 SIL 2 SIL 1 ANSI/ISA S84.01 SIL 1 IEC AK 6 AK 5 AK 4 AK 3 AK 2 AK 1 DIN V Risk Measures Risk Standards Determining a Safety Integrity Level If a PHA (process hazard analysis) concludes that an SIS is required, ANSI/ISA S84.01 and IEC require that a target SIL be assigned. The assignment of a SIL is a corporate decision based on risk management and risk tolerance philosophy. Safety regulations require that the assignment of SILs should be carefully performed and thoroughly documented.

21 Hazard and Risk Analysis 7 Completion of a HAZOP determines the severity and probability of the risks associated with a process. Risk severity is based on a measure of the anticipated impact or consequences, including: On-site consequences Worker injury or death Equipment damage Off-site consequences Community exposure, including injury and death Property damage Environmental impact Emission of hazardous chemicals Contamination of air, soil, and water supplies Damage to environmentally sensitive areas A risk probability is an estimate of the likelihood that an expected event will occur. A risk probability is classified as high, medium, or low, and is often based on a company s or a competitor s operating experience. Several methods of converting HAZOP data into SILs are used. Methods range from making a corporate decision on all safety system installations to more complex techniques, such as an IEC risk graph. Chapter 1 Safety Concepts

22 8 Hazard and Risk Analysis Example SIL Calculation As a PES, the controller is designed to minimize its contribution to the SIL, thereby allowing greater flexibility in the SIS design. Comparison of Percent Availability and PFD R i s k R e d u c t I o n Percent Availability Risk Measures PFD Trident PES* SIL 3 SIS * Trident controller failure rates have been independently calculated by Factory Mutual System. A copy of Factory Mutual Technical Report, Calculation of the Probability of Failure-On-Demand (PFD) for the Triconex Trident System, FMRC J.I , is available upon request. Safety Integrated System Simplified Diagram of Key Elements 3 Pressure Transmitters (2oo3) Sensors TMR Controller (2oo3) PES/Logic Solver 2 Block Valves in Series (1oo2) Final Elements 3 Temperature Transmitters (2oo3)

23 Hazard and Risk Analysis 9 Equation for Calculating PFD avg for Sensors The following simplified equation may be used to calculate PFD avg for sensors (2oo3): PFD avg = (λ DU *TI) 2 where the following variables are supplied by the manufacturer: λ = failure rate DU = dangerous, undetected failure rate TI = test interval in hours Equation for Calculating PFD avg for Block Valves The following simplified equation may be used to calculate PFD avg for block valves (1oo2) in series (final elements): PFD avg = 1/3(λ DU *TI) 2 where the following variables are supplied by the manufacturer: λ = failure rate DU = dangerous, undetected failure rate TI = test interval in hours Equation for Calculating PFD avg for System The following simplified equation may be used to calculate PFD avg for a system. System PFD avg = Sensors PFD avg + Block Valves PFD avg + Controller PFD avg Chapter 1 Safety Concepts

24 10 Hazard and Risk Analysis Using the Equations λdu TI PFDResult Pressure Transmitters (2oo3) 2.28E E-04 Temperature Transmitters (2oo3) 2.85E E-04 Total for Sensors 2.56E-04 Block Valves (1oo2) 2.28E E-05 Total for Block Valves 3.33E-05 Trident Controller PFD avg for System 1.00E E-04 To determine the SIL, compare the calculated PFD avg to the figure on page 8. In this example, the system is acceptable as an SIS for use in SIL3 applications. Safety Life Cycle Model The necessary steps for designing an SIS from conception through decommissioning are described in the safety life cycle. Before the safety life cycle model is implemented, the following requirements should be met: Hazard and operability study has been completed SIS requirement has been determined Target SIL has been determined

25 Hazard and Risk Analysis 11 Safety Life Cycle Model Start Design conceptual process Perform process hazard analysis and risk assessment Apply non-sis protection layers to prevent identified hazards or reduce risk Develop safety requirements document Perform SIS conceptual design and verify it meets the SRS Perform SIS detail design Establish operation and maintenance procedure Pre-start-up safety review assessment SIS start-up operation, maintenance, periodic functional testing Exit No SIS required? Yes Define target SIL SIS installation, commissioning, and pre-startup acceptance test Conceptual process design Modify Modify or decommission SIS? Decommission SIS decommissioning S84.01 Concern Chapter 1 Safety Concepts

26 12 Hazard and Risk Analysis PES Steps in a Safety Life Cycle: 1 Develop a safety requirement specification. An SRS consists of safety functional requirements and safety integrity requirements. An SRS can be a collection of documents or information. Safety functional requirements specify the logic and actions to be performed by an SIS and the process conditions under which actions are initiated. These requirements include such items as consideration for manual shutdown, loss of energy source, etc. Safety integrity requirements specify a SIL and the performance required for executing SIS functions. Safety integrity requirements include: Required SIL for each safety function Requirements for diagnostics Requirements for maintenance and testing Reliability requirements if the spurious trips are hazardous 2 For conceptual design, an engineer should: Define the SIS architecture to ensure the SIL is met; e.g. voting 1oo1, 1oo2, 2oo2, 2oo3 Define the logic solver to meet the highest SIL if different SIL levels are required in a single logic solver Select a functional test interval to achieve the SIL Verify the conceptual design against the SRS 3 Develop a detail design including: General requirements SIS logic solver Field devices Interfaces Energy sources System environment Application logic requirements Maintenance or testing requirements

27 Hazard and Risk Analysis 13 Some key ANSI/ISA S84.01 requirements are: The logic solver shall be separated from the basic process control system. Sensors for SIS shall be separated from the sensors for the BPCS. The logic system vendor shall provide: MTBF data Covert failure listing Frequency of occurrence of identified covert failures Triconex controllers do not contain covert failures (undiagnosed dangerous faults) that are statistically significant Each individual field device shall have its own dedicated wiring to the system I/O. Using a field bus is not allowed! A control valve from the BPCS shall not be used as a single final element for SIL3. The operator interface may not be allowed to change the SIS application software. Maintenance overrides shall not be used as a part of application software or operating procedures. When online testing is required, test facilities shall be an integral part of the SIS design. 4 Develop a pre-start-up acceptance test procedure that provides a fully functional test of the SIS to verify conformance with the SRS. 5 Before startup, establish operational and maintenance procedures to ensure that the SIS functions comply with the SRS throughout the SIS operational life, including: Training Documentation Operating procedures Maintenance program Testing and preventive maintenance Functional testing Documentation of functional testing 6 Before start-up, complete a safety review. Chapter 1 Safety Concepts

28 14 Hazard and Risk Analysis 7 Define procedures for the following: Start-up Operations Maintenance, including administrative controls and written procedures that ensure safety if a process is hazardous while an SIS function is being bypassed Training that complies with national regulations (e.g., OSHA 29 CFR ) Functional testing to detect covert faults that prevent the SIS from operating according to the SRS SIS testing, including: Sensors Logic solver Final elements (e.g., shutdown valves, motors, etc.) 8 To ensure that no unauthorized changes are made to an application, as mandated by OSHA 29 CFR , follow management of change (MOC) procedures. 9 To ensure proper review, decommission an SIS before its permanent retirement from active service.

29 Safety Standards 15 Safety Standards Over the past several years, there has been rapid movement in many countries to develop standards and regulations to minimize the impact of industrial accidents on citizens. The standards described below apply to typical applications. General Safety Standards DIN V In Germany, the methodology of defining the risk to individuals is established in DIN V 19250, Control Technology; Fundamental Safety Aspects To Be Considered for Measurement and Control Equipment. DIN V establishes the concept that safety systems should be designed to meet designated classes, Class 1 (AK1) through Class 8 (AK8). The choice of the class is dependent on the level of risk posed by the process. DIN V attempts to force users to consider the hazards involved in their processes and to determine the integrity of the required safety-related system. DIN V VDE 0801 As the use of programmable electronic systems in safety system designs has become prevalent, it is necessary to determine whether the design of a PES is sufficiently rigorous for the application and for the DIN V class. DIN V VDE 0801, Principles for Computers in Safety-Related Systems, sets forth the following specific measures to be used in evaluating a PES: Design Coding (system level) Implementation and integration Validation Each measure is divided into specific techniques that can be thoroughly tested and documented by independent persons. Thus, DIN V VDE 0801 provides a means of determining if a PES meets certain DIN V classes. Chapter 1 Safety Concepts

30 16 Safety Standards IEC 61508, Parts 1 7 The IEC standard, Functional Safety: Safety Related Systems, is an international standard designed to address a complete SIS for the process, transit, and medical industries. The standard introduces the concept of a safety life cycle model (see figure on page 10) to illustrate that the integrity of an SIS is not limited to device integrity, but is also a function of design, operation, testing, and maintenance. The standard includes 4 SILs that are indexed to a specific probability-to-fail-ondemand (PFD) (see figure on page 6). A SIL assignment is based on the required risk reduction as determined by a PHA. ANSI/ISA S84.01 ANSI/ISA S is the United States standard for safety systems in the process industry. The SIL classes from IEC are used and the DIN V relationships are maintained. ANSI/ISA S does not include the highest SIL class, SIL 4. The S84 Committee determined that SIL 4 is applicable for medical and transit systems in which the only layer of protection is the safetyinstrumented layer. In contrast, the process industry can integrate many layers of protection in the process design. The overall risk reduction from these layers of protection is equal to or greater than that of other industries. Draft IEC 61511, parts 1 3 The IEC standard, Functional Safety: Safety Instrumented Systems for the Process Industry Sector, is an international standard designed to be used as a companion to IEC IEC is intended primarily for manufacturers and suppliers of devices. IEC is intended for SIS designers, integrators, and users in the process-control industry.

31 Safety Standards 17 Application-Specific Standards DIN VDE 0116 DIN VDE 0116 Electrical Equipment Of Furnaces, outlines the German requirements for burner management applications. EN 54, Part 3 EN 54, Part 3, Components of Automatic Fire Detection System: Control and Indicating Equipment, outlines the European requirements for fire detection systems. NFPA 72 NFPA 72, National Fire Alarm Code, outlines the United States requirements for fire alarm systems. NFPA 8501 NFPA 8501, Standard for Single Burner Boiler Operation, outlines the United States requirements for operations using single burner boilers. NFPA 8502 NFPA 8502, Standard for the Prevention of Furnace Explosions/Implosions in Multiple Burner Boilers, outlines the United States requirements for operations using multiple burner boilers. CSA C22.2 NO 199 CSA C22.2 NO 199, Combustion Safety Controls and Solid-State Igniters for Gas and Oil-Burning Equipment, outlines the Canadian requirements for burner management applications. Chapter 1 Safety Concepts

32 18 Safety Standards

33 CHAPTER 2 Application Guidelines This chapter provides information on industry guidelines. Topics include: TÜV Rheinland Certification General Guidelines Guidelines for Trident Controllers

34 20 TÜV Rheinland Certification TÜV Rheinland Certification When used as a PES in an SIS, the Trident controller and its companion programming workstation, the TriStation 1131 Developer s Workbench, have been certified by TÜV Rheinland/Berlin-Brandenburg to meet the requirements of DIN AK5-AK6 and IEC SIL3. If these standards apply to your application, compliance with the guidelines described in this chapter is highly recommended. General Guidelines All Safety Systems This section describes standard industry guidelines that apply to: All safety systems Emergency shutdown (ESD) systems Fire and gas systems Burner management systems The following general guidelines apply to all user-written safety applications and procedures: Functional testing is recommended to verify the correct design and operation. After a safety system is commissioned, no changes to the system software (operating system, I/O drivers, diagnostics, etc.) are allowed without type approval and re-commissioning. Any changes to the application or the control application should be made under strict change-control procedures. For more information on change-control procedures, see Project Change and Control on page 30. All changes should be thoroughly reviewed, audited, and approved by a safety change control committee or group. After an approved change is made, it should be archived. In addition to printed documentation of the application, two copies of the application should be archived on an electronic medium that is writeprotected to avoid accidental changes.

35 General Guidelines 21 Under certain conditions, a PES may be run in a mode that allows an external computer or operator station to write to system attributes. This is normally done by means of a communication link. The following guidelines apply to writes of this type: Serial communication should use Modbus or another approved protocol with CRC checks. Serial communication should not be allowed to write directly to output points For information about writes to safety-related variables that result in disabling safety action, see External Communication on page 47. PID and other control algorithms should not be used for safety-related functions. Each control function should be checked to verify that it does not provide a safety-related function. An SIS PES should be wired and grounded according to the procedures defined by the manufacturer. Emergency Shutdown Systems The safe state of the plant should be a de-energized or low (0) state. For ESD functions, it is recommended that the hardware devices connected to PES outputs should be made of fail-safe components or should have two separate, independent shutdown paths that are periodically inspected. Burner Management Systems The safe state of the plant should be a de-energized or low (0) state. When a safety system is required to conform with the DIN 0116 standard for electrical equipment in furnaces, PES throughput time should ensure that a safe shutdown can be performed within 1 second after a problem in the process is detected. Chapter 2 Application Guidelines

36 22 General Guidelines Fire and Gas Systems Fire and gas applications typically do not have a safe state and should operate continuously to provide protection. The following industry guidelines apply: If inputs and outputs are energized to mitigate a problem, a PES system should detect and alarm open and short circuits in the wiring between the PES and the field devices. An entire PES system should have redundant power supplies. Also, the power supplies that are required to activate critical outputs and read safetycritical inputs should be redundant. All power supplies should be monitored for proper operation. De-energized outputs may be used for normal operation. To initiate action to mitigate a problem, the outputs are energized. This type of system should monitor the critical output circuits to ensure that they are properly connected to the end devices.

37 Guidelines for Trident Controllers 23 Guidelines for Trident Controllers The following topics relate to industry guidelines that are specific to Trident controllers when used as a PES in an SIS: Safety-critical modules Safe shutdown Programming lockout alarm Remote access alarm Scan time and response time alarm Disabled points alarm Disabled output voters Download all Modbus master functions Triconex Peer-to-Peer communication SIL3/AK5 guidelines SIL3/AK5 fire and gas guidelines SIL3/AK6 guidelines SIL3/AK6 fire and gas guidelines Project change and control Chapter 2 Application Guidelines

38 24 Guidelines for Trident Controllers Safety-Critical Modules It is recommended that only the following modules be used for safety-critical applications: Main Processor Module Communication Module Analog Input Module Analog Output Module Digital Input Module Digital Output Module Pulse Input Module The Solid-State Relay Output Module is recommended for non-safety-critical points only. Safety-Shutdown A safety application should include a network that initiates a safe shutdown of the process being controlled when a controller operates in a degraded mode for a specified maximum time. The Triconex Library provides two function blocks to simplify programming a safety-shutdown application: SYS_SHUTDOWN and SYS_CRITICAL_IO. To see the Structured Text code for these function blocks, see Appendix B, Function Blocks. For more information on safety-shutdown networks, see Sample Safety- Shutdown Programs on page 57. Response Time and Scan Time Scan time must be set below 50 percent of the required response time. If scan time is greater than 50 percent, an alarm should be triggered. Disabled Points Alarm A project should not contain disabled points unless there is a specific reason for disabling them, such as initial testing. An alarm should be available to alert the operator that a point is disabled.

39 Guidelines for Trident Controllers 25 Disabled Output Voter Diagnostic A safety application must not disable the output voter diagnostic. Download All at Completion of Project When development and testing of a safety application is completed, use the Download All command on the Control Panel to completely re-load the application to the controller. Modbus Master Functions Modbus Master functions are designed for use with non-critical I/O points only. These functions should not be used for safety-critical I/O points or for transferring safety-critical data using the MBREAD and MBWRITE functions. Triconex Peer-to-Peer Communication Triconex Peer-to-Peer communication enables Triconex controllers (also referred to as nodes) to send and receive information. You should use a redundant Peer-to- Peer network for safety-critical data. If a node sends critical data to another node that makes safety-related decisions, you must ensure that the application on the receiving node can determine whether it has received new data. If new data is not received within the time-out period (equal to half of the processtolerance time), the application on the receiving node should be able to determine the action to take. The specific actions depend on the unique safety requirements of your process. The following sections summarize actions typically required by Peer-to-Peer send and receive functions. Sending Node The actions typically required in the sending application include the following: To send data as quickly as possible, the sending node must set the SENDFLG parameter in the send function to true (1) to ensure new data is sent following the acknowledgment that data was received by the receiving node. Chapter 2 Application Guidelines

40 26 Guidelines for Trident Controllers A TR_USEND-type function block must include a diagnostic variable that is changed each time data is sent. By monitoring this variable, the receiving node can determine whether it has received new data. This diagnostic variable is required because the communication path is not triplicated like the I/O system. The number of TR_USEND functions in an application must be less than or equal to ten because the controller only initiates ten TR_USEND functions per scan. The status of the TR_USEND and TR_PORT_STATUS functions should be monitored in case a network problem requires operator intervention. Receiving Node The actions typically required in the receiving application include the following: If new data is not received within the time-out period, take one of the following actions: Use the last data received for safety-related decisions Use default values for safety-related decisions in the application A diagnostic variable in a TR_USEND-type function block that changes with each new message should be monitored to determine whether a new message has been received. The status of the TR_URCV and TR_PORT_STATUS functions should be monitored in case a network problem requires operator intervention. For information on data transfer time and examples of how to use Peer-to-Peer functions to transfer safety-critical data, see Appendix A, Triconex Peer-to-Peer Communication on page 71.

41 Guidelines for Trident Controllers 27 SIL3/AK5 Guidelines For SIL3/AK5 applications, the following guidelines should be followed: If non-approved modules are used, the inputs and outputs should be checked to verify that they do not affect safety-critical functions of the controller. Two modes control write operations from external hosts: Remote Mode When true, external hosts, such as Modbus master, DCS, etc., can write to aliased variables in the controller. When false, writes are prohibited. Program Mode When true, changes can be made that modify the behavior of the currently running application. For example, Download All, Download Change, declaring variables, enabling/disabling variables, changing values of variables and scan time, etc. Remote mode and program mode are independent of each other. In safety applications, operation in these modes is not recommended. In other words, write operations to the controller from external hosts should be prohibited. If remote mode or program mode becomes true, the application should include the following safeguards: When remote mode is true: The application should turn on an alarm. For example, if using the SYS_SHUTDOWN function block, the ALARM_REMOTE_ACCESS output could be used. Verify that aliased variables adhere to the guidelines described in Maintenance Overrides on page 32. When program mode is true: The application should turn on an alarm. For example, if using the SYS_SHUTDOWN function block, the ALARM_PROGRAMMING_PERMITTED output could be used. Wiring and grounding procedures outlined in the Trident Planning and Installation Guide should be followed. Maintenance instructions outlined in the Trident Planning and Installation Guide should be followed. If degradation to dual mode occurs, repair efforts should be timely. To ensure maximum availability, limits for maximum time in degraded mode should not be imposed. Chapter 2 Application Guidelines

42 28 Guidelines for Trident Controllers If degradation to single mode occurs, continued operation without repair should be limited to 72 hours (three days). The GATENB function allows external hosts to write selected aliased variables even when the remote mode is false. A network using the GATENB function should be thoroughly validated to ensure that only the intended aliased variable range is used. Peer-to-Peer communication must be programmed according to the recommendations in Triconex Peer-to-Peer Communication on page 25. Additional Fire and Gas Guidelines Analog input cards with current loop terminations should be used to read digital inputs. Opens and shorts in the wiring to the field devices should be detectable. The Triconex library function, LINEMNTR, should be used to simplify application development. A controller should be powered by two independent sources. If degradation to dual mode or single mode occurs, repairs should be timely. To ensure maximum availability, limits for maximum time in degraded mode should not be imposed.

43 Guidelines for Trident Controllers 29 SIL3/AK6 Guidelines For SIL3/ AK6 applications, the following guidelines should be followed: DIN V VDE 19250/AK6 applications that require continued operation after detecting an output failure must have a secondary means of operating the output. A secondary means may be an external group relay or a single point on an independent output module that controls a group of outputs. If a relay is used, it should be checked at least every six months, manually or automatically. If non-approved modules are used, the inputs and outputs should be checked to verify that they do not affect safety-critical functions of the controller. Two modes control write operations from external hosts: Remote Mode When true, external hosts, such as Modbus master, DCS, etc., can write aliased data in the controller. When false, writes are prohibited. Program Mode When true, changes can be made that modify the behavior of the currently running application. For example, Download All, Download Change, declaring variables, enabling/disabling variables, changing values of variables and scan time, etc. Remote mode and program mode are independent of each other. In safety applications, operation in these modes is not recommended. In other words, write operations to the controller from external hosts should be prohibited. If remote mode or program mode becomes true, the application should include the following safeguards: When remote mode is true: The application should turn on an alarm. For example, if using the SYS_SHUTDOWN function block, the ALARM_REMOTE_ACCESS output could be used. Verify that aliased variables adhere to the guidelines described in Maintenance Overrides on page 32. When program mode is true: The application should turn on an alarm. For example, if using the SYS_SHUTDOWN function block, the ALARM_PROGRAMMING_PERMITTED output could be used. Wiring and grounding procedures outlined in the Trident Planning and Installation Guide should be followed. Chapter 2 Application Guidelines

44 30 Guidelines for Trident Controllers Maintenance instructions outlined in the Trident Planning and Installation Guide should be followed. If degradation to dual mode occurs, repair efforts should be timely. To ensure maximum availability, limits for maximum time in degraded mode should not be imposed. If degradation to single mode occurs, continued operation without repair should be limited to 1 hour. The GATENB function allows external hosts to write selected aliased variables even when the remote mode is false. A network using the GATENB function should be thoroughly validated to ensure that only the intended aliased variable range is used. Peer-to-Peer communication must be programmed according to the recommendations in Triconex Peer-to-Peer Communication on page 25. Additional Fire and Gas Guidelines Project Change and Control Analog input cards with current loop terminations should be used to read digital inputs. Opens and shorts in the wiring to the field devices should be detectable. The Triconex library function, LINEMNTR, should be used to simplify application development. A controller should be powered by two independent sources. If degradation to dual mode or single mode occurs, repairs should be timely. To ensure maximum availability, limits for maximum time in degraded mode should not be imposed. A change to a project, however minor, should comply with the guidelines of your organization s Safety Change Control Committee (SCCC). The following steps are recommended: 1 Generate a change request defining all changes and reasons for changes, then obtain approval for the changes from the Safety Change Control Committee. 2 Develop a specification for changes, including a test specification, then obtain approval for the specification from the SCCC. 3 Make the appropriate changes to the project, including those related to design, operation, or maintenance documentation.

45 Guidelines for Trident Controllers 31 4 To verify that the configuration in the controller matches the last downloaded configuration, use the Upload and Verify command on the Control Panel. For details, see Upload and Verify in the TriStation 1131 Developer's Guide. 5 Compare the configuration in your project with the configuration that was last downloaded to the controller by printing the Configuration Differences report from the Configuration editor. For details, see Compare to Last Download in the TriStation 1131 Developer's Guide. 6 Print all logic elements and verify that the changes to networks within each element do not affect other sections of the application. 7 Test the changes according to the test specification by using the Emulator Control Panel. 8 Write a test report. 9 Review and audit all changes and test results with the SCCC. 10 When approved by the SCCC, download the changes to the controller. You may make minor changes online only if the changes are absolutely necessary and are tested thoroughly. To enable a Download Change command, select the Enable Programming option in the Set Programming Mode dialog box on the Control Panel if it is not already selected. Note Changing the operating mode to PROGRAM should generate an alarm to remind the operator to return the operating mode to run as soon as possible after the Download Change. For more information, see Programming Permitted Alarm on page Save the downloaded project in TriStation and back up the project. 12 Archive two copies of the project file and all associated documentation. Chapter 2 Application Guidelines

46 32 Guidelines for Trident Controllers Maintenance Overrides Three methods can be used to check safety-critical devices connected to controllers: Special switches are connected to inputs to a controller that deactivate the actuators and sensors undergoing maintenance. The maintenance condition is handled in the logic of the control application. Sensors and actuators are electrically disconnected from a controller and manually checked using special measures. Serial communication to a controller activates the maintenance override condition. This method is useful when space is limited and the maintenance console should be integrated with the operator display. Using Serial Communication For maintenance overrides, two options for serial connection are available: DCS connection using Modbus RTU protocol (or another approved serial protocol). TriStation PC connection, which requires additional, industry-standard safety measures in a controller to prevent downloading a program change during maintenance intervals. For more information on TriStation, see Alarm Usage on page 70.

47 Guidelines for Trident Controllers 33 Design Requirements The following table describes design requirements for handling maintenance overrides when using serial communication. Design Requirements Control program logic and the controller configuration determine whether the desired signal can be overridden Control program logic and/or system configuration specify whether simultaneous overriding in independent parts of the application is acceptable Controller activates the override. The operator should confirm the override condition Direct overrides on inputs and outputs are not allowed, but should be checked and implemented in relation to the application. Multiple overrides in a controller are allowed as long as only one override applies to each safetycritical group. The controller alarm should not be overridden DCS warns the operator about an override condition. The operator continues to receive warnings until the override is removed A second way to remove the maintenance override condition should be available If urgent, a maintenance engineer may remove the override using a hard-wired switch DCS Project Engineer, Commissioner Project Engineer Operator, Maintenance Engineer Project Engineer Project Engineer, Commissioner Project Engineer Responsible Person TriStation Project Engineer, Commissioner Project Engineer, Type Approval Maintenance Engineer, Type Approval Project Engineer, Type Approval N/A Maintenance Engineer, Type Approval Chapter 2 Application Guidelines

48 34 Guidelines for Trident Controllers Design Requirements During an override, proper operating measures should be implemented. The time span for overriding should be limited to one shift (typically no longer than 8 hours). A maintenance override switch (MOS) light on the operator console should be provided (one per a controller or process unit) DCS Project Engineer, Commissioner, DCS, TriStation Responsible Person TriStation Operating Requirements The following table describes operating requirements for handling maintenance overrides when using serial communication. Operating Requirements DCS Responsible Person TriStation 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 Operator, Maintenance Engineer Operator, Maintenance Engineer Operator, Maintenance Engineer Maintenance Engineer, Type Approval Maintenance Engineer, Type Approval Maintenance Engineer