Safety Considerations Guide for Trident v2 Systems - TUV ...

More documents

Recommendations

Info

64 Appendix A Triconex Peer-to-Peer Communication Overview Triconex Peer-to-Peer protocol is designed to allow multiple Triconex controllers in a closed network to exchange safety-critical data. (If you plan to implement a complex Peer-to-Peer network, please contact the Invensys Global Customer Support (GCS) Center.) To enable Peerto-Peer communication, you must connect each controller (also referred to as a node) to an Ethernet network by means of an Ethernetport on theCM. The controllers exchange data by using Send and Receive function blocks in their TriStation 1131 applications. CM MP Tri-GP Controller Peer-to-Peer Network N N M M M C C P P P MM ABC 1 2 Tricon Controller Figure 13 Basic Triconex Peer-to-Peer Network To configure a TriStation 1131 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 65. The sample programs described in this appendix can be found in the Tdpeer.pt2 project included as part of the TriStation 1131 software 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 Trident v2 Systems. Safety Considerations Guide for Trident v2 Systems CM MP Trident Controller
Data Transfer Time Data Transfer Time 65 In a Peer-to-Peer application, data transfer time includes the time required to initiate a send operation, send the message over the network, and have the message read by the receiving node. Additional time (at least two scans) is required for a sending node to get an acknowledgment from the MPs that the message has been acted on. These time periods are a function of the following parameters of the sending and receiving controllers: • Scan time • Configuration size • Number of bytes for aliased variables • Number of SEND function blocks, RECEIVE function blocks, printing function blocks, and Modbus master function blocks • Number of controllers (nodes) on the Peer-to-Peer network 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. Estimating Memory for Peer-to-Peer Data Transfer Time This procedure explains how to estimate memory for Peer-to-Peer data transfer time between a pair of Triconex controllers (nodes). The more memory allocated for aliased points the slower the transfer time. Procedure 1 In the TriStation 1131 software, on the sending controller, expand the Controller tree, and double-click Configuration. On the Configuration tree, click Memory Allocation. 2 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. 3 On the receiving controller, get the BOOL, DINT, and REAL points and enter the numbers on step 3 of the Data Transfer Time worksheet. Estimating the Data Transfer Time The basic formula for estimating the data transfer time is as follows: • Data transfer time in milliseconds = 2 * (larger of TS or SS) + 2 * (larger of TR or SR) Safety Considerations Guide for Trident v2 Systems
Page 1 and 2:
Trident v2 Systems Safety Considera
Page 3 and 4:
Contents Preface vii Summary of Sec
Page 5 and 6:
Contents v Partitioned Processes. .
Page 7 and 8:
Preface This guide provides informa
Page 9 and 10:
• All other requests are handled
Page 11 and 12:
1 Safety Concepts Overview 2 Hazard
Page 13 and 14:
Protection Layers Methods that prov
Page 15 and 16:
Hazard and Risk Analysis Hazard and
Page 17 and 18:
Sample SIL Calculation Hazard and R
Page 19 and 20:
Safety Life Cycle Model Hazard and
Page 21 and 22:
Hazard and Risk Analysis 11 • Eac
Page 23 and 24: CAN/CSA-C22.2 No. 61010-1-04 Safety
Page 25 and 26: 2 Application Guidelines Overview 1
Page 27 and 28: General Guidelines This section des
Page 29 and 30: General Guidelines 19 Safety Measur
Page 31 and 32: Emergency Shutdown Systems The safe
Page 33 and 34: Safety-Shutdown Guidelines for Tric
Page 35 and 36: Guidelines for Triconex Controllers
Page 43 and 44: 3 Fault Management Overview 34 Syst
Page 45 and 46: System Diagnostics System Diagnosti
Page 47 and 48: Operating Modes Each input or outpu
Page 49 and 50: Analog Output (AO) Modules Module D
Page 51 and 52: Calculation for Diagnostic Fault Re
Page 53 and 54: External Communication Module Diagn
Page 55 and 56: 4 Application Development Developme
Page 57 and 58: Array Index Errors Infinite Loops D
Page 59 and 60: Setting Scan Time 49 application. T
Page 61 and 62: Sample Safety-Shutdown Programs Sam
Page 63 and 64: Sample Safety-Shutdown Programs 53
Page 65 and 66: When Some I/O Modules Are Safety-Cr
Page 67 and 68: Sample Safety-Shutdown Programs 57
Page 69 and 70: Partitioned Processes Sample Safety
Page 71 and 72: Alarm Usage Alarm Usage 61 To imple
Page 73: A Triconex Peer-to-Peer Communicati
Page 77 and 78: Data Transfer Time 67 A typical dat
Page 79 and 80: Examples of Peer-to-Peer Applicatio
Page 81 and 82: B HART Communication Overview 72 HA
Page 83 and 84: 2008-04-01 Automation, Software and
Page 85 and 86: 2008-04-01 HART Position Paper from
Page 87 and 88: 2008-04-01 A possible impact to the
Page 89 and 90: 2008-04-01 HART Position Paper from
Page 91 and 92: C Safety-Critical Function Blocks O
Page 93 and 94: SYS_CRITICAL_IO Accumulates the sta
Page 95 and 96: Library Trident and Tri-GP (TRDLIB)
Page 97 and 98: END_IF ; PREVIOUS_RESET := RESET ;
Page 99 and 100: Output Parameters (continued) Name
Page 101 and 102: SYS_SHUTDOWN 91 * the safety system
Page 103 and 104: ALARM_DISABLED_POINTS := MPX.POINTS
Page 105 and 106: Example For shutdown examples, see
Page 107 and 108: A abbreviations, list of viii actua
Page 109 and 110: message errors, external communicat
Page 112: Invensys Operations Management 5601
show all

Safety Considerations Guide for Trident v2 Systems - TUV ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?