Professional Documents
Culture Documents
March 2007
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 Triconex. 20062007 by Invensys Systems, Inc. All rights reserved. Triconex, Tricon, Trident, TriStation 1131, TriStation MSW, and CEMPLE are trademarks of Invensys plc, its subsidiaries and affiliates. All other brands may be trademarks of their respective owners. Acknowledgement Triconex acknowledges the generous assistance of TV Rheinland/Berlin-Brandenburg in the development of this guide. Their efforts have contributed to the overall quality and integrity of the Tricon and Trident systems. TV 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, TV offers support during the complete life cycle of a product, from concept through development and testing to certification.
Contents
Preface
vii
Summary of Sections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii Abbreviations Used. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii Product and Training Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix We Welcome Your Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Chapter 1
Safety Concepts
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Protection Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 SIS Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 SIL Factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Hazard and Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Safety Integrity Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Safety Life Cycle Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Safety Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 General Safety Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Application-Specific Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Chapter 2
Application Guidelines
15
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 TV Rheinland Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 All Safety Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Emergency Shutdown Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Burner Management Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Fire and Gas Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Guidelines for Tricon Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Safety-Critical Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Safety-Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Response Time and Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Disabled Points Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Disabled Output Voter Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Download All at Completion of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Modbus Master Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Triconex Peer-to-Peer Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
iv
Contents
SIL3/AK5 Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 AK6 Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Periodic Offline Test Interval Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Project Change and Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Maintenance Overrides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Chapter 3
Fault Management
31
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 System Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Types of Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 External Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Internal Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Operating Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Module Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Digital Input (DI) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Digital Output (DO) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Analog Input (AI) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Analog Output (AO) Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Pulse Input (PI) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Relay Output (RO) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Input/Output Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Main Processor and TriBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 External Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Chapter 4
Application Development
41
Development Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Triconex Product Alert Notices (PANs). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Safety and Control Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 VAR_IN_OUT Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Array Index Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Infinite Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Important TriStation Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Download Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Verify Last Download to the Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Compare to Last Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Setting Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Scan Surplus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Sample Safety-Shutdown Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 When All I/O Modules Safety-Critical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 When Some I/O Modules Are Safety-Critical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Defining Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Partitioned Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Alarm Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Contents
Programming Permitted Alarm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Remote Access Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Response Time and Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Disabled Points Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
59
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Data Transfer Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Estimating Memory for Peer-to-Peer Data Transfer Time. . . . . . . . . . . . . . . . . . . . . . 61 Estimating the Data Transfer Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Examples of Peer-to-Peer Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Example 1: Fast Send to One Triconex Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Example 2: Sending Data Every Second to One Node . . . . . . . . . . . . . . . . . . . . . . . . . 64 Example 3: Controlled Use of SEND/RECEIVE Function Blocks . . . . . . . . . . . . . . . 64 Example 4: Using SEND/RECEIVE Function Blocks for Safety-Critical Data. . . . . 65
67
Index
87
vi
Contents
Preface
This guide provides information about safety concepts and standards that apply to the Tricon controller. This document replaces all previous versions of the Safety Considerations Guide for Tricon Systems.
Summary of Sections
Chapter 1, Safety ConceptsDescribes safety issues, safety standards, and implementation of safety measures. Chapter 2, Application GuidelinesProvides information on industry guidelines and recommendations. Chapter 3, Fault ManagementDiscusses fault tolerance and fault detection. Chapter 4, Application DevelopmentDiscusses methods for developing applications properly to avoid application faults. Appendix A, Triconex Peer-to-Peer CommunicationProvides examples of using Triconex Peer-to-Peer function blocks to transfer data between applications. Appendix B, Safety-Critical Function BlocksDescribes the function blocks intended for use in safety-critical applications and shows their Structured Text code.
Related Documents
Communication Guide for Tricon v9v10 Systems Field Terminations Guide for Tricon v9v10 Systems Planning and Installation Guide for Tricon v9v10 Systems Developers Guide for TriStation 1131, v4.2 TriStation 1131 Libraries Reference
Abbreviations Used
The controller is hereafter called Tricon, except in cases where the full name must be used to ensure clarity. The TriStation 1131 Developers Workbench is hereafter called TriStation. The following list provides full names for abbreviations of safety terms used in this guide.
viii
Preface
Basic process control system Emergency shutdown Hazard and operability study Management of change Mean time between failure Programmable electronic system Average probability of failure to perform IES design function on demand Process hazard analysis Process safety management Risk management program Risk reduction factor Safe failure fraction Safety integrity level Safety-instrumented system Solenoid-operated valve Safety requirements specification Safety (relief) valve
Preface
ix
Technical Support
Customers in the U.S. and Canada can obtain technical support from the Customer Satisfaction Center (CSC) at the numbers below. International customers should contact their regional support center. Requests for support are prioritized as follows: Emergency requests are given the highest priority Requests from participants in the System Watch Agreement (SWA) and customers with purchase order or charge card authorization are given next priority All other requests are handled on a time-available basis
If you require emergency or immediate response and are not an SWA participant, you may incur a charge. Please have a purchase order or credit card available for billing. Telephone Toll-free number 866-746-6477, or Toll number 508-549-2424 (outside U.S.) Fax Toll number Web Site http://customernet.triconex.com (registration required) E-mail ips.csc@ips.invensys.com 508-549-4999
Preface
Send e-mail to us at: triconextechpubs@ips.invensys.com Please keep in mind that this e-mail address is only for documentation feedback. If you have a technical problem or question, please contact the Customer Satisfaction Center. See Technical Support (page ix) for contact information. Or, you can write to us at: Attn: Technical Publications Triconex 15345 Barranca Parkway Irvine, CA 92618 Thank you for your feedback.
1
Safety Concepts
Overview Hazard and Risk Analysis Safety Standards Application-Specific Standards 2 5 12 13
Chapter 1
Safety Concepts
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 61508 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 safety-instrumented system (SIS) Installing mitigating equipment to reduce harmful consequences; for example, explosion walls, foams, impoundments, and pressure relief systems
Overview
Protection Layers
Methods that provide layers of protection should be: Independent Verifiable Dependable Designed for the specific safety risk
This figure 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.
Figure 1
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 61508 standards during a process hazard analysis (PHA).
Chapter 1
Safety Concepts
SIS Factors
According to the ANSI/ISA S84.01 and IEC 61508 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
An SIL can be considered a statistical representation of the availability of an SIS at the time of a process demand. A process demand is defined as the occurrence of a process deviation that causes an SIS to transition a process to a safe state. An 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 an SIS. The Tricon controller is a state-of-the-art PES optimized for safety-critical applications.
0.00001 0.0001 0.001 0.01 0.1 >10,000 10,000 1,000 1,000 100 100 10
Percent Availability
PFDavg
RRF
ANSI/ISA S84.01
IEC 61508
Risk Measures
Risk Standards
Figure 2
Note
DIN V 19250 was withdrawn in August 2004. It is not applicable to Tricon v10 systems, only Tricon v9 systems.
Chapter 1
Safety Concepts
As a required SIL increases, SIS integrity increases as measured by: System availability (expressed as a percentage) Average probability of failure to perform IES design function on demand (PFDavg) Risk reduction factor (RRF, reciprocal of PFDavg)
The relationship between AK class (see page 12) 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.
Off-site consequences include: 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. Classified as high, medium, or low, a risk probability is often based on a companys or a competitors 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 61508 risk graph.
Figure 3
* Tricon controller module failure rates, PFDavg, Spurious Trip Rate, and Safe Failure Fraction (SFF) calculation methods have been independently calculated and/or reviewed by Factory Mutual Research and TV Rheinland. The numbers presented here (and in the following tables) are typical. Exact numbers should be calculated for each specific system configuration. Contact Triconex/Invensys Systems for details on calculation methods and options related to the Tricon controller.
Safety Integrated System
3 Pressure Transmitters (2oo3) Sensors 3 Temperature Transmitters (2oo3)
Figure 4
Chapter 1
Safety Concepts
This table provides simplified equations for calculating the PDFavg for the key elements in an SIS. Once the PDFavg for each element is known, an SIL can be determined. Table 1 Simplified Equations for Calculating PFDavg
Description Sensors Equation PFDavg = (DU*TI)2 Variables (supplied by the manufacturer)
To calculate PFDavg for sensors (2oo3) PFDavg for block valves (1oo2) in series (final elements)
To calculate PFDavg for a system To calculate
= failure rate
DU=dangerous, undetected failure rate TI= test interval in hours DU=dangerous, undetected failure rate TI= test interval in hours
Block Valves
PFDavg = 1/3(DU*TI)2
= failure rate
System
To determine the SIL, compare the calculated PFDavg to the figure on page 5. In this example, the system is acceptable as an SIS for use in SIL3 applications. Table 2 Determining the SIL Using the Equations
DU Pressure Transmitters (2oo3) Temperature Transmitters (2oo3) Total for Sensors Block Valves (1oo2) Total for Block Valves Tricon Controller 2.00E-05 3.09E-04 2.28E-06 4380 3.33E-05 3.33E-05 2.28E-06 2.85E-06 TI 4380 4380 PFD 1.00E-04 1.56E-04 2.56E-04 Result
For additional information on SIL assignment and SIL verification, visit the Premier Consulting Services web site at http://www.premier-fs.com.
Modify EXIT No SIS required? Yes Define target SIL SIS installation, commissioning, and pre-startup acceptance test
(Step 4)
SIS decommissioning
(Step 9)
Figure 5
10
Chapter 1
Safety Concepts
Note
11
4 5
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.
Develop a pre-start-up acceptance test procedure that provides a fully functional test of the SIS to verify conformance with the SRS. 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 7
Before start-up, complete a safety review. 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 (such as OSHA 29 CFR 1910.119) Functional testing to detect covert faults that prevent the SIS from operating according to the SRS SIS testing, including sensors, logic solver, and final elements (such as shutdown valves, motors, etc.)
8 9
Follow management of change (MOC) procedures to ensure that no unauthorized changes are made to an application, as mandated by OSHA 29 CFR 1910.119. Decommission an SIS before its permanent retirement from active service, to ensure proper review.
12
Chapter 1
Safety Concepts
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 in this section apply to typical applications.
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 19250 classes. Note DIN V 19250 and DIN V VDE 0801 were withdrawn in August 2004. They are not applicable to Tricon v10 systems, only Tricon v9 systems.
Safety Standards
13
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 four SILs that are indexed to a specific probability-to-fail-on-demand (PFD) (see Figure 2 on page 5). A SIL assignment is based on the required risk reduction as determined by a PHA.
ANSI/ISA S84.01
ANSI/ISA S84.01-1996 is the United States standard for safety systems in the process industry. The SIL classes from IEC 61508 are used and the DIN V 19250 relationships are maintained. ANSI/ISA S84.01-1996 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 safety-instrumented 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. Note DIN V 19250 was withdrawn in August 2004. It is not applicable to Tricon v10 systems, only Tricon v9 systems.
Application-Specific Standards
EN 50156
EN 50156 Electrical equipment for furnaces and ancillary equipment outlines the European requirements for burner management applications.
EN 54, Part 2
EN 54, Part 2, 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.
14
Chapter 1
Safety Concepts
NFPA 85
NFPA 85, Boiler and Combustion Systems Hazards Code, outlines the United States requirements for operations using single burner boilers and multiple burner boilers.
2
Application Guidelines
Overview TV Rheinland Certification General Guidelines Guidelines for Tricon Controllers 16 16 17 19
16
Chapter 2
Application Guidelines
Overview
This chapter provides information about the industry-standard guidelines applicable to safety applications. These guidelines include those that apply to all safety systems, as well as those that apply only to specific industries, such as burner management or fire and gas systems. Guidelines that apply specifically to the Tricon controller, including SIL3/AK5 and AK6 guidelines, are also provided. Project change control guidelines and maintenance override considerations can be found at the end of this chapter. Note AK classes do not apply to Tricon v10 systems, they apply only to Tricon v9 systems because DIN V 19250 and DIN V VDE 0801 were discontinued in August 2004.
Be sure to thoroughly read and understand these guidelines before you write your safety application and procedures.
TV Rheinland Certification
When used as a PES in an SIS, the Tricon v9 controller and its companion programming workstation, the TriStation 1131 Developers Workbench, have been certified by TV Rheinland/Berlin-Brandenburg to meet the requirements of DIN 19250 AK5-AK6 and IEC 61508 SIL3. When used as a PES in an SIS, the Tricon v10 controller and its companion programming workstation, the TriStation 1131 Developers Workbench, have been certified by TV Rheinland/Berlin-Brandenburg to meet the requirements of IEC 61508 SIL3. Note DIN V 19250 was withdrawn in August 2004. It is not applicable to Tricon v10 systems, only Tricon v9 systems.
If these standards apply to your application, compliance with the guidelines described in this chapter is highly recommended.
General Guidelines
17
General Guidelines
This section describes standard industry guidelines that apply to: All safety systems Emergency shutdown (ESD) systems Fire and gas systems Burner management systems
18
Chapter 2
Application Guidelines
19
Safety-Critical Modules
It is recommended that only the following modules be used for safety-critical applications: Main Processor Modules, all models Communication Modules (only when using protocols defined for safety-critical applications) Digital Input Modules, all models Digital Output Modules, all models Analog Input Modules, all models Analog Output Module, Model #3805E only Pulse Input Module Pulse Totalizer Input Module
20
Chapter 2
Application Guidelines
Safety-Shutdown
A SIL3 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: TR_SHUTDOWN and TR_CRITICAL_IO. To see the Structured Text code for these function blocks, see Appendix B, Safety-Critical Function Blocks. For more information on safety-shutdown networks, see Sample Safety-Shutdown Programs on page 47.
21
If new data is not received within the time-out period (equal to half of the processing-tolerance time), the application on the receiving node should be able to determine the action to take. The actions may include one or more of the following: Use the last data received for safety-related decisions in the application. Use default values for safety-related decisions in the application. Monitor the status of the TR_URCV and TR_PORT_STATUS functions to determine whether there is a network problem that requires operator intervention.
The specific actions that an application should take depend on the unique safety requirements of your particular process. The following sections summarize actions typically required by Peerto-Peer send and receive functions.
Sending Node
Actions typically required in the logic of the sending application are: The sending node must set the SENDFLG parameter in the send call to true (1) so that the sending node sends new data as soon as the acknowledgment for the last data is received from the receiving node. The SEND function block (TR_USEND) must include a diagnostic integer variable that is incremented with each new send initiation so that the receiving node can check this variable for changes every time it receives new data. This new variable should have a range of 1 to 65,565 where the value 1 is sent with the first sample of data. When this variable reaches the limit of 65,565, the sending node should set this variable back to 1 for the next data transfer. This diagnostic variable is required because the communication path is not triplicated like the I/O system. The number of SEND functions in an application must be less than or equal to five because the controller only initiates five SEND functions per scan. To send data as fast as possible, the SEND function must be initiated as soon as the acknowledgment for the last data is received from the receiving node. The sending application must monitor the status of the RECEIVE (TR_URCV) and TR_PORT_STATUS functions to determine whether there is a network problem that requires operator intervention.
Receiving Node
Actions typically required in the logic of the receiving application are: To transfer safety-critical data, the basic rule is that the receiving node must receive at least one sample of new data within the maximum time-out limit. If this does not happen, the application for the receiving node must take one or more of the following actions, depending on requirements: Use the last data received for safety-related decisions. Use default values for safety-related decisions in the application. Check the status of the TR_URCV and TR_PORT_STATUS functions to see whether there is a network problem that requires operator intervention.
22
Chapter 2
Application Guidelines
The receiving node must monitor the diagnostic integer variable every time it receives new data to determine whether this variable has changed from last time. The receiving program must monitor the status of the TR_URCV and TR_PORT_STATUS functions to determine if there is a network problem that 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.
Tricon MP
Communication Bus
Tricon MP
Tricon MP
Communication Bus
Communication Module
802.3 cable
802.3 cable
Communication Module
Tricon MP
Tricon MP
Communication Bus
Black Channel
Tricon MP
Send Node
Receive Node
Figure 6
The SEND node prepares and sends a Peer-to-Peer message with the following items: A receive node number Send and receive context Number and types of data A 32-bit CRC for the message.
The RECEIVE node checks the message for The correct CRC The correct receive node number The correct send and receive context The correct data type and number of data items.
If all parts of the messageincluding the CRCare verified, the Main Processor provides the data to the application. If there is a problem in the black channel, the RECEIVE node will either not receive the message, or will receive a corrupted message that will be rejected. In this way, the integrity of the message is independent from the communication channel and the
23
communication equipment used in the channel; for example, routers, hubs, switches, or satellites. The RECEIVE node application receives Peer-to-Peer data only if the integrity of the Peer-toPeer message has been validated.
SIL3/AK5 Guidelines
For Tricon v9 and v10 SIL3, or Tricon v9 AK5 applications, these 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. Three modes control write operations from external hosts: Remote ModeWhen the keyswitch setting is REMOTE, external hosts, such as a Modbus Master or DCS, can write to aliased variables in the controller. When false, writes are prohibited except for the use of gated access functions in RUN mode. Program ModeWhen the keyswitch setting is PROGRAM, TriStation can make program changes, including operations 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. Run ModeWhen the keyswitch setting is RUN, external hosts, such as a Modbus Master or DCS, can write to aliased variables in the controller only by the application calling gated access functions that allow external writes during a designated window of time. Once the Writes have been performed and confirmed, the writing window should be closed using gated access functionality and closure of the writing access should be confirmed. For more information, see the descriptions of the GATENB and GATDIS function blocks in Appendix B. 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 program should include the following safeguards: When remote mode is true, the application should turn on an alarm. For example, if using the TR_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 27. When program mode is true, the application should turn on an alarm. For example, if using the TR_SHUTDOWN function block, the ALARM_PROGRAMMING_PERMITTED output could be used. Wiring and grounding procedures outlined in the Planning and Installation Guide for Tricon v9v10 Systems should be followed. Maintenance instructions outlined in the Planning and Installation Guide for Tricon v9 v10 Systems should be followed.
24
Chapter 2
Application Guidelines
The GATENB function allows external hosts to write to 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 Appendix A, Triconex Peer-to-Peer Communication. According to IEC 61508, SIL3 applications that require continued operation after detecting an output failure are not required to have a secondary means of operating the output. You should understand the risk mitigation requirements of your particular application and use good engineering practices.
Note
AK6 Guidelines
For Tricon v9 AK6 applications, these guidelines should be followed: DIN V 19250 was discontinued in August 2004, so it applies only to Tricon v9 systems. According to DIN V 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.
25
Three modes control write operations from external hosts: Remote ModeWhen the keyswitch setting is REMOTE, external hosts, such as a Modbus Master or DCS, can write to aliased variables in the controller. When false, writes are prohibited. Program ModeWhen the keyswitch setting is PROGRAM, TriStation can make program changes, including operations 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. Run ModeWhen the keyswitch setting is RUN, external hosts, such as a Modbus Master or DCS, can write to aliased variables in the controller only by the application calling gated access functions that allow external writes during a designated window of time. Once the Writes have been performed and confirmed, the writing window should be closed using gated access functionality and closure of the writing access should be confirmed. For more information, see the descriptions of the GATENB and GATDIS function blocks in Appendix B.
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 program should include the following safeguards: When remote mode is true, the application should turn on an alarm. For example, if using the TR_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 27. When program mode is true, the application should turn on an alarm. For example, if using the TR_SHUTDOWN function block, the ALARM_PROGRAMMING_PERMITTED output could be used.
Wiring and grounding procedures outlined in the Planning and Installation Guide for Tricon v9v10 Systems should be followed. Maintenance instructions outlined in the Planning and Installation Guide for Tricon v9 v10 Systems should be followed. If Tricon operation is degraded to dual mode, continued operation without repair should be limited to 1500 hours (two months). If Tricon operation is degraded to single mode, continued operation without repair should be limited to one hour. The GATENB function allows external hosts to write to 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 Appendix A, Triconex Peer-to-Peer Communication.
26
Chapter 2
Application Guidelines
Change Procedure
1 2 3 4 Generate a change request defining all changes and the reasons for the changes, then obtain approval for the changes from the SCCC. Develop a specification for the changes, including a test specification, then obtain approval for the specification from the SCCC. Make the appropriate changes to the project, including those related to design, operation, or maintenance documentation. To verify that the configuration in the controller matches the last downloaded configuration, use the Verify Last Download to the Controller command on the Controller Panel. For details, see the Developers Guide for TriStation 1131, v4.2. Compare the configuration in your project with the configuration that was last downloaded to the controller by printing the Compare Project to Last Download report from the Controller Panel. For details, see the Developers Guide for TriStation 1131, v4.2. Print all logic elements and verify that the changes to networks within each element do not affect other sections of the application. Test the changes according to the test specification using the Emulator Panel. For details, see the Developers Guide for TriStation 1131, v4.2. Write a test report. Review and audit all changes and test results with the SCCC.
6 7 8 9
27
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 and Control option in the Set Programming Mode dialog box on the Controller Panel if it is not already selected.
Note
Changing the operating mode to PROGRAM generates 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 58. Save the downloaded project in TriStation and back up the project. Archive two copies of the project file and all associated documentation.
11 12
Maintenance Overrides
Three methods can be used to check safety-critical devices connected to controllers: Special switches are connected to the inputs on 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. Communication to a controller activates the maintenance override condition. This method is useful when space is limited; the maintenance console should be integrated with the operator display.
TV recommends that the TriStation 1131 workstation used for programming is not also used for maintenance.
28
Chapter 2
Application Guidelines
Table 3 describes the design requirements for handling maintenance overrides when using Tricon communication capabilities. Table 3 Design Requirements for Maintenance Override Handling
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 safety-critical 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. During an override, proper operating measures should be implemented. The time span for overriding should be limited to one shift (typically no longer than eight hours). A maintenance override switch (MOS) light on the operator console should be provided (one per controller or process unit). Project Engineer, Commissioner, DCS, TriStation Responsible Person DCS Project Engineer, Commissioner Project Engineer TriStation Project Engineer, Commissioner Project Engineer, Type Approval
N/A
29
Table 4 describes the operating requirements for handling maintenance overrides when using Tricon 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. Responsible Person DCS Operator, Maintenance Engineer Operator, Maintenance Engineer Operator, Maintenance Engineer TriStation 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 28 and page 29: 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
HardWired Switch
Operator Warning
Engineering Workstation
Use of the maintenance override capability should be documented in a DCS or TriStation 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.
30
Chapter 2
Application Guidelines
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 TV web site at http://www.tuv-fs.com/modr_3_e.htm.
3
Fault Management
Overview System Diagnostics Types of Faults Operating Modes Module Diagnostics 32 33 34 35 36
32
Chapter 3
Fault Management
Overview
The Tricon controller has been designed from its inception with self-diagnostics as a primary feature. Triple-Modular Redundant (TMR) architecture (shown in Figure 7) ensures fault tolerance and provides error-free, uninterrupted control in the event of hard failures of components or transient faults from internal or external sources. Each I/O module houses the circuitry for three independent channels. Each channel on the input modules reads the process data and passes that information to its respective main processor. The three Main Processor (MP) modules communicate with each other using a proprietary, high-speed bus system called the TriBus. Extensive diagnostics on each channel, module, and functional circuit quickly detect and report operational faults by means of indicators or alarms. This fault information is available to an application. It is critical that an application properly manage fault information to avoid an unnecessary shutdown of a process or plant. This section discusses the methods for properly handling faults.
Auto Spare Input Channel A Input Channel B I/O Bus TriBus Main Processor B TriBus I/O Bus Auto Spare Output Channel A TriBus I/O Bus Main Processor C
Main Processor A
Input Termination
Output Channel B
Input Channel C
Output Channel C
Figure 7
System Diagnostics
33
System Diagnostics
To improve system availability and safety, a safety system must be able to detect failures and provide the means for managing failures properly. The controllers diagnostics may be categorized as: Reference diagnostics: Comparing an operating value to a predetermined reference, such as a system specification. Comparison diagnostics: Comparing one component to another, such as one independent channel with two other independent channels. Field device diagnostics: Diagnostics are extended to a systems field devices and wiring.
34
Chapter 3
Fault Management
Types of Faults
A controller is subject to external faults and internal faults, which are reported by: The status indicators on a modules front panels The Triconex Enhanced Diagnostic Monitor System attributes on the Controller Panel in TriStation
External Faults
A controller may experience the following types of external faults: Logic power faults Field power faults Load or fuse faults
When an external fault occurs, the controller asserts an alarm. How the alarm is communicated is module-specific. In some cases, a yellow alarm indicator is provided on the module. For example, a Load/Fuse alarm is provided on digital output modules. In most cases, the System alarm is asserted, and the System alarm indicators on the main chassis power modules are lit. The Triconex Enhanced Diagnostic Monitor identifies the faulting module by displaying a red frame around it. For instructions on responding to specific alarm conditions, see the Planning and Installation Guide for Tricon v9v10 Systems.
Internal Faults
Internal faults are usually isolated to one of the controllers three channels (A, B, or C). When an internal fault occurs on one of the three channels, the remaining two healthy channels maintain full control. Depending on the type of fault, the controller either remains in TMR mode or degrades to dual mode for the system component that is affected by the fault. For more information about operating modes, see Operating Modes on page 35. When an internal fault occurs, the controller lights the red Fault indicator on the faulting module and the System alarm on the main chassis power modules to alert the operator to replace the faulting module.
Operating Modes
35
Operating Modes
Each input or output point is considered to operate in one of three modes: Triple Modular Redundant (TMR) Single Mode Dual Mode
The current mode indicates the number of channels controlling a point; in other words, the number of channels controlling the output or having confidence in the input. For safety reasons, system mode is defined as the mode of the point controlled by the fewest number of channels. System variables summarize the status of input and output points. When a safety-critical point is in dual or single mode, the application may need to shut down the controlled process within a pre-determined time. You can further simplify and customize shutdown logic by using special function blocks provided by Triconex. By considering only faults in safety-critical modules, system availability can be improved. Using shutdown function blocks is essential to preventing potential false trips in dual mode and to guaranteeing fail-safe operation in single mode. For more information, see Appendix B, Safety-Critical Function Blocks. While operating in TMR mode, during each scan the process is protected from the effect of a single safety-critical system fault. The system can also tolerate multiple faults and continue to operate correctly unless the combined effects of multiple faults affects the same point on multiple channels. If a system fault occurs, the loss of redundancy causes an increased probability-of-failure-ondemand. To keep the PFD within industry-acceptable guidelines, adherence with the recommended maximum operating period of 3000 hours in dual mode (SIL3/AK5-6) and 150 hours (SIL3/AK5-6) should be observed. A safety-critical fault is defined as a fault that prevents the system from executing the safety function on demand. Safety-critical faults include: Inability to detect a change of state on a digital input point Inability to detect a change of value on an analog input point Inability to change the state of a digital output point Inability of the system to: Read each input point Vote the correct value of each input Execute the control program Determine the state of each output point correctly Also, during each execution of the control application, each channel independently verifies the: Integrity of the data path between the MPs Proper voting of all input values Proper evaluation of the control application Calculated value of each output point
Safety Considerations Guide for Tricon v9v10 Systems
36
Chapter 3
Fault Management
Module Diagnostics
Each system component detects and reports operational faults.
Module Diagnostics
37
compared its against internal references. A channel that has detected a fault on an analog input point votes that point to be zero. Using these diagnostics, each channel can be verified independently, thus assuring nearly 100 percent fault coverage and fail-safe operation under all single-fault scenarios and most common multiple-fault scenarios.
38
Chapter 3
Fault Management
Input/Output Processing
Each processor on an I/O module is protected by an independent watchdog that verifies the timely execution of the I/O module firmware and diagnostics. If an I/O processor fails to execute correctly, the I/O processor enters the fail-safe state. The I/O bus transceiver and all outputs for the faulting channel are disabled, leaving all outputs under control of the remaining healthy channels. The integrity of the I/O bus is continuously monitored and verified independently by each channel of the system. A catastrophic bus fault results in affected I/O module channels reverting to the fail-safe state in less than 500 milliseconds (0.5 seconds), worst case. Each digital input point is reported to the control program as de-energized. Each analog input point is reported to the control program as zero. Each digital output point goes to the de-energized state. Each analog output point goes to 0.0 mA. Each relay output point goes to the normally open (NO) position.
Module Diagnostics
39
An independent watchdog ensures that the control program and diagnostics execute within 500 milliseconds (the watchdog period). If an MP fails to execute the scan, the watchdog forces the MP to the fail-safe state. The I/O processor adds a sequential element to the MP watchdog. If an MP fails to report the proper sequence of execution, the I/O processor causes the MP to enter the fail-safe state.
External Communication
Loss of external communication is not indicated by a system alarm. However, alarms can be generated by using semaphore flags and system attributes.
CAUTION
Semaphore Flags
External communications are intended for transporting non-safetycritical data. The guidelines outlined in Using Tricon Communication Capabilities on page 27 should be followed in SIS applications.
Establish a semaphore between a controller and an external device by using a timer function block to evaluate the changing state of semaphore flags.
System Attributes
System attributes can be used to generate an alarm when a communication link is lost. For more information about communication alarms, see the Developers Guide for TriStation 1131, v4.2 and the following manuals: Communication Guide for Tricon v9v10 Systems Planning and Installation Guide for Tricon v9v10 Systems TriStation 1131 Libraries Reference
40
Chapter 3
Fault Management
4
Application Development
Development Guidelines Important TriStation Commands Setting Scan Time Sample Safety-Shutdown Programs Alarm Usage 42 44 46 47 58
42
Chapter 4
Application Development
Development Guidelines
To avoid corruption of project files while developing an application (also known as a control program), you should: Use a dedicated PC that is not connected to a network. Use a good virus checker. Use dependable media, such as a CD-ROM instead of a floppy disk. Not use battery power if using a notebook computer. Not copy a project file while it is open in TriStation. Not e-mail project files. Not use a system prone to crashing. Verify proper installation of TriStation 1131 using TriStation Install Check. You should run the TriStation Install Check program to verify that TriStation is correctly installed on your PC and that no associated files are corrupted. This is especially helpful if applications besides TriStation 1131 reside on your PC. See the Developers Guide for TriStation 1131, v4.2 for instructions on using the TriStation Install Check program.
VAR_IN_OUT Variables
You should not use the VAR_IN_OUT variable in a safety application. Safety standards (such as IEC 61508) recommend limiting the use of pointers in safety applications; VAR_IN_OUT is used as a pointer in TriStation 1131. To automatically check for the use of VAR_IN_OUT in your safety application, set the safety attribute (as described above).
Development Guidelines
43
See the TriStation 1131 Libraries Reference for more information about the CHK_ERR and CLR_ERR function blocks.
Infinite Loops
If the actual scan time exceeds the maximum allowable scan time for the Tricon, the main processors will reset, causing the Tricon to go to the safe state, with all outputs de-energized. The maximum allowable scan time for the Tricon is 450 milliseconds. Although it is not possible to program an endless loop with TriStation 1131, it is possible to create a loop with a very long time, enough to increase the actual scan time beyond the controllers maximum allowable scan time. See Setting Scan Time on page 46 for more information about actual and maximum scan times.
44
Chapter 4
Application Development
Download Changes
The Download Changes command is a convenient means of making simple modifications to an offline system during application development.
WARNING
Download Changes is intended for offline use during application development. If you use Download Changes to modify a safety-critical application that is running online, you must exercise extreme caution because an error in the modified application or system configuration may cause a trip or unpredictable behavior. If you must make online changes to a controller, you should always follow the guidelines provided in the Developers Guide for TriStation 1131, v4.2 and fully understand the risks you are taking by using the Download Changes command. Note that the scan time of the controller is doubled momentarily after you use the Download Changes command. Changing the resolution type on model 3720 and 3721 AI modules will cause all input points on the module to change. A change from high to low resolution (or vice-versa) results in a value change by a factor of four. You must modify your application to take this change into account. During a Download Changes operation, the implementation of the logic change will occur before the implementation of the range change on the modules. This may result in a mismatch between the range the application expects and the actual range from the module. All points should be bypassed during a resolution change to prevent any unintended application problems.
Before a Download Changes, use the Triconex Enhanced Diagnostic Monitor to verify that the Scan Surplus is sufficient for the application and changes being made. As a rule, the value for Scan Surplus should be at least 10 percent of Scan Time to accommodate newly added elements. For more information on scan time, see Setting Scan Time on page 46.
CAUTION
Do not attempt a Download Changes if you have a negative Scan Surplus. First, adjust Scan Time to make the surplus value greater than or equal to zero. Please note that adjusting the scan time of a running system may degrade communication performance.
45
For more information on the Download Changes command, see the Developers Guide for TriStation 1131, v4.2.
46
Chapter 4
Application Development
Scan Time
Scan time is the interval required for evaluations (in other words, scans) of an application as it executes in the controller. The time it actually takes to do an evaluation may be less than the requested scan time. To prevent scan-time overruns, a scan time must be set that includes sufficient time for all executable elements in an applicationincluding print statements, conditional statements, and future download changes. Use the Scan Time parameter in the TriStation Program Execution List to suggest the desired scan time before downloading an applicationthis is the Requested Scan Time. Upon downloading, the controller determines the minimum and maximum allowable scan times for your application and uses your requested scan time if it falls within the acceptable limits. The default scan time is 200 milliseconds. The maximum allowable scan time is 450 milliseconds and the minimum allowable scan time is 20 milliseconds (Tricon v9.5 and earlier) or 10 milliseconds (Tricon v9.6 and later). Actual Scan Time is the actual time of the last scan. Actual scan time is always equal to or greater than the requested scan time. Note To guarantee that the controller provides a deterministic response time, the scan time should always be set to a value greater than the I/O poll time (the maximum time needed by the controller to obtain data from the input modules). You can view the I/O poll time on the System Overview screen in the Triconex Enhanced Diagnostic Monitor.
Scan Surplus
Scan Surplus is the scan time remaining after application elements have been executed. Scan Surplus must be positiveif it is negative, the Scan Time parameter must be adjusted (using the Set Scan Time command on the Commands menu in the Controller Panel) to set the surplus value to greater than or equal to zero. The Scan Time parameter in the TriStation Program Execution List applies only when you perform a Download All.
Scan Overruns:
If Scan Surplus becomes negative and a scan overrun occurs, the relevant status attributes are set as follows SCAN_OVERRUNS is incremented once for each time that a longer scan time is needed. SURPLUS_SCAN is set to a negative number to indicate the additional time period used by a scan overrun.
1 C1
SCAN_STATUS
TR_SCAN_STATUS
CO POWERUP FIRSTSCAN SCANREQUEST SCANSURPLUS SCANDELTA DELTAT SCANOVERRUN
001
SCAN_SURPLUS
SCAN_OVERRUNS
KEYSWITCH
For more information, see the Developers Guide for TriStation 1131, v4.2 and the TriStation 1131 Libraries Reference.
Safety Considerations Guide for Tricon v9v10 Systems
47
When the output CRITICAL_MODULES_OPERATING is true, all safety-critical modules are operating properly. The input MAX_TIME_DUAL specifies the maximum time allowed with two channels operating (with no connection, defaults to 40000 days). The input MAX_TIME_SINGLE specifies the maximum time allowed with one channel operating (3 days in the example). Note In typical applications, continued operation in dual mode is restricted to 3000 hours for SIL3/AK5-6. Continued operation in single mode is restricted to 150 hours for SIL3/AK5-6.
When CRITICAL_MODULES_OPERATING is false, the time in degraded operation exceeds the specified limits; therefore, the control program should shut down the process under safety control.
CAUTION
The sample program called EX01_SHUTDOWN does not handle detected field faults, rare combinations of faults detected as field faults, or output voter faults hidden by field faults. The control program, not the TR_SHUTDOWN function block, must read the NO_FLD_FLTS module status or FLD_OK point status to provide the required applicationspecific action.
For information on improving availability using external, power-disconnect relays and advanced programming techniques, see the sample program EX02_SHUTDOWN.
48
Chapter 4
Application Development
Program EX01_SHUTDOWN
CRITICAL_MODULES
TR_SHUTDOWN
CI IO_CO IO_TMR IO_GE_DUAL IO_GE_SINGLE IO_NO_VOTER_FLTS IO_ERROR
T#1500h
CO OPERATIING TMR DUAL SINGL ZERO TIMER_RUNNING ALARM_PROGRAMMING_PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS CRITICAL_MODULES_OPERATING
MAX_TIME_DUAL
T#3d
T#400ms
Figure 8
CO false indicates a programming error; for example, MAX_TIME_SINGLE greater than MAX_TIME_DUAL. The error number shows more detail. Table 5
Parameter CI IO_CO IO_TMR IO_GE_DUAL IO_GE_SINGLE IO_NO_VOTER_FLTS IO_ERROR MAX_TIME_DUAL MAX_TIME_SINGLE MAX_SCAN_TIME
49
Table 6
Parameter CO
OPERATING
TMR DUAL SINGL ZERO TIMER_RUNNING TIME_LEFT ALARM_PROGRAMMING_PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS ERROR_NUM
System is operating in triple modular redundant mode At least one safety-critical point is controlled by two channels At least one safety-critical point is controlled by one channel At least one safety-critical point is not controlled by any channel Time left to shutdown is decreasing Time remaining before shutdown True if application changes are permitted True if remote-host writes are enabled True if actual scan time is greater than MAX_SCAN_TIME True if one or more points are disabled. Error Number: 0 = No error 1 = Error in maximum time 2 = I/O function block errorIO_ERROR is non-zero 3 = Function block errorsystem status or MP Status
50
Chapter 4
Application Development
Table 7
Parameter
ALARM_PROGRAMMING_PERMITTED
ALARM_REMOTE_ACCESS
ALARM_RESPONSE_TIME
ALARM_DISABLED_POINTS
51
When the output CRITICAL_MODULES_OPERATING is true, all critical modules are operating properly. The input MAX_TIME_DUAL specifies the maximum time allowed with two channels operating (with no connection, defaults to 40,000 days). The input MAX_TIME_SINGLE specifies the maximum time allowed with one channel operating (three days in the example). Note In typical applications, continued operation in dual mode is restricted to 3000 hours for SIL3/AK5-6. Continued operation in single mode is restricted to 150 hours for SIL3/AK5-6.
When CRITICAL_MODULES_OPERATING is false, the time in degraded operation exceeds the specified limits; therefore, the control program should shut down the plant.
CAUTION
The EX02_SHUTDOWN sample program does not handle detected field faults, rare combinations of faults detected as field faults, or output voter faults hidden by field faults. The application program, not the TR_SHUTDOWN function block, must read the NO_FLD_FLTS module status or FLD_OK point status to provide the required applicationspecific action.
52
Chapter 4
Application Development
Program EX02_SHUTDOWN
CRITICAL_MODULES CRITICAL_IO EX02_CRITICAL_IO
CI RELAY1_OK CO TMR GE_DUAL GE_SINGLE NO_VOTER_FLTS
001
TR_SHUTDOWN
CI IO_CO IO_TMR IO_GE_DUAL IO_GE_SINGLE IO_NO_VOTER_FLTS IO_ERROR MAX_TIME_DUAL MAX_TIME_SINGLE MAX_SCAN_TIME CO OPERATING TMR DUAL SINGL ZERO TIMER_RUNNING TIME_LEFT ALARM_PROGRAMMING_PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS
002
CRITICAL_MODULES_OPERATING
ERROR
T#1500h
T#3d
T#400ms
ERROR
Figure 9
Table 8
Parameter CI
Critical I/O control out All critical I/O points are operating in triple modular redundant mode All critical I/O points are operating are operating in dual or TMR mode All critical I/O points are operating are operating in single, dual, or TMR mode If true, then no voter faults exist on a critical I/O module If false, then a voter fault exists on a critical I/O module Error numberzero indicates no error. Non-zero indicates a programming or configuration error Maximum time with only two channels operating Maximum time with only one channel operating 50% of the maximum response time
53
Table 9
Parameter CO
OPERATING
TMR DUAL SINGL ZERO TIMER_RUNNING TIME_LEFT ALARM_PROGRAMMING_PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS ERROR_NUM
System is operating in triple modular redundant mode At least one safety-critical point is controlled by two channels At least one safety-critical point is controlled by one channel At least one safety-critical point is not controlled by any channel Time left to shutdown is decreasing Time remaining before shutdown True if application changes are permitted True if remote-host writes are enabled True if actual scan time is greater than MAX_SCAN_TIME True if one or more points are disabled Error Number: 0 = No error 1 = Error in maximum time 2 = I/O function block errorIO_ERROR is non-zero 3 = Function block errorsystem status or MP Status
54
Chapter 4
Application Development
Table 10
Parameter
ALARM_PROGRAMMING_PERMITTED
ALARM_REMOTE_ACCESS
ALARM_RESPONSE_TIME
ALARM_DISABLED_POINTS
55
Procedure
1 2 Copy the example EX02_CRITICAL_IO function block in the ExTUV.pt2 sample project provided with the TriStation 1131 Developers Workbench. Edit the lines following the comment Include here all safety-critical I/O modules. Each line calls the safety-critical I/O (SCIO) function block for one safety-critical I/O module. Example
**************************************************************) (* Include here all safety-critical I/O modules: *) SCIO( CHASSIS:=1,SLOT:=1, APP:=DE_ENERGIZED,RELAY_OK:=FALSE):(*DI*) SCIO( CHASSIS:=1,SLOT:=2, APP:=RELAY, RELAY_OK:=RELAY1_OK);(*DO*) SCIO( CHASSIS:=1,SLOT:=3, APP:=RELAY, RELAY_OK:=RELAY1_OK);(*DO*) (* ( CHASSIS:=1,SLOT:=4, NOT CRITICAL) *)(*RO*)
Enter the correct CHASSIS number, SLOT number, APP (application), and RELAY_OK parameters for the safety-critical I/O module. Parameters for Safety-Critical Modules
Relay_OK Parameter True Description A voter fault degrades the mode to dual. The relay provides a third channel for shutdown so that if an output voter fails, there remain two independent channels (the relay and other output voter channel) that can de-energize the output. A voter fault degrades the mode to single. A non-voter fault degrades the mode to dual. A voter fault degrades the mode to single. A non-voter fault degrades the mode to dual.
Table 11
RELAY (de-energized to trip with relay) DE-ENERGIZED (de-energized to trip with no relay)
False
56
Chapter 4
Application Development
Partitioned Processes
You can achieve greater system availability if you can allocate modules to processes that do not affect each other. For example, you could have two processes with: Outputs for one process on one DO module Outputs for another process on a second DO module Inputs from a shared DI module
Procedure
1 Partition the safety-critical I/O modules into three function blocks: 2 SHARED_IO for the shared safety-critical I/O modules PROCESS_1_IO for safety-critical I/O modules that do not affect process 2 PROCESS_2_IO for safety-critical I/O modules that do not affect process 1
Connect the function blocks as shown in the EX03_SHUTDOWN example on page 57. The EX03_SHUTDOWN sample program does not handle detected field faults, rare combinations of faults detected as field faults, or output voter faults hidden by field faults. The application program, not the TR_SHUTDOWN function block, must read the NO_FLD_FLTS module status or FLD_OK point status to provide the required applicationspecific action.
CAUTION
57
Program EX03_SHUTDOWN
SHARED SHARED_IO
TR_SHUTDOWN
CI IO_CO IO_TMR IO_GE_DUAL IO_GE_SINGLE IO_NO_VOTER_FLTS IO_ERROR MAX_TIME_DUAL MAX_TIME_SINGLE MAX_SCAN_TIME CO OPERATING TMR DUAL SINGL ZERO TIMER_RUNNING TIME_LEFT ALARM_PROGRAMMING_PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS
002
EX03_SHARED_IO
CI RELAY1_OK CO TMR GE_DUAL GE_SINGLE NO_VOTER_FLTS
001
ERROR
T#1500h
T#3d
T#400ms
ERROR
TR_SHUTDOWN
CI IO_CO IO_TMR IO_GE_DUAL IO_GE_SINGLE IO_NO_VOTER_FLTS IO_ERROR MAX_TIME_DUAL MAX_TIME_SINGLE MAX_SCAN_TIME CO OPERATING TMR DUAL SINGL ZERO TIMER_RUNNING TIME_LEFT ALARM_PROGRAMMING_PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS
004
AND
005
PROCESS_1_ OPERATING
ERROR
T#1500h
T#3d
T#400ms
If PROCESS_1_OPERATING = FALSE, shut down process 1 because the time in degraded mode exceeds the specified limit for safety-critical modules that affect process 1.
ERROR
TR_SHUTDOWN
CI IO_CO IO_TMR IO_GE_DUAL IO_GE_SINGLE IO_NO_VOTER_FLTS IO_ERROR MAX_TIME_DUAL MAX_TIME_SINGLE CO OPERATING TMR DUAL SINGL ZERO TIMER_RUNNING TIME_LEFT ALARM_PROGRAMMING_PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS
006
AND
006
PROCESS_2_ OPERATING
ERROR
T#1500h
If PROCESS_2_OPERATING = FALSE, shut down process 2 because the time in degraded mode exceeds the specified limit for safety-critical modules that affect process 2.
ERROR
Figure 10
58
Chapter 4
Application Development
Alarm Usage
To implement the guidelines, the alarms described below are provided with TriStation 1131.
A
Triconex Peer-to-Peer Communication
Overview Data Transfer Time Examples of Peer-to-Peer Applications 60 61 64
60
Appendix A
Overview
Triconex Peer-to-Peer protocol is designed to allow multiple Tricon and Trident controllers in a closed network to exchange safety-critical data. (If you plan to implement a complex Peer-toPeer network, please contact the Triconex Customer Satisfaction Center.) To enable Peer-to-Peer communication, you must connect each controller (also referred to as a node) to an Ethernet network by means of a NET 1 (Ethernet) port on an NCM or a TCM. The controllers exchange data by using Send and Receive function blocks in their TriStation applications.
Peer-to-Peer Network
CM
CM
MP Trident Controller
M M M P P P A B C
NN CC MM 1 2
Figure 11
To configure a TriStation application for Peer-to-Peer communication, you must do the following tasks: Configure the physical port connection for Peer-to-Peer mode Allocate memory for Send and Receive function blocks Add Send and Receive function blocks to your programs Observe restrictions on data transmission speed
In addition, Triconex recommends that you calculate the data transfer time to determine whether your control algorithms will operate correctly. Instructions for performing this calculation are provided on page 61. The sample programs described in this appendix can be found in the Expeer.pt2 project included as part of the TriStation 1131 installation. These programs show how to send data at high speed and under controlled conditions. For more detailed information on Triconex Peer-to-Peer communication, please refer to the Communication Guide for Tricon v9v10 Systems.
61
Send function blocks require multiple scans to transfer data from the sending controller to the receiving controller. The number of send operations initiated in a scan is limited to 5. The number of pending send operations is limited to 10.
Procedure
1 2 In TriStation, on the sending controller, expand the Controller tree, and double-click Configuration. On the Configuration tree, click Memory Allocation. Find the bytes allocated for BOOL, DINT, and REAL points by doing this: On the Configuration tree, click Memory Points, Input Points, or Output Points. Double-click the graphic for the point type. Add the number of bytes allocated for all BOOL input, output, and aliased memory points. Enter the number on step 1 of the following worksheet. Enter the number for DINT and REAL points on step 1.
On the receiving controller, get the BOOL, DINT, and REAL points and enter the numbers on step 3 of the Data Transfer Time worksheet.
62
Appendix A
Table 12
Parameter TS SS TR SR
Procedure
1 Use the instructions in the following worksheet to estimate the transfer time.
Steps 1. Enter the number of bytes for each point type on the sending controller and divide or multiply as indicated. Add the results. Point Type BOOL DINT REAL Allocated Bytes _________ _________ _________ Operation 8= x4= x4= Result _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ _________ Adjusted DT _________
Total bytes of aliased points TBS = 2. Multiple total bytes sending TBS (step 1) by 0.01 3. Enter the number of bytes for each point type on the receiving controller and divide or multiply as indicated. Add the results. BOOL DINT REAL _________ _________ _________ TS = 8= x4= x4=
Total bytes of aliased points TBR = 4. Multiple total bytes receiving TBR (step 3) by 0.01 5. Get the scan time of sending node in milliseconds by viewing the Scan Time in the Execution List. 6. Get the scan time of receiving node in milliseconds by viewing the Scan Period in the Execution List. 7. Multiply the larger of TS or SS by 2. 8. Multiply the larger of TR or SR by 2. 9. Add the results of step 7 and 8 to get the data transfer time = DT 10. If the number of pending send requests in the application is greater than 10, divide the number of send requests by 10. 11. Multiply the results of steps 9 and 10 to get the adjusted data transfer time. TR = SS = SR =
63
A typical data transfer time (based on a typical scan time) is 1 to 2 seconds, and the time-out limit for a Peer-to-Peer send (including three retries) is 5 seconds. Consequently, the processtolerance time of the receiving controller must be greater than 5 seconds. Process-tolerance time is the maximum length of time that can elapse before your control algorithms fail to operate correctly. If these limitations are not acceptable, further analysis of your process is required. For an example that shows how to measure the maximum data transfer time and use SEND/RECEIVE function blocks to transfer-safety critical data, see Example 4: Using SEND/RECEIVE Function Blocks for Safety-Critical Data on page 65. While testing your system, you should measure the actual maximum time it takes to transfer data to ensure the validity of your calculations. As Table 12 shows, it takes from two to 30 seconds to detect and report time-out and communication errors. This is why a receiving node that uses the received data to make safetycritical decisions must include logic to verify that new data is received within the specified time period. If the data is not received within the specified process-tolerance time, the application must take appropriate actions depending on requirements. For an example that shows how to use SEND and RECEIVE function blocks for transferring safety critical data, see Example 4: Using SEND/RECEIVE Function Blocks for Safety-Critical Data on page 65. Refer to the TriStation 1131 Libraries Reference for additional information.
64
Appendix A
65
If the sending controller does not receive acknowledgment from the receiving controller in one second, it automatically retries the last TR_USEND message. Because of network collisions, communication bus loading, etc., the sending controller occasionally has to retry once to get the message to the receiving node. This is why the general rule for data transfer time is one to two seconds, even though the estimated time is 550 milliseconds. The receiving node has a network to measure the actual time so you can validate the assumed four-second maximum transfer time, since the process-tolerance time of the receiving node is four seconds. The receiving node should receive at least one data transfer within the maximum time-out limit. Using this criteria meets the basic requirement for using peer-to-peer communication to transfer safety-critical data.
66
Appendix A
This example packs 32 BOOL values into a DWORD and sends the DWORD and a diagnostic variable to a receiving node as fast as possible by setting the sendflag parameter to 1 all the time. The diagnostic variable is incremented every time a new SEND is initiated. The receiving node checks the diagnostic variable to verify that it has changed from the previous value received. The receiving node also determines whether it has received at least one data transfer within the process-tolerance time. If not, the application takes appropriate action, such as using the last data received or using default data to make safety-critical decisions. This example uses the following project elements: PEER_EX4_SEND_FBD (for sending Node #1) PEER_EX4_RCV_FBD (for receiving Node #3)
B
Safety-Critical Function Blocks
GATDIS GATENB TR_CRITICAL_IO TR_SHUTDOWN TR_VOTE_MODE 69 70 72 78 84
68
Appendix B
Overview
This appendix describes these function blocks, which are intended for use in safety-critical applications: GATDIS on page 69 GATENB on page 70 TR_CRITICAL_IO on page 72 TR_SHUTDOWN on page 78 TR_VOTE_MODE on page 84
GATDIS
69
GATDIS
Disables remote writes to aliased variables in a Tricon controller.
Syntax
GATDIS(CI:=b)
Input Parameters
Name CI Data Type BOOL Description Enables GATDIS.
Output Parameters
Name CO Data Type BOOL Description True if GATDIS execute successfully.
Description
In a Tricon controller, the GATDIS function block disables remote writes for all ranges of read/write aliased variables that were previously enabled by GATENB, thereby restricting write operations by external hosts. GATDIS must be executed after the GATENB function. For more information, see GATENB on page 70.
Example
VAR GATE_IS_DISABLED : BOOL ; END_VAR VAR DISABLED_GATE : GATDIS ; END_VAR DISABLE_GATE(TRUE); GATE_IS_DISABLED = GATDIS.CO ;
Runtime Errors
None.
Application Notes
Can be used in Safety or Control applications. Only Once: each instance should be executed only once per scan, but does not need to be executed every scan.
Library
Tricon (TX1LIB)
Related Topics
GATENB on page 70
70
Appendix B
GATENB
Enables remote writes to aliased variables in a Tricon controller.
Syntax
GATENB(CI:=b,DRWFRST:=k1,DRWLAST:=k2,IRWFRST:=k3,IRWLAST:=k4,RRWFRST:=k5,KRW LAST:=k6
Input Parameters
Name CI DRWFRST DRWLAST IRWFRST IRWLAST RRWFRST RRWLAST Data Type BOOL DINT DINT DINT DINT DINT DINT Description Enables GATENB. The starting alias number for memory discrete (BOOL) read/write range. The ending alias number for memory discrete (BOOL) read/write range. The starting alias number for memory integer (DINT) read/write range. The ending alias number for memory integer (DINT) read/write range. The starting alias number for memory real read/write range. The ending alias number for memory real read/write range.
Output Parameters
Name CO Data Type BOOL Description True if GATENB executes successfully.
Description
In a Tricon controller, the GATENB function block opens a gate for external-host read/writes to a specified range of Modbus aliased variables when the controller is operating in RUN mode. In a safety shutdown application, the keyswitch is typically set to RUN mode for normal operation. However, this mode does not support Modbus writes from external hosts. To solve this problem, TriStation 1131 provides gated-access function blocks to programmatically enable and disable external-host writes to a Tricon controller. GATENB allows you to specify a range of aliases for each of these data types: Discrete Read/Write Integer Read/Write Real Read/Write
You should use only one GATENB function block in a program. If you do not want to specify alias ranges for certain data types, leave their starting and ending values at zero (the default).
GATENB
71
Example
This example opens a gate for external-host writes to selected Modbus read/write memory BOOL and DINT variables.
VAR ENABLE_GATE : GATENB; END_VAR ENABLE_GATE( CI:=TRUE,DRWFRST:=2001, DRWLAST:=2020, IRWFRST:=40251,IRWLAST:=40258, RRWFRST:=0, RRWLAST:=0 );
Runtime Errors
Condition If a specified alias range is invalid If this is a second function block with the same specified alias range Return Value CO=false CO=false Error Flags None None
Upon detection of a runtime error condition, the function block returns the indicated values and sets the error flags to true. For more information about error flags and runtime errors, see the CHK_ERR function block description in the TriStation 1131 Libraries Reference.
Application Notes
Can be used in Safety or Control applications. Only Once: each instance should be executed only once per scan, but does not need to be executed every scan.
Library
Tricon (TX1LIB)
72
Appendix B
TR_CRITICAL_IO
Accumulates the status of safety-critical I/O modules in a Tricon controller.
Syntax
MY_TR_CRITICAL_IO( CI:=b1, INIT:=b2, CHASSIS:=n1, SLOT:=n2, APP:=n3, RELAY_OK:=b3 ) ;
Input Parameters
Name CI INIT CHASSIS SLOT APP RELAY_OK Data Type BOOL BOOL DINT DINT DINT BOOL Description Enables TR_CRITICAL_IO. Initializes TR_CRITICAL_IO. The chassis number (115). The physical slot number. The application number (1-2). The relay is energized and not stuck.
Output Parameters
Name CO TMR GE_DUAL GE_SINGLE NO_VOTER_FLTS ERROR Data Type BOOL BOOL BOOL BOOL BOOL DINT Description True if TR_CRITICAL_IO executes successfully. Three channels are operating without fatal faults on critical I/O modules detected. Two channels are operating without fatal faults on critical I/O modules detected. At least one channel is operating without faults on critical I/O modules detected. No voter faults on critical I/O modules detected. Error Number: 0 = No error. 1 The slot is not odd or not numbered 115. 2 = Invalid chassis or slot. 3 = The module is not configured. 4 = An invalid application number is used. 5 = Not initialized.
Description
The TR_CRITICAL_IO function block accumulates the status of all safety-critical I/O modules in a Tricon controller.
TR_CRITICAL_IO
73
To get the status of all safety-critical I/O modules, invoke each module by specifying these input values: CHASSIS SLOT APP RELAY_OK
If CHASSIS 1 SLOT 1 is a critical DI module, and CHASSIS 1 SLOT 2 is a critical DO module with a relay, then this example applies. SCIO is the function block instance name:
SCIO(CHASSIS:=1,SLOT:=1,APP:=DE-ENERGIZED,RELAY_OK:=FALSE); SCIO(CHASSIS:=1,SLOT:=2,APP:=RELAY,RELAY_OK:=RELAY1_OK);
The output values are an accumulation of the status of all critical I/O modules. For example, the output called TMR is true if all of the critical modules in the system are in TMR mode.
Example
For shutdown examples, see this sample project: My Documents\Triconex\TriStation 1131 4.x\Projects\ExTUV.pt2
74
Appendix B
Runtime Errors
Condition If ERROR_NUM is non-zero Return Value Reset all BOOL outputs to false Error Flags BADPARAM, ERROR
Upon detection of a runtime error condition, the function block returns the indicated values and sets the error flags to true. For more information about error flags and runtime errors, see the CHK_ERR function block in the TriStation 1131 Libraries Reference.
Application Notes
Can be used in Safety or Control applications.
Library
Tricon (TR1LIB/TX1LIB)
Structured Text
FUNCTION_BLOCK TR_CRITICAL_IO VAR_INPUT CI : BOOL := TRUE ; (* Control in. *) INIT : BOOL ; (* Initialize *) CHASSIS : DINT ; (* Chassis number 1-15 *) SLOT : DINT ; (* Physical SLOT odd number 1,3..15 *) APP : DINT ; (* Application number 1-2 *) RELAY_OK : BOOL := TRUE ; (* Relay is energized and not stuck. *) END_VAR VAR_OUTPUT CO : BOOL ; (* Critical IO Control out. *) TMR : BOOL := TRUE ; (* Critical IO 3 channels operating. *) GE_DUAL : BOOL ; (* Critical IO 2 or more channels operating. *) GE_SINGLE : BOOL ; (* Critical IO 1 or more channels operating. *) NO_VOTER_FLTS : BOOL ; (* No voter faults on critical modules. *) ERROR : DINT ; (* Error number. *) (* * Error number: * 0 = No error. * -1 = Slot is not odd or not in 1..15. * -2 = Chassis or slot is invalid. * -3 = Module not configured. * -4 = Reserved (not used). * -5 = Application number is invalid. * -6 = Not initialized. *) END_VAR VAR PREVIOUS_INIT : BOOL ; (* INIT on previous evaluation. *) MP : TR_MP_STATUS ; (* MP status. *) LEFT_SLOT : TR_SLOT_STATUS ; (* Left slot status. *) RIGHT_SLOT : TR_SLOT_STATUS ; (* Right slot status. *) RELAY : DINT := 1 ; (* De-energized to trip with relay *) DE_ENERGIZED : DINT := 2 ; (* De-energized to trip with no relay *) U : BOOL ; (* Unused value. *) LEFT_GE_SINGLE : BOOL ; (* Left slot, mode >= single. *)
TR_CRITICAL_IO
75
LEFT_GE_DUAL : BOOL ; LEFT_TMR : BOOL ; RIGHT_GE_SINGLE : BOOL ; RIGHT_GE_DUAL : BOOL ; RIGHT_TMR : BOOL ; VOTER_FAULT : BOOL ; END_VAR
(* (* (* (* (* (*
Left slot, mode >= dual. *) Left slot, mode = tmr. *) Right slot, mode >= single. *) Right slot, mode >= dual. *) Right slot, mode = tmr. *) Voter fault on either slot. *)
(* *=F=============================================================================== * FUNCTION_BLOCK: TR_CRITICAL_IO * Purpose: Calculate status of critical IO modules. * * Return: none * * Remarks: * Usage * 1. Invoke once with INIT := TRUE, to initialize. * 2. Invoke again with INIT := FALSE, CI := TRUE, APP := DE_ENERGIZED, and * RELAY_OK := FALSE to complete initialization. * 3. Invoke repeatedly, once for each critical IO module. * 4. Read outputs CO, TMR, GE_DUAL, and GE_SINGLE for safety critical results. * * In step 3, invoke with the CHASSIS and SLOT of the critical IO module, * the module application, and the relay status. * For example, if CHASSIS 1 SLOT 5 is a critical DO module with a relay, * and SCIO is the function block instance name: * SCIO( CHASSIS:=1, SLOT:= 5, APP:=RELAY, RELAY_OK:=RELAY1_OK ); * * Slot Number * Each logical IO slot consists of two physical slots, * a left slot and a right slot. By convention, * the physical slot number of the left slot is always odd. * The SLOT parameter is the physical slot number of the left slot. * * Application * The APP parameter for a module selects the effect of a fault * on the vote mode outputs of the shutdown function blocks. * APP:=RELAY with RELAY_OK:=true * A single fault (even a voter fault) degrades the mode to DUAL. * The relay provides a third channel for shutdown, * so if an output voter fails, there are still * two independent channels that can de-energize the output, * i.e., the relay and the other output voter channel. * APP:=RELAY with RELAY_OK:=false, or * APP:=DE_ENERGIZED * A voter fault degrades the mode to SINGLE. * A non-voter fault degrades the mode to DUAL. * * Runtime Errors * EBADPARAM Bad parameter * CO=FALSE indicates a programming error. * See ERROR number parameter for details. *=F=============================================================================== *) IF INIT THEN MP( CI := TRUE ) ; CO := MP.CO ;
76
Appendix B
TMR := TRUE ; GE_DUAL := TRUE ; GE_SINGLE := TRUE ; NO_VOTER_FLTS := TRUE ; ELSIF PREVIOUS_INIT THEN ; (* No operation. *) ELSIF CI AND CO THEN IF (DINT_TO_DWORD(SLOT) AND 1) <> 1 OR SLOT<1 OR 15<SLOT THEN ERROR := -1 ; (* Slot is not odd or not in 1..15. *) U := ReportBadParam(0) ; CO := FALSE ; END_IF ; IF CO THEN LEFT_SLOT( CI := CI, CHASSIS := CHASSIS, SLOT := SLOT ) ; RIGHT_SLOT( CI := CI, CHASSIS := CHASSIS, SLOT := SLOT+1 ) ; IF NOT (LEFT_SLOT.CO AND RIGHT_SLOT.CO) THEN ERROR := -2 ; (* Chassis or slot is invalid. *) U := ReportBadParam(0) ; CO := FALSE ; END_IF ; END_IF ; IF CO THEN IF NOT ( LEFT_SLOT.PASS OR LEFT_SLOT.FAIL OR LEFT_SLOT.ACTIVE OR LEFT_SLOT.INSTALLED OR RIGHT_SLOT.PASS OR RIGHT_SLOT.FAIL OR RIGHT_SLOT.ACTIVE OR RIGHT_SLOT.INSTALLED ) THEN ERROR := -3 ; (* Module not configured. *) U := ReportBadParam(0) ; CO := FALSE ; END_IF ; END_IF ; IF CO THEN LEFT_GE_SINGLE := LEFT_SLOT.INSTALLED AND LEFT_SLOT.ACTIVE ; LEFT_GE_DUAL := LEFT_GE_SINGLE AND NOT LEFT_SLOT.NOGOOD ; LEFT_TMR := LEFT_GE_DUAL AND LEFT_SLOT.PASS AND NOT LEFT_SLOT.FAIL ; RIGHT_GE_SINGLE := RIGHT_SLOT.INSTALLED AND RIGHT_SLOT.ACTIVE ; RIGHT_GE_DUAL := RIGHT_GE_SINGLE AND NOT RIGHT_SLOT.NOGOOD ; RIGHT_TMR := RIGHT_GE_DUAL AND RIGHT_SLOT.PASS AND NOT RIGHT_SLOT.FAIL ; VOTER_FAULT := LEFT_SLOT.VOTER_FAULT OR RIGHT_SLOT.VOTER_FAULT ; TMR := TMR AND (LEFT_TMR OR RIGHT_TMR) ; GE_DUAL := GE_DUAL AND (LEFT_GE_DUAL OR RIGHT_GE_DUAL) ; GE_SINGLE := GE_SINGLE AND (LEFT_GE_SINGLE OR RIGHT_GE_SINGLE) ; NO_VOTER_FLTS := NO_VOTER_FLTS AND NOT VOTER_FAULT ; IF APP = RELAY AND RELAY_OK THEN TMR := TMR AND NOT VOTER_FAULT ; ELSIF APP = DE_ENERGIZED OR APP = RELAY AND NOT RELAY_OK THEN TMR := TMR AND NOT VOTER_FAULT ; GE_DUAL := GE_DUAL AND NOT VOTER_FAULT ; ELSE ERROR := -5 ; (* Application number is invalid *) U := ReportBadParam(0) ; CO := FALSE ; END_IF ; END_IF ;
TR_CRITICAL_IO
77
END_IF ; IF ERROR = 0 AND NOT CO THEN ERROR := -6 ; U := ReportBadParam(0) ; END_IF ; IF NOT CO THEN TMR := FALSE ; GE_DUAL := FALSE ; GE_SINGLE := FALSE ; NO_VOTER_FLTS := FALSE ; END_IF ; PREVIOUS_INIT := INIT ; END_FUNCTION_BLOCK
(* Not initialized *)
78
Appendix B
TR_SHUTDOWN
Enables a Tricon system shutdown according to industry guidelines.
Syntax
MY_TR_SHUTDOWN( CI:=b1, IO_CO:=b2, IO_TMR:=b3, IO_GE_DUAL:=b4, IO_GE_SINGLE:=b5, IO_NO_VOTER_FLTS:=b6, IO_ERROR:=n1, MAX_TIME_DUAL:=t1, MAX_TIME_SINGLE:=t2, MAX_SCAN_TIME:=t3 ) ;
Input Parameters
Name CI IO_CO IO_TMR IO_GE_DUAL IO_GE_SINGLE IO_NO_VOTER_FLTS IO_ERROR MAX_TIME_DUAL MAX_TIME_SINGLE MAX_SCAN_TIME Data Type BOOL BOOL BOOL BOOL BOOL BOOL DINT TIME TIME TIME Description Enables TR_SHUTDOWN. True if TR_SHUTDOWN executes successfully. Three channels are operating without fatal faults detected. Two channels are operating without fatal faults detected. One channel is operating without fatal faults detected. No failed critical modules detected. Zero = no error. Non-zero = programming or configuration error. The maximum time of continuous operation in dual mode (two channels operating). The maximum time of continuous operation in single mode (one channel operating). 50% of the maximum response time.
Output Parameters
Name CO OPERATING TMR DUAL SINGL ZERO TIMER_RUNNING TIME_LEFT ALARM_PROGRAMMING_PERMITTED ALARM_REMOTE_ACCESS Data Type BOOL BOOL BOOL BOOL BOOL BOOL BOOL TIME BOOL BOOL Description True if TR_SHUTDOWN executes successfully. If false, shut down. Three channels are operating. Two channels are operating. One channel is operating. No channels are operating. The shutdown timer is running The time remaining to shutdown. True if application changes are permitted. True if remote-host writes are enabled.
TR_SHUTDOWN
79
Description
The TR_SHUTDOWN function block enables a Tricon system shutdown according to industry guidelines.
Example
For shutdown examples, see this sample project: My Documents\Triconex\TriStation 1131 4.x\Projects\ExTUV.pt2
Runtime Errors
Condition If ERROR is non-zero Return Value Set alarm outputs to true, reset the other BOOL outputs to false, and reset TIME_LEFT to zero. Error Flags BADPARAM, ERROR
Upon detection of a runtime error condition, the function block returns the indicated values and sets the error flags to true. For more information about error flags and runtime errors, see the CHK_ERR function block. If a programming error or configuration error occurs, then CO is false and the error number is non-zero. For error numbers, see the description of the ERROR output.
Application Notes
Can be used in Safety or Control applications.
Library
Tricon (TR1LIB/TX1LIB)
80
Appendix B
Structured Text
FUNCTION_BLOCK TR_SHUTDOWN VAR_INPUT CI : BOOL := TRUE ; (* Control in. *) IO_CO : BOOL ; (* Critical IO Control out. *) IO_TMR : BOOL ; (* Critical IO 3 channels operating. *) IO_GE_DUAL : BOOL ; (* Critical IO 2 or more channels operating. *) IO_GE_SINGLE : BOOL ; (* Critical IO 1 or more channels operating. *) IO_NO_VOTER_FLTS : BOOL ; (* No voter faults on critical modules. *) IO_ERROR : DINT ; (* Error number, 0 = no error. *) MAX_TIME_DUAL : TIME := T#40000d ; (* Max Time with only 2 channels. *) MAX_TIME_SINGLE : TIME := T#40000d ; (* Max Time with only 1 channel. *) MAX_SCAN_TIME : TIME := T#400ms ; (* 50% of Max Response Time. *) END_VAR VAR_OUTPUT CO : BOOL ; (* Control out. *) OPERATING : BOOL ; (* Shutdown if OPERATING=FALSE. *) TMR : BOOL ; (* Three channels operating. *) DUAL : BOOL ; (* Dual mode. *) SINGL : BOOL ; (* Single mode. *) ZERO : BOOL ; (* Zero mode. *) TIMER_RUNNING : BOOL ; (* Shutdown timer is running. *) TIME_LEFT : TIME ; (* Time remaining to shutdown. *) ALARM_PROGRAMMING_PERMITTED : BOOL ; (* Alarm -- download change. *) ALARM_REMOTE_ACCESS : BOOL ; (* Alarm -- remote host writes. *) ALARM_RESPONSE_TIME : BOOL ; (* Alarm -- exceed response time. *) ALARM_DISABLED_POINTS : BOOL ; (* Alarm -- some points disabled. *) ERROR : DINT ; (* Error number. *) (* * Error number: * 0 = No error. * 1 = Error in maximum time. * 2 = IO function block error - IO_ERROR is non-zero. * 3 = Status function block error. *) END_VAR VAR GE_DUAL : BOOL ; (* Two or more channels operating. *) GE_SINGLE : BOOL ; (* One or more channels operating. *) MP : TR_MP_STATUS ; (* MP status. *) PROG : TR_PROGRAM_STATUS ; (* Program status. *) SCAN : TR_SCAN_STATUS ; (* Scan status. *) DUAL_TIME : TON ; (* Dual mode timer. *) SINGLE_TIME : TON ; (* Single mode timer. *) U : BOOL ; (* Unused Value. *) END_VAR (* *=F=============================================================================== * FUNCTION_BLOCK: TR_SHUTDOWN * Purpose: Implement TUV restrictions. * * Return: none * * Remarks: * * Example EX01_SHUTDOWN shows one way to check that * the safety system is operating within spec when
TR_SHUTDOWN
81
* every module in the safety system is safety critical. * The example uses the Tricon Library function block * TR_SHUTDOWN - one instance named CRITICAL_MODULES. * The output CRITICAL_MODULES.OPERATING indicates * that all safety critical modules are operating * within spec. Input MAX_TIME_DUAL specifies the * maximum time allowed with two channels operating * (for example, 1500 hours). * Input MAX_TIME_SINGLE specifies the maximum time allowed * with only one channel operating (for example, 72 hours). * When CRITICAL_MODULES.OPERATING is FALSE, * the time in degraded operation exceeds the * specified limits -- therefore the control program * should shutdown the plant. * * Excluding output voter faults and field faults -- TMR implies * three channels with no detected fatal errors, GE_DUAL implies * at least two channels with no detected fatal errors, * and GE_SINGLE implies at least one channel * with no detected fatal errors -- for every path * from a safety critical input to a safety critical output. * Detected output voter faults reduce TMR or GE_DUAL to GE_SINGLE. * (See example EX02_SHUTDOWN to improve availability * using relays and advanced programming techniques.) * * The "TMR" output indicates TMR. * The "DUAL" output indicates GE_DUAL but not TMR. * The "SINGL" output indicates GE_SINGLE but not GE_DUAL. * The "ZERO" output indicates not GE_SINGLE. * The "TIMER_RUNNING" output indicates that * the time left to shutdown is decrementing. * The "TIME_LEFT" output indicates the time remaining before shutdown. * * WARNING - the TR_SHUTDOWN function block * does not use detected field faults or * combinations of faults reported as field faults. * It is the responsibility of the application program * to use system variable NoFieldFault or FieldOK * to detect and respond to such faults. * * To see how to create a user-defined function block * to improve availability, see the examples * in the help topic for TR_SHUTDOWN. * * NOTE -- If IO_CO is false (for example, if you do not provide * a user-defined function block like the one in example EX02_SHUTDOWN), * then losing all three legs of an active IO module results in * a transition to "SINGL", not "ZERO". * * Runtime Errors * EBADPARAM Bad parameter * CO=FALSE indicates a programming error. * See ERROR number parameter for details. *=F=============================================================================== *) IF CI THEN (* Get Status *) MP( CI := TRUE ) ;
82
Appendix B
PROG( CI := TRUE ) ; SCAN( CI := TRUE ) ; (* Check for programming errors. *) ERROR := 0 ; IF MAX_TIME_DUAL < MAX_TIME_SINGLE OR MAX_TIME_DUAL < T#0S OR MAX_TIME_SINGLE < T#0S OR MAX_SCAN_TIME < T#0S THEN ERROR := 1 ; ELSIF IO_ERROR <> 0 THEN ERROR := 2 ; ELSIF NOT (MP.CO AND PROG.CO AND SCAN.CO) THEN ERROR := 3 ; END_IF ; CO := ERROR = 0 ; IF CO THEN (* Summarize redundancy. *) TMR := NOT MP.MPMAIN AND ( NOT IO_CO AND NOT MP.IOMAIN OR IO_CO AND IO_TMR ); GE_DUAL := NOT MP.MPBAD AND ( NOT IO_CO AND NOT MP.IOBAD OR IO_CO AND IO_GE_DUAL ); GE_SINGLE := ( NOT IO_CO OR IO_CO AND IO_GE_SINGLE ); (* Update timers. *) DUAL_TIME( IN := NOT TMR, PT := MAX_TIME_DUAL ) ; SINGLE_TIME( IN := NOT GE_DUAL, PT := MAX_TIME_SINGLE ) ;
(* Shutdown if excessive time in degraded operation. *) OPERATING := GE_SINGLE AND NOT DUAL_TIME.Q AND NOT SINGLE_TIME.Q ; (* Output current status. *) DUAL := GE_DUAL AND NOT TMR ; SINGL := GE_SINGLE AND NOT GE_DUAL ; ZERO := NOT GE_SINGLE ; TIMER_RUNNING := OPERATING AND NOT TMR ; (* Output time remaining to shutdown. *) IF NOT OPERATING THEN
TR_SHUTDOWN
83
TIME_LEFT := T#0s ; ELSIF TMR THEN TIME_LEFT := T#999999d ; ELSIF GE_DUAL OR MAX_TIME_DUAL-DUAL_TIME.ET <= MAX_TIME_SINGLE-SINGLE_TIME.ET THEN TIME_LEFT := MAX_TIME_DUAL - DUAL_TIME.ET ; ELSE TIME_LEFT := MAX_TIME_SINGLE - SINGLE_TIME.ET ; END_IF ; (* Output alarms. *) ALARM_PROGRAMMING_PERMITTED := SCAN.KEYSWITCH = 1 (*1=PROGRAM*) ; ALARM_REMOTE_ACCESS := SCAN.KEYSWITCH <> 2 ; (*2=RUN*) ALARM_RESPONSE_TIME := T#1ms * SCAN.SCANDELTA > MAX_SCAN_TIME ; ALARM_DISABLED_POINTS := PROG.POINTS_DISABLED > 0 ; ELSE (* Programming error. *) U := ReportBadParam(0) ; OPERATING := TMR := GE_DUAL := GE_SINGLE := DUAL := SINGL := ZERO := TIMER_RUNNING := TIME_LEFT := FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE T#0S; ; ; ; ; ; ; ; ;
; ; ; ;
84
Appendix B
TR_VOTE_MODE
Converts redundancy status.
Syntax
MY_TR_VOTE_MODE( CI:=b1, IN_TMR:=b2, GE_DUAL:=b3, GE_SINGLE:=b4 ) ;
Input Parameters
Name CI IN_TMR GE_DUAL GE_SINGLE Data Type BOOL BOOL BOOL BOOL Description Enables TR_VOTE_MODE. Three channels are operating. Two or more channels are operating. One or more channels are operating.
Output Parameters
Name CO TMR DUAL SINGL ZERO Data Type BOOL BOOL BOOL BOOL BOOL Description True if TR_VOTE_MODE executes successfully. Three channels are operating. Two or more channels are operating. One or more channels are operating. No channels are operating.
Description
The TR_VOTE_MODE function block converts redundancy status, as shown in this truth table. Truth Table
TMR T F F F Other1 GE_DUAL T T F F GE_SINGLE T T T F TMR T F F F F DUAL F T F F F SINGL F F T F F ZERO F F F T F
1. If an error in the inputs occurs, then CO is false, the mode outputs are false, and the function block reports a bad parameter error (BADPARAM).
Note
TR_VOTE_MODE
85
Example
For shutdown examples, see this sample project: My Documents\Triconex\TriStation 1131 4.x\Projects\ExTUV.pt2
Runtime Errors
Condition If the inputs do not match one of the first four rows of the truth table Return Value Reset all BOOL outputs to false Error Flags BADPARAM, ERROR
Upon detection of a runtime error condition, the function block returns the indicated values and sets the error flags to true. For more information about error flags and runtime errors, see the CHK_ERR function block in the TriStation 1131 Libraries Reference.
Application Notes
Can be used in Safety or Control applications. Space Saver: a single instance can be executed more than once per scan to reduce memory usage and increase performance. For directions, see the TriStation 1131 Libraries Reference.
Library
Tricon (TR1LIB/TX1LIB)
Structured Text
FUNCTION_BLOCK TR_VOTE_MODE VAR_INPUT CI : BOOL := TRUE ; IN_TMR : BOOL ; GE_DUAL : BOOL ; GE_SINGLE : BOOL ; END_VAR VAR_OUTPUT CO : BOOL ; TMR : BOOL ; DUAL : BOOL ; SINGL : BOOL ; ZERO : BOOL ; END_VAR VAR U : BOOL ; END_VAR
(* (* (* (*
Control in. *) 3 channels operating. *) 2 or more channels operating. *) 1 or more channels operating. *)
(* (* (* (* (*
Control out. *) Triple Modular Redundant. *) Dual mode. *) Single mode. *) Zero mode. *)
(* Unused Value. *)
86
Appendix B
* Remarks: * 1. Convert redundancy status (TMR, GE_DUAL, GE_SINGLE) * to (TMR, DUAL, SINGL, ZERO). * 2. "GE_" denotes "greater than or equal to". * 3. CO is true if CI is true and there is no programming error. * * Runtime Errors * EBADPARAM Bad parameter * CO=false indicates a programming error if CI=true. * The outputs are all false if there is a programming error. *=F============================================================================== *) CO := CI ; IF CI THEN CO := GE_DUAL IF CO THEN TMR := DUAL := SINGL := ZERO := ELSE U := TMR := DUAL := SINGL := ZERO := END_IF ; END_IF ; END_FUNCTION_BLOCK
AND GE_SINGLE OR NOT GE_DUAL AND NOT IN_TMR; IN_TMR ; GE_DUAL AND NOT IN_TMR ; GE_SINGLE AND NOT GE_DUAL ; NOT GE_SINGLE ; ReportBadParam(0) ; FALSE ; FALSE ; FALSE ; FALSE ;
Index
A
abbreviations, list of vii actual scan time 46 alarms analog input module 37 analog output module 37 digital input module 36 digital output modules 36 disabled points 20, 58 I/O modules 38 output operation 53 programming permitted 58 pulse input module 37 relay output module 38 remote access 58 semaphore flags 39 system attributes 39 analog input module alarms 37 diagnostics 36 analog output module alarms 37 diagnostics 37 analysis, hazard and risk 5 ANSI/ISA S84.01 13 application-specific standards 13, 14 architecture, system 32 array index errors 43
communication external 39 for maintenance overrides 27 Compare to Last Download command 45 CSA C22.2 NO 199 14 customer support ix
B
burner management systems, guidelines 18 bus, Tribus 32
C
calculating PFDavg , equation for sensors 7 calculations, SIL examples 7 certification, TV Rheinland 16 change control 26 commands Compare to Last Download 45 Download All 20 Download Change 44 Verify Last Download to Controller 45
data transfer time 6166 DCS programs, recommendations 29 design requirements 28 development guidelines 42 diagnostics analog input module 36 analog output module 37 digital input module 36 digital output module 36 disable output voter 20 pulse input module 37 relay output module 38 system 33 digital input module alarms 36 diagnostics 36 digital output module alarms 36 diagnostics 36 DIN V 19250 12 DIN V VDE 0801 12 disable output voter diagnostics 20 disabled points alarms 20, 58 Download All command 20 Download Change command 44
E
emergency shutdown systems, guidelines 18 EN 50156 13 EN 54, part 2 13 equations, calculating PFDavg for sensors 7 EX01_shutdown program 48 EX02_shutdown program 52 EX03_shutdown program 57 external communication 39
88
Index
external faults 34
F
factors SIL 4 SIS 4, 5 faults external 34 internal 34 safety-critical 35 types 34 fire and gas systems, guidelines 18 flags, semaphore 39 function blocks GATDIS 69 GATENB 70 TR_URCV 66 TR_USEND 66 Triconex Peer-to-Peer 6466 functions, Modbus master 20
IEC 61508, parts 17 12 infinite loops 43 input module alarms analog 37 digital 36 pulse 37 input module diagnostics analog 36 digital 36 pulse 37 internal faults 34
K
keyswitch settings 23
L
layers, protection 5
M
Main Processor, Tribus 38 maintenance overrides design requirements for handling 28 guidelines 2730 methods for 27 operating requirements for handling 29 Modbus master functions 20 modes, operating 35 module alarms analog input 37 analog output 37 digital input 36 digital output 36 I/O 38 pulse input 37 relay output 38 module diagnostics analog input 36 analog output 37 digital input 36 digital output 36 pulse input 37 relay output 38 module faults, I/O 38 module processors, I/O 38 modules safety-critical 19 system-critical shutdown program for all 47 system-critical shutdown program for some 51
G
GATDIS function block 69 gate disable 69 gate enable 70 GATENB function block 70 guidelines all safety systems 17 burner management systems 18 development 42 emergency shutdown systems 18 fire and gas systems 18 general 17 maintenance overrides 2730 SIL 2326 SIL fire and gas 24, 26 SIL general 23, 24 Tricon controller 19
H
hazard and risk analysis 5 HAZOP 5
I
I/O bus faults 38 integrity of 38 I/O modules alarms 38 processors 38 status 72 system-critical 47
N
NFPA 72 13 NFPA 85 14
Index
89
O
operating modes 35 output module alarms analog 37 digital 36 relay 38 output module diagnostics analog 37 digital 36 relay 38 output operation alarms 53 output parameters 49 output voter diagnostics 20 OVD, See output voter diagnostics overrides, maintenance 27 overrides, maintenance guidelines 2730 overrun, scan 46 overview, safety 5
R
relay output module alarms 38 diagnostics 38 remote access 70 remote access alarms 58 Remote mode 23 remote write access 69 requested scan time 46 requirements, design 28 response time and scan time 20, 58 risk probability 6 risk reduction factor 6 risks, described 6
P
parameters, output 49 partitioning processes 55 Peer-to-Peer communication description of function blocks for 60 overview 20, 60 Peer-to-Peer function blocks data transfer time 61 errors 63 examples 64 rules for correct usage 60 using with critical data 21 permitted alarms, programming 58 PFDavg for sensors, equation for calculating 7 points, disabled 58 processes, partitioning 55 processors, I/O modules 38 Product Alert Notices 42 Program mode 23 programmable electronic systems 4 programming permitted alarms 58 programs EX01_shutdown 48 EX02_shutdown 52 EX03_shutdown 57 recommendations for DCS programs 29 safety-shutdown for all system-critical I/O modules 47 safety-shutdown for some system-critical I/O modules 51 project change and control 26 protection layers 3, 5
S
safety attribute 42 methods 2 overview 5 requirement specifications 10 safety integrity levels, See SILs safety life cycle model 9 PES steps 1011 safety systems, guidelines 17 safety-critical faults 35 modules 19 safety-instrumented systems, See SISs safety-shutdown networks 20 overview 20 programs for all system-critical I/O modules modules 47 programs for some system-critical I/O modules 51 scan overrun 46 scan surplus 44, 46 scan time actual 46 allowable exceeded 43 overview 46 requested 46 response time and 20, 58 semaphore flags 39 SEND function, peer-to-peer communication 21 sensors, equation for calculating PFDavg 7 serial communication, operating requirements 29
90
Index
shutdown programs for all system-critical I/O modules 47 programs for some system-critical I/O modules 51 safe 20 system emergencies 18 TR_CRITICAL_IO function block 72 TR_SHUTDOWN function block 78 TR_VOTE_MODE 84 SILs calculation examples 7 determining 6, 8 factors 4 fire and gas guidelines 24, 26 guidelines 2326 SIS factors 4, 5 specifications, safety requirements 10 standards application-specific 13, 14 general safety 1213 relation to SILs 6 status, critical I/O modules 72 surplus, scan 46 system architecture 32 attributes as alarms 39 availability 6 burner management 18 diagnostics 33 emergency shutdown 18 fire and gas 18 system-critical I/O modules safety-shutdown program for all 47 safety-shutdown program for some 51
V
VAR_IN_OUT variables 42 Verify Last Download to Controller command 45 voter diagnostics, disable output 20
W
watchdog period 38 write access 69
T
technical support ix time, scan 46 TMR architecture 32 TR_CRITICAL_IO function block 72 TR_SHUTDOWN function block 78 TR_URCV function blocks 6466 TR_USEND function blocks 6466 TR_VOTE_MODE function block 84 training viii Tribus Main Processor 38 system architecture 32 Triconex contact information viii Triconex Peer-to-Peer function blocks 6466 TV Rheinland certification 16 types of faults 34