Safety Considerations Guide Tricon v9 6

Tricon Version 9
Safety Considerations Guide
Triconex Corporation An Invensys company
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 Corporation. 2001 Triconex Corporation. All Rights Reserved. Microsoft, Windows, and Windows NT are registered trademarks of Microsoft Corporation. Modbus is a registered trademark of Modicon Corporation. Triconex is a registered trademark of Triconex Corporation in the USA and other countries. TriStation 1131 and Tricon are trademarks of Triconex Corporation in the USA and other countries. All other brands or product names may be trademarks or registered trademarks of their respective owners.
Document No. 9720078-002 Printed in the United States of America.
Acknowledgement
Triconex acknowledges the generous assistance of TV Rheinland/BerlinBrandenburg in the development of this guide. In addition, their efforts have contributed to the overall quality and integrity of the Tricon system. 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.
About This Guide
This manual provides information about safety concepts and standards that apply to the Tricon controller.
How This Guide Is Organized

This manual is organized as follows: 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, Peer-to-Peer CommunicationDescribes the function blocks intended for use in safety-critical applications and shows their Structured Text code.
Tricon Safety Considerations Guide
vi
Related Documents
Related Documents
The following manuals contain information that is relevant to the use of the system. Advanced Communication Module User's Guide Enhanced Intelligent Communication Module User's Manual Hiway Interface Module User's Guide Network Communication Module User's Guide Safety Manager Module User's Guide Tricon DDE Server User's Guide Tricon System Access Application Programmer's Reference Tricon System Aliases Reference Manual Tricon Planning & Installation Guide TriStation 1131 Developer's Guide for Tricon Systems TriStation 1131 Getting Started for Tricon Users TriStation 1131 Triconex Libraries
Abbreviations Used vii
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. BPCS ESD HAZOP MOC MTBF PES PFD PHA PSM RMP RRF SIL SIS SOV SRS SV Basic process control system Emergency shutdown Hazard and operability study Management of change Mean time between failure Programmable electronic system Probability to fail on demand Process hazard analysis Process safety management Risk management program Risk reduction factor Safety integrity level Safety-instrumented system Solenoid-operated valve Safety requirements specification Safety (relief) valve
viii
How to Contact Triconex
How to Contact Triconex

You can obtain sales information and technical support for Triconex products from any regional customer center or from corporate headquarters. To locate regional centers, go to which displays the Global Locator page on the Triconex web site at: http://www.triconex.com.
Requesting Technical Support

You can obtain technical support from any regional center and from offices in Irvine, California and Houston, Texas. If you require emergency or immediate response and are not a participant in the System Maintenance Program (SMP), you may incur a charge. After-hours technical support is billed at the rate specified in the current Customer Satisfaction Price List. Requests for support are prioritized as follows: Emergency requests are given the highest priority. Requests from SMP participants and customers with purchase order or charge card authorization are given next priority. All other requests are handled on a time-available basis.
Gathering Supporting Documentation

Before contacting corporate technical support, please try to solve the problem by referring to the Triconex documentation. If you are unable to solve the problem, obtain the following information: Error messages and other indications of the problem Sequence of actions leading to the problem Actions taken after the problem occurred If the problem involves a Triconex controller, obtain the model numbers and revision levels for all affected items. This information can be found on the modules, in the System Log Book, or on the TriStation Diagnostic Panel. If the problem involves software, obtain the product version number by selecting the About topic from the Help menu.
Requesting Technical Support ix
Contacting Triconex Technical Support

If possible, you should contact your regional customer center for assistance. If you cannot contact your regional center, contact technical support for the type of system you are using, either ESD systems or Turbomachinery systems. Please include the following information in your message: Your name and your company name. Your location (city, state, and country). Your phone number (area code and country code, if applicable). The time you called. Whether this is an emergency. Note If you require emergency support and are not an SMP participant, please have a purchase order or credit card available for billing.
For ESD Systems

For ESD systems, contact the Customer Response Center in Irvine, California. Normal business hours are 8:00 A.M. to 5:00 P.M. (Pacific time), Monday through Friday.You can leave a message at any time. Emergency calls are responded to on a 24-hour daily basis. Telephone Phone: Toll-free at 866-TMR-CALL (866-867-2255), or 949-885-0800 Fax Send your request to the Technical Support Manager. Fax: Toll-free at 800-325-2134, or 949-753-9101
Training
For Turbomachinery Systems

For turbomachinery systems, contact the Customer Response Center in Houston, Texas. Normal business hours are 8:00 A.M. to 5:00 P.M. (Central time), Monday through Friday. You can leave a message at any time. Emergency calls are responded to on a 24-hour daily basis. Telephone Phone: Toll-free at 866-TMC-HELP (866-862-4357), or 281-709-1200 Fax Send your request to the Technical Support Manager. Fax: 281-709-0015
Training
In addition to this documentation, Triconex offers in-house and on-site training. For information on available courses, please contact your regional customer center.
xi
xii
xi
CONTENTS
About This Guide .................................................................................................... v

How This Guide Is Organized ........................................................................ v Related Documents ....................................................................................... vi Abbreviations Used ...................................................................................... vii How to Contact Triconex ............................................................................. viii Requesting Technical Support ................................................................... viii Gathering Supporting Documentation ...................................................... viii Contacting Triconex Technical Support .................................................... ix For ESD Systems ............................................................................... ix For Turbomachinery Systems ............................................................. x Training ........................................................................................................... x
Chapter 1
Safety Concepts ........................................................................... 1

Safety Overview .............................................................................................. Protection Layers ....................................................................................... SIS Factors ................................................................................................ SIL Factors ................................................................................................. 2 3 4 4
Hazard and Risk Analysis .............................................................................. 5 Safety Integrity Levels ................................................................................ 6 Determining a Safety Integrity Level ................................................... 6 Example SIL Calculation ............................................................................ 8 Safety Life Cycle Model ........................................................................... 10 Safety Standards .......................................................................................... General Safety Standards ........................................................................ DIN V 19250 ...................................................................................... DIN V VDE 0801 ............................................................................... IEC 61508, Parts 17 ........................................................................ ANSI/ISA S84.01 ............................................................................... Draft IEC 61511, parts 13 ................................................................ Application-Specific Standards ................................................................ DIN VDE 0116 ................................................................................... EN 54, Part 3 ..................................................................................... NFPA 72 ............................................................................................ NFPA 8501 ........................................................................................ 15 15 15 15 16 16 16 17 17 17 17 17
xii
NFPA 8502 ....................................................................................... 17 CSA C22.2 NO 199 ........................................................................... 17
Chapter 2
Application Guidelines .............................................................. 19

TV Rheinland Certification ....................................................................... 20 General Guidelines ...................................................................................... All Safety Systems .................................................................................. Emergency Shutdown Systems .............................................................. Burner Management Systems ................................................................. Fire and Gas Systems ............................................................................. Guidelines for Tricon Controllers ............................................................... Safety-Critical Modules ........................................................................... Safety-Shutdown ..................................................................................... Response Time and Scan Time .............................................................. Disabled Points Alarm ............................................................................. Disabled Output Voter Diagnostic ........................................................... Download All at Completion of Project .................................................... Modbus Master Functions ....................................................................... Peer-to-Peer Communication .................................................................. Sending Node ................................................................................... Receiving Node ................................................................................. SIL3/AK5 Guidelines ............................................................................... Additional Fire and Gas Guidelines .................................................. SIL3/AK6 Guidelines ............................................................................... Additional Fire and Gas Guidelines .................................................. Project Change and Control .................................................................... Maintenance Overrides ........................................................................... Using Serial Communication ............................................................. Additional Recommendations .................................................................. 20 20 21 21 22 23 24 24 24 24 25 25 25 25 25 26 27 28 29 30 30 32 32 35
Chapter 3
Fault Management ..................................................................... 37

System Architecture .................................................................................... 38 System Diagnostics ..................................................................................... 39 Types of Faults ............................................................................................. 40 External Faults ........................................................................................ 40 Internal Faults .......................................................................................... 40 Operating Modes .......................................................................................... 41 Module Diagnostics ..................................................................................... Digital Input Modules ............................................................................... Digital Input Module Alarms .............................................................. Digital Output Modules ............................................................................ Digital Output Module Alarms ........................................................... Analog Input Modules .............................................................................. 43 43 43 43 43 44
xiii
Analog Input Module Alarms ............................................................. Analog Output Modules ........................................................................... Analog Output Module Field Alarms .................................................. Relay Output Modules ............................................................................. Relay Output Module Alarms ............................................................ Input/Output Processing .......................................................................... I/O Module Alarms ............................................................................. Main Processor and TriBus ...................................................................... External Communication .......................................................................... Semaphore Flags .............................................................................. System Attributes ..............................................................................
44 44 44 45 45 45 45 46 46 46 47
Chapter 4
Application Development .......................................................... 49

Development Guidelines ............................................................................. 50 TriStation Install Check ......................................................................... 50 Important TriStation Commands ................................................................ Download Change ................................................................................... Upload and Verify .................................................................................... Compare to Last Download ..................................................................... Setting Scan Time ........................................................................................ Scan Time ................................................................................................ Scan Surplus ............................................................................................ Scan Overruns .................................................................................. Sample Safety-Shutdown Programs .......................................................... All I/O Modules Safety-Critical ................................................................. Program EX01_SHUTDOWN ............................................................ Some I/O Modules Safety-Critical ............................................................ Program EX02_SHUTDOWN ............................................................ Defining Function Blocks ......................................................................... Partitioned Processes .............................................................................. Program EX03_SHUTDOWN ............................................................ Alarm Usage ................................................................................................. Programming Permitted Alarm ................................................................. Remote Access Alarm ............................................................................. Response Time and Scan Time ............................................................... Disabled Points Alarm .............................................................................. 51 51 52 52 53 53 53 54 55 55 56 60 61 65 66 67 68 68 68 68 68
Appendix A
Peer-to-Peer Communication .................................................... 69

Data Transfer Time ....................................................................................... 70
xiv
Examples of Peer-to-Peer Applications ..................................................... Fast Send to One Triconex Node ............................................................ Sending Data Every Second to One Node .............................................. Controlled Use of TR_USEND/TR_URCV Function Blocks .................... Using TR_USEND/TR_URCV Function Blocks for Safety-Critical Data . Sending Node #1 Parameters: ....................................................... Receiving Node #3 Parameters: ....................................................
72 72 72 73 73 73 73
TR_CRITICAL_IO Function Block ............................................................... 75 Instructions for Use ................................................................................. 75 Structured Text ........................................................................................ 79 TR_SHUTDOWN Function Block ................................................................ 82 Structured Text ........................................................................................ 86 TR_VOTE_MODE Function Block ............................................................... 90 Structured Text ........................................................................................ 92
Appendix B
Shutdown Function Blocks ...................................................... 95

TR_CRITICAL_IO Function Block ............................................................... 96 Instructions for Use ................................................................................. 96 Structured Text ...................................................................................... 100 TR_SHUTDOWN Function Block .............................................................. 103 Structured Text ...................................................................................... 107 TR_VOTE_MODE Function Block ............................................................. 111 Structured Text ...................................................................................... 113
Index .................................................................................................................... 115
CHAPTER 1
Safety Concepts
This chapter describes background information about safety concepts and standards. Topics include: Safety Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Hazard and Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Safety Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Application-Specific Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Safety Overview
Safety Overview
Modern industrial processes tend to be technically complex, involve substantial energies, and have the potential to inflict serious harm to persons or property during a mishap. The IEC 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 Methods that provide layers of protection should be: Independent Verifiable Dependable Designed for the specific safety risk
Safety Overview
Protection Layers
The figure below shows how layers of protection can be used to reduce unacceptable risk to an acceptable level. The amount of risk reduction for each layer is dependent on the specific nature of the safety risk and the impact of the layer on the risk. Economic analysis should be used to determine the appropriate combination of layers for mitigating safety risks.
Acceptable Risk Level
Mechanical Integrity Inherent Process Risk
SV
SIS
BPCS*
Effect of Protection Layers on Process Risk
Process 0
Lower Risk Higher Risk
* BPCSBasic process control system SISSafety-instrumented system SVSafety (relief) valve
When an SIS is required, one of the following should be determined: Level of risk reduction assigned to the SIS Safety integrity level (SIL) of the SIS Typically, a determination is made according to the requirements of the ANSI/ISA S84.01 or IEC 61508 standards during a process hazard analysis (PHA). A process demand is defined as the occurrence of a process deviation that causes an SIS to transition a process to a safe state.
Chapter 1
Safety Concepts
Safety Overview
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
A SIL can be considered a statistical representation of the availability of an SIS at the time of a process demand. A SIL is the litmus test of acceptable SIS design and includes the following factors: Device integrity Diagnostics Systematic and common cause failures Testing Operation Maintenance In modern applications, a programmable electronic system (PES) is used as the core of a SIS. The Triconex controller is a state-of-the-art PES optimized for safety-critical applications.
Hazard and Risk Analysis 5
Hazard and Risk Analysis

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

The figure below shows the relationship of DIN V 19250 classes and safety integrity levels (SILs). As a required SIL increases, SIS integrity increases as measured by: System availability (expressed as a percentage) Average probability-to-fail-on-demand (PFDavg) Risk reduction factor (RRF, reciprocal of PFDavg) The relationship between AK class and SIL is extremely important and should not be overlooked. These designations were developed in response to serious incidents that resulted in the loss of life, and are intended to serve as a foundation for the effective selection and appropriate design of safety-instrumented systems.
R i s k R e d u c t I o n
99.999 99.99 99.90 99.00 90.00
0.00001 0.0001 0.001 0.01 0.1 >10,000 10,000 1,000 1,000 100 100 10 RRF SIL 3 SIL 2 SIL 1 SIL 4 SIL 3 SIL 2 SIL 1
AK 8 AK 7 AK 6 AK 5 AK 4 AK 3 AK 2 AK 1 DIN V 19250
Standards and Risk Measures
Percent Availability
PFDavg
ANSI/ISA S84.01
IEC 61508
Risk Measures
Risk Standards
Determining a Safety Integrity Level

If a PHA concludes that an SIS is required, ANSI/ISA S84.01 and IEC 61508 require that a target SIL be assigned. The assignment of a SIL is a corporate decision based on risk management and risk tolerance philosophy. Safety regulations require that the assignment of SILs should be carefully performed and thoroughly documented.
Completion of a HAZOP determines the severity and probability of the risks associated with a process. Risk severity is based on a measure of the anticipated impact or consequences, including: On-site consequences Worker injury or death Equipment damage Off-site consequences Community exposure, including injury and death Property damage Environmental impact Emission of hazardous chemicals Contamination of air, soil, and water supplies Damage to environmentally sensitive areas A risk probability is an estimate of the likelihood that an expected event will occur. A risk probability is classified as high, medium, or low, and is often based on a 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.
Chapter 1
Safety Concepts
Example SIL Calculation

As a PES, the controller is designed to minimize its contribution to the SIL, thereby allowing greater flexibility in the SIS design.
99.9999 R i s k 99.999 99.99 99.90 99.00 90.00
0.000001 Tricon PES* 0.00001 0.0001 0.001 0.01 0.1 SIL 3 SIS
Comparison of Percent Availability and PFD
R e d u c t I o n
Percent Availability Risk Measures
PFD
* Tricon controller failure rates have been independently calculated by Factory Mutual System. A copy of Factory Mutual Technical Report, An Estimation of the Failure Rates for Modules Used in the Triconex Tricon 9 System, FMRC J.I. 003003840, is available upon request.
Safety Integrated System 3 Pressure Transmitters (2oo3) Sensors 3 Temperature Transmitters (2oo3)
Simplified Diagram of Key Elements
TMR Controller (2oo3) PES/Logic Solver
2 Block Valves in Series (1oo2) Final Elements
Equation for Calculating PFDavg for Sensors The following simplified equation may be used to calculate PFDavg for sensors (2oo3): PFDavg = (DU*TI)2 where the following variables are supplied by the manufacturer:
= failure rate
DU = dangerous, undetected failure rate TI = test interval in hours Equation for Calculating PFDavg for Block Valves The following simplified equation may be used to calculate PFDavg for block valves (1oo2) in series (final elements): PFDavg = 1/3(DU*TI)2 where the following variables are supplied by the manufacturer: = failure rate DU = dangerous, undetected failure rate TI = test interval in hours Equation for Calculating PFDavg for System The following simplified equation may be used to calculate PFDavg for a system. System PFDavg = Sensors PFDavg + Block Valves PFDavg + Controller PFDavg
Chapter 1
Safety Concepts
10
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 2.28E-06 2.28E-06 2.85E-06
TI 4380 4380
PFD 1.00E-04 1.56E-04
Result
2.56E-04 4380 3.33E-05 3.33E-05
PFDavg for System
3.09 E-04
To determine the SIL, compare the calculated PFDavg to the figure on page 8. In this example, the system is acceptable as an SIS for use in SIL3 applications.
Safety Life Cycle Model

The necessary steps for designing an SIS from conception through decommissioning are described in the safety life cycle. Before the safety life cycle model is implemented, the following requirements should be met: Hazard and operability study has been completed SIS requirement has been determined Target SIL has been determined
11
Start
Design conceptual process Perform process hazard analysis and risk assessment Apply non-SIS protection layers to prevent identified hazards or reduce risk Establish operation and maintenance procedure Develop safety requirements document Perform SIS conceptual design and verify it meets the SRS Perform SIS detail design SIS installation, commissioning, and pre-startup acceptance test Modify
Pre-start-up safety review assessment SIS start-up operation, maintenance, periodic functional testing
Flowchart of Safety Life Cycle
Exit
No
SIS required? Yes Define target SIL
Modify or decommission SIS? Decommission SIS decommissioning
Conceptual process design S84.01 Concern
Chapter 1
Safety Concepts
12
M PES Steps in a Safety Life Cycle: 1 Develop a safety requirement specification.
An SRS consists of safety functional requirements and safety integrity requirements. An SRS can be a collection of documents or information. Safety functional requirements specify the logic and actions to be performed by an SIS and the process conditions under which actions are initiated. These requirements include such items as consideration for manual shutdown, loss of energy source, etc. Safety integrity requirements specify a SIL and the performance required for executing SIS functions. Safety integrity requirements include: Required SIL for each safety function Requirements for diagnostics Requirements for maintenance and testing Reliability requirements if the spurious trips are hazardous
2 For conceptual design, an engineer should:
Define the SIS architecture to ensure the SIL is met; e.g. voting 1oo1, 1oo2, 2oo2, 2oo3 Define the logic solver to meet the highest SIL if different SIL levels are required in a single logic solver Select a functional test interval to achieve the SIL Verify the conceptual design against the SRS
3
Develop a detail design including: General requirements SIS logic solver Field devices Interfaces Energy sources System environment Application logic requirements Maintenance or testing requirements
13
Some key ANSI/ISA S84.01 requirements are: The logic solver shall be separated from the basic process control system Sensors for SIS shall be separated from the sensors for the BPCS The logic system vendor shall provide: MTTF data Covert failure listing Frequency of occurrence of identified covert failures 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 Forcing shall not be used as a part of application software or operating procedures When on-line testing is required, test facilities shall be an integral part of the SIS design
4 Develop a pre-start-up acceptance test procedure that provides a fully functional
test of the SIS to verify conformance with the SRS.

5 Before startup, establish operational and maintenance procedures to ensure that
the SIS functions comply with the SRS throughout the SIS operational life, including: Training Documentation Operating procedures Maintenance program Testing and preventive maintenance Functional testing Documentation of functional testing
6 Before start-up, complete a safety review.
Chapter 1
Safety Concepts
14
7 Define procedures for the following:
Start-up Operations Maintenance, including administrative controls and written procedures that ensure safety if a process is hazardous while an SIS function is being bypassed Training that complies with national regulations (e.g., OSHA 29 CFR 1910.119) Functional testing to detect covert faults that prevent the SIS from operating according to the SRS SIS testing, including: Sensors Logic solver Final elements (e.g., shutdown valves, motors, etc.)
8 To ensure that no unauthorized changes are made to an application program, as
mandated by OSHA 29 CFR 1910.119, follow management of change (MOC) procedures.

9 To ensure proper review, decommission an SIS before its permanent retirement
from active service.
Safety Standards
15
Safety Standards
Over the past several years, there has been rapid movement in many countries to develop standards and regulations to minimize the impact of industrial accidents on citizens. The standards described below apply to typical applications.
General Safety Standards

DIN V 19250
In Germany, the methodology of defining the risk to individuals is established in DIN V 19250, Control Technology; Fundamental Safety Aspects To Be Considered for Measurement and Control Equipment. DIN V 19250 establishes the concept that safety systems should be designed to meet designated classes, Class 1 (AK1) through Class 8 (AK8). The choice of the class is dependent on the level of risk posed by the process. DIN V 19250 attempts to force users to consider the hazards involved in their processes and to determine the integrity of the required safety-related system.
DIN V VDE 0801

As the use of programmable electronic systems in safety system designs has become prevalent, it is necessary to determine whether the design of a PES is sufficiently rigorous for the application and for the DIN V 19250 class. DIN V VDE 0801, Principles for Computers in Safety-Related Systems, sets forth the following specific measures to be used in evaluating a PES: Design Coding (system level) Implementation and integration Validation Each measure is divided into specific techniques that can be thoroughly tested and documented by independent persons. Thus, DIN V VDE 0801 provides a means of determining if a PES meets certain DIN V 19250 classes.
Chapter 1
Safety Concepts
16
Safety Standards
IEC 61508, Parts 17

The IEC 61508 standard, Functional Safety: Safety Related Systems, is an international standard designed to address a complete SIS for the process, transit, and medical industries. The standard introduces the concept of a safety life cycle model (see the flowchart on page 11) to illustrate that the integrity of an SIS is not limited to device integrity, but is also a function of design, operation, testing, and maintenance. The standard includes 4 SILs that are indexed to a specific probability-to-fail-ondemand (PFD) (see figure on page 6). A SIL assignment is based on the required risk reduction as determined by a PHA.
ANSI/ISA S84.01
ANSI/ISA 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 safetyinstrumented layer. In contrast, the process industry can integrate many layers of protection in the process design. The overall risk reduction from these layers of protection is equal to or greater than that of other industries.
Draft IEC 61511, parts 13

The IEC 61511 standard, Functional Safety: Safety Instrumented Systems for the Process Industry Sector, is an international standard designed to be used as a companion to IEC 61508. IEC 61508 is intended primarily for manufacturers and suppliers of devices. IEC 61511 is intended for SIS designers, integrators, and users in the process-control industry.
Safety Standards
17
Application-Specific Standards
DIN VDE 0116
DIN VDE 0116 Electrical Equipment Of Furnaces, outlines the German requirements for burner management applications.
EN 54, Part 3
EN 54, Part 3, Components of Automatic Fire Detection System: Control and Indicating Equipment, outlines the European requirements for fire detection systems.
NFPA 72
NFPA 72, National Fire Alarm Code, outlines the United States requirements for fire alarm systems.
NFPA 8501
NFPA 8501, Standard for Single Burner Boiler Operation, outlines the United States requirements for operations using single burner boilers.
NFPA 8502
NFPA 8502, Standard for the Prevention of Furnace Explosions/Implosions in Multiple Burner Boilers, outlines the United States requirements for operations using multiple burner boilers.
CSA C22.2 NO 199

CSA C22.2 NO 199, Combustion Safety Controls and Solid-State Igniters for Gas and Oil-Burning Equipment, outlines the Canadian requirements for burner management applications.
Chapter 1
Safety Concepts
18
Safety Standards
CHAPTER 2
Application Guidelines
This chapter provides information on industry guidelines. Topics include: TV Rheinland Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Guidelines for Tricon Controllers . . . . . . . . . . . . . . . . . . . . . . . . . 23
20
TV Rheinland Certification
TV Rheinland Certification
When used as a PES in an SIS, the Tricon 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. If these standards apply to your application, compliance with the guidelines described in this chapter is highly recommended.
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
All Safety Systems

The following general guidelines apply to all user-written safety application programs and procedures: Functional testing is recommended to verify the correct design and operation. After a safety system is commissioned, no changes to the system software (operating system, I/O drivers, diagnostics, etc.) are allowed without type approval and re-commissioning. Any changes to the application or the control program should be made under strict change-control procedures. For more information on change-control procedures, see section Project Change and Control on page 30. All changes should be thoroughly reviewed, audited, and approved by a safety change control committee or group. After an approved change is made, it should be archived. In addition to printed documentation of the application program, two copies of the program should be archived on an electronic medium which is writeprotected to avoid accidental changes.
General Guidelines
21
Under certain conditions, a PES may be run in a mode which allows an external computer or operator station to write to system attributes. This is normally done by means of a communication link. The following guidelines apply to writes of this type: Serial communication should use Modbus or another approved protocol with CRC checks. Serial communication should not be allowed to write directly to output points. For information about writes to safety-related variables that result in disabling safety action, see section Module Diagnostics on page 43. PID and other control algorithms should not be used for safety-related functions. Each control function should be checked to verify that it does not provide a safety-related function. An SIS PES should be wired and grounded according to the procedures defined by the manufacturer.
Emergency Shutdown Systems

The safe state of the plant should be a de-energized or low (0) state. For ESD functions, it is recommended that the hardware devices connected to PES outputs should be made of fail-safe components or should have two separate, independent shutdown paths which are periodically inspected.
Burner Management Systems

The safe state of the plant should be a de-energized or low (0) state. When a safety system is required to conform with the DIN 0116 standard for electrical equipment in furnaces, PES throughput time should ensure that a safe shutdown can be performed within one second after a problem in the process is detected.
Chapter 2
22
General Guidelines
Fire and Gas Systems

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

The following topics relate to industry guidelines that are specific to Tricon controllers when used as a PES in an SIS: Safety-critical modules Safe shutdown Programming lockout alarm Remote access alarm Scan time and response time alarm Disabled points alarm Disabled output voters Download all Use of Peer-to-Peer functions Modbus master functions SIL3/AK5 guidelines SIL3/AK5 fire and gas guidelines SIL3/AK6 guidelines SIL3/AK6 fire and gas guidelines Project change and control
Chapter 2
24
Safety-Critical Modules
It is recommended that only the following modules be used for safety-critical applications: Main Processor Modules, all models Communication Modules, all models Digital Input Modules, all models Digital Output Modules, all models Analog Input Modules, all models Analog Output Module, Model #3805 only Pulse Totalizer Input Module The Relay Output Module is recommended for non-safety-critical points only.
Safety-Shutdown
A safety application should include a network that initiates a safe shutdown of the process being controlled when a controller operates in a degraded mode for a specified maximum time. The Triconex Library provides two function blocks to simplify programming a safety-shutdown application: TR_SHUTDOWN and TR_CRITICAL_IO. To see the Structured Text code for these function blocks, see Appendix A, Peer-to-Peer Communication. For more information on safety-shutdown networks, see section Sample Safety-Shutdown Programs on page 55.
Response Time and Scan Time

Scan time must be set below 50% of the required response time. If scan time is greater than 50%, an alarm should be available.
Disabled Points Alarm

A project should not contain disabled points unless there is a specific reason for disabling them, such as initial testing. An alarm should be available to alert the operator that a point is disabled.
25
Disabled Output Voter Diagnostic

A safety application may not disable the output voter diagnostic.
Download All at Completion of Project

When development and testing of a safety application is completed, use the Download All command on the Control Panel to completely re-load the application to the controller.
Modbus Master Functions

Modbus Master functions are designed for use with non-critical I/O points only. These functions should not be used for safety-critical I/O points or for transferring safety-critical data using the MBREAD and MBWRITE functions.
Peer-to-Peer Communication
Peer-to-Peer communication enables Triconex controllers (also referred to as nodes) to send and receive information. If a node sends critical data to another node that makes safety-related decisions, you must ensure that the application on the receiving node can determine whether it has received new data. If new data is not received within the time-out period (equal to half of the 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 depends on the unique safety requirements of your particular process. The sections that follow summarize the main types of actions entailed in the use of Peer-to-Peer send and receive functions.
Sending Node
The actions required in the logic of the sending application are:
Chapter 2
26
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 TR_USEND function block 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 TR_USEND functions in an application must be less than or equal to five because the controller only initiates five TR_USEND functions per scan. To send data as fast as possible, the TR_USEND 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 TR_URCV and TR_PORT_STATUS functions to determine whether there is a network problem that requires operator intervention.
Receiving Node
The types of actions 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. 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.
27
For information on data transfer time and examples of how to use Peer-to-Peer functions to transfer safety-critical data, see Appendix A, Peer-to-Peer Communication.
SIL3/AK5 Guidelines
For SIL3/AK5 applications, the following guidelines should be followed: If non-approved modules are used, the inputs and outputs should be checked to verify that they do not affect safety-critical functions of the controller. Two modes control write operations from external hosts: Remote ModeWhen the keyswitch setting is REMOTE, external hosts, such as Modbus master, DCS, etc., 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 programs currently running. (For example, Download All, Download Change, declaring variables, enabling/disabling variables, changing values of variables and scan time, etc.) Remote mode and program mode are independent of each other. In safety applications, operation in these modes is not recommended. In other words, write operations to the controller from external hosts should be prohibited. If remote mode or program mode becomes true, the application program should include the following safeguards: When remote mode is true: A program should turn on an alarm. For example, if using the TR_SHUTDOWN function block, the ALARM_REMOTE_ACCESS output could be used. Aliased variables should be checked for adherence to the guidelines described in section Maintenance Overrides on page 32. When program mode is true: A program 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 Tricon Planning & Installation Guide should be followed.
Chapter 2
28
Maintenance instructions outlined in the Tricon Planning & Installation Guide should be followed. If degradation to dual mode occurs, continued operation without repair should be limited to 1500 hours (two months). If degradation to single mode occurs, continued operation without repair should be limited to 72 hours (three days). The GATENB function allows external hosts to write selected aliased variables even when the remote mode is false. A network using the GATENB function should be thoroughly validated to ensure that only the intended aliased variable range is used. Remote Peer-to-Peer connections must be programmed according to the recommendations in the section Peer-to-Peer Communication on page 25.
Additional Fire and Gas Guidelines

Analog input cards with current loop terminations should be used to read digital inputs. Opens and shorts in the wiring to the field devices should be detectable. The Triconex library function, LINEMNTR, should be used to simplify program development. A controller should be powered by two independent sources. If outputs are normally de-energized, a Supervised Digital Output Module should be used to verify proper connection to the final control element and to check the load and the wiring for potential shorts. If degradation to dual mode or single mode occurs, repairs should be timely and limits for maximum time in degraded mode should not be imposed to ensure maximum availability.
29
SIL3/AK6 Guidelines
For SIL3/ AK6 applications, the following guidelines should be followed: DIN V VDE 19250/AK6 applications that require continued operation after detecting an output failure must have a secondary means of operating the output. A secondary means may be an external group relay or a single point on an independent output module that controls a group of outputs. If a relay is used, it should be checked at least every six months, manually or automatically. If non-approved modules are used, the inputs and outputs should be checked to verify that they do not affect safety-critical functions of the controller. Two modes control write operations from external hosts: Remote ModeWhen the keyswitch setting is REMOTE, external hosts, such as Modbus master, DCS, etc., can write aliased data 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 programs currently running. (For example, Download All, Download Change, declaring variables, enabling/disabling variables, changing values of variables and scan time, etc.) Remote mode and program mode are independent of each other. In safety application, 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: A program should turn on an alarm. For example, if using the TR_SHUTDOWN function block, the ALARM_REMOTE_ACCESS output could be used. Aliased variables should be checked for adherence to the guidelines described in section Maintenance Overrides on page 32. When program mode is true: A program 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 Tricon Planning & Installation Guide should be followed.
Chapter 2
30
Maintenance instructions outlined in the Tricon Planning & Installation Guide should be followed. If degradation to dual mode occurs, continued operation without repair should be limited to 1500 hours (two months). If degradation to single mode occurs, continued operation without repair should be limited to one hour. The GATENB function allows external hosts to write selected aliased variables even when the remote mode is false. A network using the GATENB function should be thoroughly validated to ensure that only the intended aliased variable range is used.
Additional Fire and Gas Guidelines

Analog input cards with current loop terminations should be used to read digital inputs. Opens and shorts in the wiring to the field devices should be detectable. The Triconex library function, LINEMNTR, should be used to simplify program development. A controller should be powered by two independent sources. If outputs are normally de-energized, a Supervised Digital Output Module should be used to verify proper connection to the final control element and to check the load and the wiring for potential shorts. If degradation to dual mode or single mode occurs, repairs should be timely and limits for maximum time in degraded mode should not be imposed to ensure maximum availability.
Project Change and Control

A change to a project, however minor, should comply with the guidelines of your organizations change control committee. The following steps are recommended:
1 Generate a change request defining all changes and reasons for changes, then
obtain approval for the changes from the Safety Change Control Committee (SCCC).
2 Develop a specification for changes, including a test specification, then obtain
approval for the specification from the SCCC.

3 Make the appropriate changes to the project, including those related to design,
operation, or maintenance documentation.
31
4 To verify that the configuration in the controller matches the last downloaded
configuration, use the Upload and Verify command on the Control Panel. For details, see section Upload and Verify in the TriStation 1131 Developer's Guide for Tricon Systems.
5 Compare the configuration in your project with the configuration that was last
downloaded to the controller by printing the Configuration Differences report from the Configuration editor. For details, see section Compare to Last Download in the TriStation 1131 Developer's Guide for Tricon Systems.
6 Print all logic elements and verify that the changes to networks within each
element do not affect other sections of the application.

7 Test the changes according to the test specification by using the Emulator
Control Panel.
8 Write a test report. 9 Review and audit all changes and test results with the SCCC. 10 When approved by the SCCC, download the changes to the controller.
You may make minor changes on-line only if the changes are absolutely necessary and are tested thoroughly. To enable a Download Change command, select the Enable Programming option in the Set Programming Mode dialog box on the Control Panel if it is not already selected. Note Changing the operating mode to PROGRAM should generate an alarm to remind the operator to return the operating mode to run as soon as possible after the Download Change. For more information, see section Programming Permitted Alarm on page 68.
11 Save the downloaded project in TriStation and back up the project. 12 Archive two copies of the project file and all associated documentation.
Chapter 2
32
Maintenance Overrides
Three methods can be used to check safety-critical devices connected to controllers: Special switches are connected to inputs to a controller that deactivate the actuators and sensors undergoing maintenance. The maintenance condition is handled in the logic of the control program. Sensors and actuators are electrically disconnected from a controller and manually checked using special measures. Serial communication to a controller activates the maintenance override condition. This method is useful when space is limited and the maintenance console should be integrated with the operator display.
Using Serial Communication

For maintenance overrides, two options for serial connection are available: DCS connection using Modbus RTU protocol (or another approved serial protocol) TriStation PC connection, which requires additional, industry-standard safety measures in a controller to prevent downloading a program change during maintenance intervals. For more information on TriStation, see section Alarm Usage on page 68.
33
Design Requirements The following table describes design requirements for handling maintenance overrides when using serial communication.
Responsible Person Design Requirements DCS Control program logic and the controller configuration determine whether the desired signal can be overridden. Control program logic and/or system configuration specify whether simultaneous overriding in independent parts of the application is acceptable. Controller activates the override. The operator should confirm the override condition. Direct overrides on inputs and outputs are not allowed, but should be checked and implemented in relation to the application. Multiple overrides in a controller are allowed as long as only one override applies to each safetycritical group. The controller alarm should not be overridden. DCS warns the operator about an override condition. The operator continues to receive warnings until the override is removed. A second way to remove the maintenance override condition should be available If urgent, a maintenance engineer may remove the override using a hard-wired switch. Project Engineer, Commissioner TriStation Project Engineer, Commissioner
Project Engineer
Project Engineer, Type Approval
Operator, Maintenance Engineer Project Engineer
Maintenance Engineer, Type Approval Project Engineer, Type Approval
Project Engineer, Commissioner
N/A
Project Engineer
Maintenance Engineer, Type Approval
Chapter 2
34
Responsible Person Design Requirements DCS During an override, proper operating measures should be implemented. The time span for overriding should be limited to one shift (typically no longer than 8 hours). A maintenance override switch (MOS) light on the operator console should be provided (one per a controller or process unit). Project Engineer, Commissioner, DCS, TriStation TriStation
Operating Requirements The following table describes operating requirements for handling maintenance overrides when using serial communication.
Responsible Person Operating Requirements DCS Maintenance overrides are enabled for an entire controller or for a subsystem (process unit). Controller activates an override. The operator should confirm the override condition. Controller removes an override. Operator, Maintenance Engineer Operator, Maintenance Engineer Operator, Maintenance Engineer TriStation Maintenance Engineer, Type Approval Maintenance Engineer, Type Approval Maintenance Engineer
35
Additional Recommendations
The following procedures are recommended in addition to the recommendations described in the tables on page 33 and page 34: 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. The following diagram depicts this procedure:
Safety-Instrumented System
Controller Sensors Safeguarding Application Program Actuators
PES Block Diagram
HardWired Switch
Maintenance Override Handling (Application Program)
Operator Warning
Distributed Control System Inputs
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 work-permit or maintenance log. Tag Name of the signal being overridden. Communication packages that are different from a type-approved Modbus should include CRC, address check, and check of the communication time frame. Loss of communication should lead to a warning to the operator and maintenance engineer. After loss of communication, a time-delayed removal of the override should occur after a warning to the operator.
Chapter 2
36
CHAPTER 3
Fault Management
This chapter discusses system architecture and diagnostics, types of faults, operating modes, and module diagnostics. Topics include: System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 System Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Types of Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Operating Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Module Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
38
System Architecture
System Architecture
The controller has been designed from its inception with self-diagnostics as a primary feature. Triple-Modular Redundant (TMR) architecture (shown below) 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. 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.
Auto Spare Input Channel A I/O Bus TriBus Main Processor B TriBus Input Channel C I/O Bus Auto Spare Output Channel A TriBus I/O Bus Main Processor C
Main Processor A
Typical Tricon System

Input Termination
Input Channel B
Output Channel B
Voter Output Termination
Output Channel C
System Diagnostics
39
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 diagnosticscomparing an operating value to a predetermined reference, such as a system specification Comparison diagnosticscomparing one component to another, such as one independent channel with two other independent channels Field device diagnosticsdiagnostics are extended to a systems field devices and wiring
Chapter 3
Fault Management
40
Types of Faults
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 Diagnostic Panel in TriStation System attributes on the Control 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 alarms. 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 Diagnostic Panel in TriStation identifies the faulting module by displaying a red frame around it. For instructions on responding to specific alarm conditions, see the Tricon Planning and Installation Guide.
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 of on operating modes, see Operating Modes on page 41. 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
41
Operating Modes
Each input or output point is considered to operate in Triple Modular Redundant, dual, or single 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. System variables summarize the status of input and output points. For safety reasons, system mode is defined as the mode of the point controlled by the fewest number of channels. 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. A user can further simplify and customize shutdown logic using special function blocks provided by Triconex. By considering only faults in safety-critical modules, system availability can be improved. For more information, see Appendix A, Peer-to-Peer Communication. While operating in TMR mode, the process is protected each scan 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-on-demand. To keep the PFD within industry-acceptable guidelines, adherence with the recommended maximum operating period of 1500 hours in dual mode and 72 hours (SIL3/AK5) or 1 hour (SIL3/AK6) in single mode should be observed. A safety-critical fault is defined as a fault that can affect the ability of the system to correctly control outputs, including: 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
Chapter 3
Fault Management
42
Operating Modes
Also, during each execution of the control program, each channel independently verifies the: Integrity of the data path between the MPs Proper voting of all input values Proper evaluation of the control program Calculated value of each output point
Module Diagnostics
43
Module Diagnostics
Each system component detects and reports operational faults.
Digital Input Modules

Digital Input Module points typically use a combination of comparison and forceto-value diagnostics (FVD). Under system control, each channel is independently compared against the measured value of all channels. If a mismatch is found, an alarm is set. Using the integral FVD capability, each point can be independently verified for its ability to accurately detect a transition to the opposite state. A channel that has detected a fault on a digital input point votes that point to be deenergized. These diagnostics are executed independently by each channel, thus assuring nearly 100% fault coverage and fail-safe operation under all single-fault, and most common, multiple-fault scenarios.
Digital Input Module Alarms

Digital Input Module faults are reported to the control program, and these alarms can be used to increase availability during specific multiple fault conditions. Loss of logic power is reported to the control program.
Digital Output Modules

Digital Output Modules use output voter diagnostics (OVD). Under system control, each output point is commanded sequentially to both the energized and deenergized states and the forced state is maintained until the value is detected by the system or a time-out occurs (500 microseconds, typical; 2 milliseconds, worst case). Using the integral OVD capability, each point can be independently verified for its ability to a transition to either state. The OVD is executed in TMR mode, thus assuring nearly 100% fault coverage and fail-safe operation under all singlefault scenarios.
Digital Output Module Alarms

Digital Output Module faults are reported to the control program and can be used to increase availability during specific multiple fault conditions. Loss of field power or logic power is reported to the control program. The inability of a Digital Output Module to control an output point is reported to the control program as a Load/Fuse alarm. This condition can result from a loss of
Chapter 3
Fault Management
44
Module Diagnostics
field power or a field short condition. The alarm can be used to modify the control strategy or direct effective maintenance action.
Analog Input Modules

Analog Input Module points use a combination of comparison and reference diagnostics. Under system control, each channel is independently compared against the measured value of all channels. If a mismatch if found, an alarm is set. Each channels measured values are also 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 near 100% fault coverage and fail-safe operation under all single-fault, and most common, multiple-fault scenarios.
Analog Input Module Alarms

Analog Input Module faults are reported to the control program. These alarms can be used to increase availability during specific multiple fault conditions. Loss of logic power is reported to the control program.
Analog Output Modules

Analog Output Modules use a combination of comparison and reference diagnostics. Under system control, each channel is given control of the output sequentially using the 2oo3 voting mechanism. Each channel independently measures the actual state of an output value by comparing it with the commanded value. If the values do not match, a channel switch is forced by voting another channel. Each channel also compares its measured values against internal references. Using these diagnostics, each channel can be independently verified for its ability to control the analog output value, thus assuring nearly 100% fault coverage and fail-safe operation under all single-fault, and most common, multiple-fault scenarios.
Analog Output Module Field Alarms

Analog Output Module faults are reported to the control program. These alarms can be used to increase availability during specific multiple-fault conditions. Loss of field power or logic power is reported to the control program.
Module Diagnostics
45
Relay Output Modules

Relay Output Module points are not intended for safety-critical applications. The diagnostics used by the relay output points cannot detect faults in the relay contacts.
Relay Output Module Alarms

Detectable Relay Output Module faults are reported to the control program.
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 50 milliseconds, 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.
I/O Module Alarms

Loss of communication with an I/O module is reported to the control program and can be used to increase availability during specific multiple-fault conditions.
Chapter 3
Fault Management
46
Module Diagnostics
Main Processor and TriBus

Each Main Processor (MP) Module uses memory data comparison between itself and the other MPs to ensure that the control program executes correctly on each scan. Each MP transfers its input point data to the other two MPs via the TriBus during each scan. Each MP then votes the input data and provides voted data to the control program. The results of the control program (outputs), including all internal variables, are transferred by the TriBus. If a mis-compare is detected, special algorithms are used to isolate the faulting MP. The faulting MP enters the fail-safe state and is ignored by the remaining MPs. Background diagnostics test MP memory and compare control program instructions and internal status. The integrity of the TriBus is continuously monitored and verified independently by each MP. All TriBus faults are detected within the scan associated with the TriBus transfer. Fault isolation hardware and firmware causes the MP with the faulting TriBus to enter the fail-safe state. An independent watchdog ensures that the control program and diagnostics execute within 500 milliseconds seconds (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 failsafe state.
External Communication
Loss of external communication is not indicated by a system alarm. However, alarms can be generated by using: Semaphore flags System attributes
!
CAUTION
External communications are intended for transporting non-safety-critical data. The guidelines outlined in section Using Serial Communication on page 32 should be followed in SIS applications.
Semaphore Flags
Establish a semaphore between a controller and an external device by using a timer function block to evaluate the changing state of semaphore flags.
Module Diagnostics
47
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 TriStation 1131 Developers Guide for Tricon Systems. See also the following relevant manuals: Advanced Communication Module User's Guide Enhanced Intelligent Communication Modules User's Manual Hiway Interface Module User's Guide Network Communication Module User's Guide Safety Manager Module User's Guide Tricon DDE Server User's Guide Tricon System Access Application Programmer's Reference Tricon System Aliases Reference Manual Tricon Planning & Installation Guide TriStation 1131 Triconex Libraries
Chapter 3
Fault Management
48
Module Diagnostics
CHAPTER 4
Application Development
This chapter discusses methods for developing applications to avoid application faults. Topics include: Development Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Important TriStation Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Setting Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Sample Safety-Shutdown Programs . . . . . . . . . . . . . . . . . . . . . . . 55 Alarm Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
50
Development Guidelines
Development Guidelines
While developing an application, you should: Use a dedicated PC that is not connected to a network. Use a good virus checker. Verify proper installation of TriStation 1131 using TriStation Install Check.
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. For more information on the TriStation Install Check program, see the TriStation 1131 Developer's Guide.
Important TriStation Commands
51

Several commands in TriStation 1131 Developers Workbench are of special interest when developing a safety application: Download Change Upload and Verify Compare to Last Download
Download Change
The Download Change command is a convenient means of making simple modifications to an off-line system during application development.
! WARNING
Download Change is intended for off-line use during application development. If you use Download Change to modify a safety-critical application that is running on-line, 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 on-line changes to a controller, you should always follow the guidelines provided in TriStation 1131 Developer's Guide and fully understand the risks you are taking by using the Download Change command. Before a Download Change, use the Diagnostic Panel to verify that Scan Surplus is sufficient for the application and changes being made. As a rule, the value for Scan Surplus should be at least 10% of Scan Time to accommodate newly added elements. For more information on scan time, see Setting Scan Time on page 53.
!
CAUTION
Do not attempt a Download Change if you have a negative Scan Surplus. First, adjust Scan Time to make the surplus value greater than or equal to zero. For more information on the Download Change command, see the TriStation 1131 Developer's Guide.
Chapter 4
52
Upload and Verify

Before you make changes to a project in TriStation, you should run the Upload and Verify command to verify that the project in TriStation matches the project running in the controller. (The Upload and Verify command is on the Commands menu on the Control Panel in TriStation.) This command compares the current project running in the controller to a record of the last downloaded project. To use the Upload and Verify command, you must be able to connect your application to the controller using the Connect command on the Control panel in TriStation. For more information on the Upload and Verify command, see the TriStation 1131 Developer's Guide.
Compare to Last Download

After you have run the Upload and Verify command, make the desired changes to the project. Use the Compare to Last Download command to verify that the changes to the project are only the intended changes. (The Compare to Last Download command is on the Commands menu of the Configuration editor in TriStation.) To test the changes, use the Emulator Control Panel in TriStation.
Setting Scan Time 53
Setting Scan Time

Setting appropriate scan time for the project is essential to avoid improper controller behavior. When changing a project running in an on-line system, special precautions should be exercised to avoid scan time overruns, which could result in unexpected controller behavior.
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 Configuration editor to suggest the desired scan time before downloading an application. Upon downloading, the controller determines the minimum and maximum allowable scan times for your application and uses your suggested scan time if it falls within the acceptable limits. The default scan time is 200 milliseconds. The maximum allowable scan time is 500 milliseconds and the minimum allowable scan time is 25 milliseconds. Requested Scan Time is a system parameter that is set using the Configuration editor. 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.
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 Control Panel to set the surplus value to greater than or equal to zero. The Scan Time parameter in the TriStation Configuration editor applies only when you do a Download All.
Chapter 4
54
Setting Scan Time
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.
SCAN_STATUS
TR_SCAN_STATUS
1 C1
CO POWERUP FIRSTSCAN SCANREQUEST SCANSURPLUS SCANDELTA DELTAT SCANOVERRUN KEYSWITCH
001
SCAN_SURPLUS
SCAN_OVERRUNS
For more information, see the TriStation 1131 Developer's Guide and the Triconex Libraries Manual.
Sample Safety-Shutdown Programs
55

The following section describes sample programs and methods for implementing safety-shutdown networks.
All I/O Modules Safety-Critical

The sample program, PROGRAM EX01_SHUTDOWN, shows one way to verify that the safety system is operating properly when every module in the safety system is safety-critical. The example uses an instance of the Triconex Library function block TR_SHUTDOWN named CRITICAL_MODULES. (The sample program is an element of project ExTUV.pt2 found on the TriStation CD. The default location of the project is C:\Program Files\Triconex\TS1131\_Tricon\Examples.) 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 1500 hours (two months). Continued operation in single mode is restricted to 72 hours for SIL/AK5 and one hour for SIL/AK6 guidelines. 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 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 application-specific action. For information on improving availability using external, power-disconnect relays and advanced programming techniques, see the sample program called EX02_SHUTDOWN.
Chapter 4
56
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 T#3d T#400ms MAX_TIME_DUAL MAX_TIME_SINGLE MAX_SCAN_TIME CO OPERATIING TMR DUAL SINGL ZERO TIMER_RUNNING TIME_LEFT ALARM_PROGRAMMING_PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS ERROR
001
CRITICAL_MODULES_OPERATING
ALARM_PROGRAMMING_PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS
CO false indicates a programming error; for example, MAX_TIME_SINGLE greater than MAX_TIME_DUAL. The error number shows more detail.
57
Input Parameters The table below describes the input parameters for the TR_SHUTDOWN function block.
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 Description Do not connect when all I/O modules are system-critical Do not connect when all I/O modules are system-critical Do not connect when all I/O modules are system-critical Do not connect when all I/O modules are system-critical Do not connect when all I/O modules are system-critical Do not connect when all I/O modules are system-critical Do not connect when all I/O modules are system-critical Maximum time with only two channels operating Maximum time with only one channel operating 50% of the maximum response time
Chapter 4
58
Output Parameters The table below describes the output parameters for the TR_SHUTDOWN function block.
Parameter CO OPERATING Description Control out When OPERATING is true, all safety-critical modules are operating properly When OPERATING is false, the time in degraded operation exceeds the specified limits; therefore, the control program should shut down the process 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
59
Alarm Output Operation The table below describes how the alarm output parameters operate.
Parameter ALARM_PROGRAMMING_PERMITTED Description To remind the operator to lock out programming changes after a download change, or for applications in which download changes are not allowed, connect the ALARM_PROGRAMMING_PERMITTED Output to an alarm For applications in which remote changes are not allowed, connect the ALARM_REMOTE_ACCESS Output to an alarm Total response time depends primarily on the actual scan time. To meet the required response time of the process, set the MAX_SCAN_TIME Input to less than 50% of the required response time. When the actual scan time exceeds the MAX_SCAN_TIME value, the ALARM_RESPONSE_TIME output becomes true A project should not contain disabled points unless there is a specific reason for disabling them, such as initial testing or maintenance. To remind an operator that some points are disabled, connect the ALARM_DISABLED_POINTS output to an alarm
ALARM_REMOTE_ACCESS
ALARM_RESPONSE_TIME
ALARM_DISABLED_POINTS
Chapter 4
60
Some I/O Modules Safety-Critical

For some applications, not all modules may be critical to a process. For example, an output module that interfaces to the status indicators on a local panel is usually not critical to a process. The EX02_SHUTDOWN sample program shows how to increase system availability by detecting the status of safety-critical modules.The user-defined function block CRITICAL_IO checks the safety-critical I/O modules. The CRITICAL_IO Outputs are connected to the inputs of the CRITICAL_MODULES function block. (The sample program is an element of project ExTUV.pt2 found on the TriStation CD. The default location of the project is C:\Program Files\Triconex\TS1131\_Tricon\Examples.) 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 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 1500 hours (two months). Continued operation in single mode is restricted to 72 hours for SIL/AK5 and one hour for SIL/AK6 guidelines. 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 application-specific action.
61
CRITICAL_MODULES CRITICAL_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 OPERATIING TMR DUAL SINGL ZERO TIMER_RUNNING TIME_LEFT ALARM_PROGRAMMING_PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS ERROR
002
EX02_CRITICAL_IO
CI RELAY1_OK CO TMR GE_DUAL GE_SINGLE NO_VOTER_FLTS
001
CRITICAL_MODULES_OPERATING
ERROR
T#1500h T#3d T#400ms
Chapter 4
62
Input Parameters The table below describes the input parameters for the TR_SHUTDOWN function block.
Parameter CI Description Control in If CI is false, then CO is falseno change in the output value If CI is true and ERROR_NUM is 0, then CO is true 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 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
63
Output Parameters The table below describes the output parameters for the TR_SHUTDOWN function block.
Parameter CO OPERATING Description Control out When OPERATING is true, all safety-critical modules are operating properly When OPERATING is false, the time in degraded operation exceeds the specified limits; therefore, the control program should shut down the process 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
Chapter 4
64
Alarm Output Operation The table below describes how the alarm output parameters operate.
Parameter ALARM_PROGRAMMING_PERMITTED Description To remind the operator to lock out programming changes after a download change, or for applications in which download changes are not allowed, connect the ALARM_PROGRAMMING_PERMITTED output to an alarm For applications in which remote changes are not allowed, connect the ALARM_REMOTE_ACCESS output to an alarm Total response time depends primarily on the actual scan time. To meet the required response time of the process, set the MAX_SCAN_TIME input to less than 50% of the required response time. When the actual scan time exceeds the MAX_SCAN_TIME value, the ALARM_RESPONSE_TIME output becomes true A project should not contain disabled points unless there is a specific reason for disabling them, such as initial testing or maintenance. To remind an operator that some points are disabled, connect the ALARM_DISABLED_POINTS output to an alarm
ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME
ALARM_DISABLED_POINTS
65
Defining Function Blocks

M To create a user-defined function block for a safety-critical module: 1 Copy the example EX02_CRITICAL_IO in the ExTUV.pt2 sample project
provided with the TriStation 1131 Developers Workbench.

2 Edit the lines following the comment Include all safety-critical I/O modules
here. Each line calls the safety-critical I/O (SCIO) function block for one safetycritical I/O module. Example
**************************************************************) (* Include here all safety-critical I/O modules: *) SCIO( CHASSIS:=1,SLOT:=1,APP:=DE_ENERGIZED,RELAY_OK:=FALSE ): SCIO( CHASSIS:=1,SLOT:=2,APP:=RELAY, RELAY_OK:=RELAY1_OK ); SCIO( CHASSIS:=1,SLOT:=3,APP:=RELAY, RELAY_OK:=RELAY1_OK ); (* ( CHASSIS:=1,SLOT:=4,NOT CRITICAL) *) ( (*DI*) (*DO*) (*DO*) (*RO*)
3 (Enter the correct CHASSIS number, SLOT number, APP (application), and
RELAY_OK parameters for the safety-critical I/O module.

Application Type (App) RELAY (de-energized to trip with relay) 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 deenergize the output.
RELAY (de-energized to trip with relay) DE-ENERGIZED (de-energized to trip with no relay)
False A voter fault degrades the mode to single. A non-voter fault degrades the mode to dual.
Chapter 4
66
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
M To partition processes: 1 Partition the safety-critical I/O modules into three function blocks:
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.
2 Connect the function blocks as shown in the EX03_SHUTDOWN example on
page 67.
!
CAUTION
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 application-specific action.
67
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 OPERATIING TMR DUAL SINGL ZERO TIMER_RUNNING TIME_LEFT ALARM_PROGRAMMING_PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS ERROR
002
EX03_SHARED_IO
001
ERROR
T#1500h T#3d T#400ms
PROCESS_1 PROCESS_1_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 OPERATIING
005
EX03_PROCESS_1_IO
003
AND
PROCESS_1_ OPERATING
TMR DUAL SINGL ZERO TIMER_RUNNING TIME_LEFT ALARM_PROGRAMMING_PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS ERROR
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 safetycritical modules that affect process 1.
004
PROCESS_2 PROCESS_2_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 CO OPERATIING
006
EX03_PROCESS_2_IO
005
AND
PROCESS_2_ OPERATING
TMR DUAL SINGL ZERO TIMER_RUNNING TIME_LEFT ALARM_PROGRAMMING_PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS ERROR
ERROR
T#1500h
If PROCESS_2_OPERATING = FALSE, shut down process 2 because the time in degraded mode exceeds the specified limit for safetycritical modules that affect process 2.
T#3d MAX_SCAN_TIME T#400ms
006
Chapter 4
68
Alarm Usage
Alarm Usage
To implement the guidelines, the alarms described below are provided with TriStation 1131 Developers Workbench.
Programming Permitted Alarm

To remind the operator to lock out programming changes after a download change, or for applications in which download changes are prohibited, connect the ALARM_KEYINPROGRAM output to an alarm.
Remote Access Alarm

In applications for which remote changes are not allowed, connect the ALARM_KEYINREMOTE output to an alarm.
Response Time and Scan Time

Response time refers to the maximum time allocated for the controller to detect a change on an input point and to change the state of an output point. Response time is primarily determined by scan time (the rate at which the program is run), but is also affected by process time (how fast the process can react to a change). The response time of the controller must be equal to or faster than the process time. The scan time must be at least two times faster than the response time. To meet the required response time of the process, set the MAX_SCAN_TIME input to less than 50% of the required response time. When the actual scan time as measured by the firmware exceeds the MAX_SCAN_TIME value, the ALARM_RESPONSE_TIME output becomes true.
Disabled Points Alarm

A project should not contain disabled points unless there is a specific reason for disabling them, such as initial testing. An alarm is available to alert the operation that a point is disabled.
APPENDIX A
This appendix provides information about data transfer time, and examples of Peer-to-Peer applications. Topics include: Data Transfer Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Examples of Peer-to-Peer Applications . . . . . . . . . . . . . . . . . . . . . 72
70
Data Transfer Time
Data Transfer Time

The Peer-to-Peer function blocks require multiple scans to transfer data from the sending node to the receiving node. The time it takes to transfer data depends on the following parameters of the sending and receiving nodes: Scan time Configuration size Amount of aliased data Number of TR_USEND function blocks, TR_URCV function blocks, print function blocks, and Modbus master function blocks Number of nodes on the peer-to-peer network To estimate the data transfer time, first calculate the number of bytes for aliased variables according to the instructions that follow.
M To calculate the number of bytes for aliased variables: 1 On the Tricon menu, select Edit Configuration. This will display the
configuration tree.
2 Click Memory Allocation under Tricon System Configuration on the
configuration tree. This will display the Memory Allocation dialog box to the right of the configuration tree. The display gives the allocation for Unaliased, Read Aliased, and Read/Write Aliased Memory points, and if you scroll down you can see the allocation for Input points and Output points. For each data type (BOOLs, DINTs, and REALs), you can see the Maximum, Allocated, Forecast, and Current number of variables. The number you need is Allocated.
3 Total the number of allocated Aliased BOOLs, DINTs and REALs. 4 The number of bytes for aliased variables is 376 + BOOLs/8 + DINTs*4 +
REALs*4. 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)
Data Transfer Time 71
Parameter TS =
Description Time for sending node to transfer Aliased data over the communication bus in milliseconds = (Number of aliased variables in bytes 20000) * 1000 Scan time of sending node in milliseconds Time for receiving node to transfer Aliased data over the communication bus in milliseconds = (Number of aliased variables in bytes 20000) * 1000
SS = TR =
SR =
Scan time of receiving node in milliseconds
As a general rule, the data transfer time is 1 second to 2 seconds. So when you use Peer-to-Peer function blocks to transfer safety-critical data, you must set the maximum time-out limit to at least 2 seconds. This means that the processtolerance time of the receiving node must be greater than 4 seconds. See Using TR_USEND/TR_URCV Function Blocks for Safety-Critical Data on page 73 for an example that shows how to measure the maximum data transfer time and use TR_USEND/TR_URCV function blocks to transfer-safety critical data. You should measure the actual maximum time it takes to transfer data while testing your system to ensure the validity of your calculations and the general rules given here. As the table shows, it takes from 2 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 safety-critical decisions must include logic to check that new data is received within the specified time period. If the data is not received within the specified process-tolerance time, then the application must take appropriate actions depending on requirements. Refer to Using TR_USEND/TR_URCV Function Blocks for Safety-Critical Data on page 73 for an example that shows how to use TR_USEND and TR_URCV function blocks for transferring safety critical data.
Appendix A
72
Examples of Peer-to-Peer Applications

Peer-to-Peer function blocks are designed to transfer limited amounts of data between two applications. Therefore you should use these function blocks sparingly in your applications. Ideally, you should control the execution of each TR_USEND function block in such a way that each TR_USEND is initiated only when the acknowledgment for the last TR_USEND is received and new data is available for sending. You can do this through effective use of the SENDFLG parameter in the TR_USEND function block and the STATUS output of the TR_USEND function block, as shown in Examples 2 and 3. The examples described below can be found in the Expeer.pt2 project on the TriStation CD.
Fast Send to One Triconex Node

This is a simple example of sending data as fast as possible from Node #2 to Node #3. Scan time in both controllers is set to 100 milliseconds. The example uses the following project elements: PEER_EX1_SEND_FBD (for sending Node #2) PEER_EX1_RCV_FBD (for receiving Node #3)
Sending Data Every Second to One Node

This is a simple example of sending data every second from Node #2 to Node #3. Scan time in both controllers is set to 100 milliseconds. The example uses the following project elements: PEER_EX2_SEND_FBD (for sending Node #2) PEER_EX2_RCV_FBD (for receiving Node #3)
73
Controlled Use of TR_USEND/TR_URCV Function Blocks

The networks in this example show how to use TR_USEND/TR_URCV function blocks correctly, in a controlled way, so that a limited amount of important data can be transferred between two applications when new data is ready to be sent. This example uses the following project elements: PEER_EX3_SEND_FBD (for sending Node #2) PEER_EX3_RCV_FBD (for receiving Node #3)
Using TR_USEND/TR_URCV Function Blocks for Safety-Critical Data

This example shows how to use TR_USEND/TR_URCV function blocks for transferring a limited amount of safety-critical data between the two applications as fast as possible. It also shows how to measure the actual maximum time for transferring data from the sending node to the receiving node. Because this is safety-critical data, each controller must have two NCMs and two peer-to-peer networks connected.
Sending Node #1 Parameters:

Scan time (SS) = 150 milliseconds Number of aliased variables in bytes = 2000 Time to transfer alias data over the communication bus in milliseconds (TS) = (2000/20000) * 1000 = 100 milliseconds The sending controller has only one TR_USEND function block in the application, meeting the requirement to have five or fewer TR_USEND function blocks. The sendflag is on in the TR_USEND function block so that, as soon as the last TR_USEND is acknowledged by the receiving controller, the sending controller initiates another TR_USEND
Receiving Node #3 Parameters:

Scan time (SR) = 200 milliseconds Number of aliased variables in bytes = 5000 Time to transfer aliased data over the communication bus in milliseconds (TR) = (5000/20000) * 1000 = 250 milliseconds Process tolerance time = 4 seconds
Appendix A
74
If the sending controller does not receive acknowledgment from the receiving controller in 1 second, then it automatically retries the last TR_USEND message. Assume that once in a while (due to network collisions, communication bus loading, etc.) the sending controller has to retry one time to get the message to the receiving node. This is why the general rule for data transfer time is 1 to 2 seconds, even though the estimated time is 800 milliseconds. The receiving node also has a network to measure the actual time so that you can validate the assumed 2-second maximum transfer time. Since the process-tolerance time of the receiving node is 4 seconds, the maximum time-out limit is set to 2 seconds (half the process tolerance time). The receiving node should get at least one sample of new data within the maximum time-out limit. Using this criteria satisfies the basic requirement for using peer-to-peer to transfer safety critical data. 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 TR_USEND is initiated. The receiving node checks the diagnostic variable to see that it has changed from the previous value received. The receiving node also checks whether it has received at least one sample of new data within the processtolerance 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)
TR_CRITICAL_IO Function Block
75

Accumulates Status of Critical I/O Modules The TR_CRITICAL_IO function block provides an easy way to accumulate the status of all safety-critical I/O modules in a Tricon system.
Instructions for Use

The following instructions for using the TR_CRITICAL_IO function block apply to the Structured Text (ST) language.
M To obtain the accumulated status of critical I/O modules: 1 Initialize TR_CRITICAL_IO by invoking it once with INIT := TRUE.
SCIO( INIT := TRUE );
where SCIO is the function block instance name

2 To complete initialization, invoke TR_CRITICAL_IO again as follows:
SCIO( INIT := FALSE, CI := TRUE, APP:=DE_ENERGIZED, RELAY_OK:=FALSE );

3 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 the following 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);
Appendix A
76
4 Read the output values:
CO TMR GE_DUAL GE_SINGLE NO_VOTER_FAULTS 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.
Parameter Inputs CI INIT CHASSIS SLOT APP RELAY_OK Outputs CO TMR Type BOOL BOOL DINT DINT DINT BOOL BOOL BOOL Description Control Inenables operation Initialize Chassis number (115) Physical slot number must be odd (1, 3...15) Application number (12) Relay is energized and not stuck Critical I/O Control Out Three channels are operating without faults on every critical I/O module At least two channels are operating without faults on every critical I/O module At least one channel is operating without faults on every critical I/O module No voter faults on critical I/O modules
GE_DUAL
BOOL
GE_SINGLE
BOOL
NO_VOTER_FLTS
BOOL
77
Parameter Outputs ERROR
Type DINT
Description Error Number: 0 = No error -1 = Slot is not odd or not numbered 115 -2 = Invalid chassis or slot -3 = Module not configured -4 = Reserved (not used) -5 = Invalid application number -6 = Not initialized
Runtime Error Code EBADPARAM
Return Value
Condition
Bad parameter
Note If there is a programming error, then CO is false and the error number is non-zero. For more information, see ERROR above.
App RELAY Relay_OK True Description A single fault (even 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.
RELAY DE-ENERGIZED Attribute Application Type Programming Usage CEM Feature
False Usage
Safety, Control N/A N/A
Library Tricon
Appendix A
78
Related Topics TR_64_POINT_STATUS TR_CALENDAR TR_MP_STATUS TR_PEER_STATUS TR_POINT_STATUS TR_PORT_STATUS TR_PROGRAM_STATUS TR_SCAN_STATUS TR_SHUTDOWN TR_SLOT_STATUS TR_VOTE_MODE
79
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. *) LEFT_GE_DUAL : BOOL ; (* Left slot, mode >= dual. *) LEFT_TMR : BOOL ; (* Left slot, mode = tmr. *) RIGHT_GE_SINGLE : BOOL ; (* Right slot, mode >= single. *) RIGHT_GE_DUAL : BOOL ; (* Right slot, mode >= dual. *) RIGHT_TMR : BOOL ; (* Right slot, mode = tmr. *) VOTER_FAULT : BOOL ; (* Voter fault on either slot. *) END_VAR (* *=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
Appendix A
80
* 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 sinlge 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 ; 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) ;
81
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 ; END_IF ; IF ERROR = 0 AND NOT CO THEN ERROR := -6 ; (* Not initialized *) 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
Appendix A
82
TR_SHUTDOWN Function Block

Enable System Shutdown The TR_SHUTDOWN function block provides an easy way to enable system shutdown according to industry guidelines.
Parameter Inputs CI Type BOOL Description Control Inenables operation If CI=FALSE, then CO=FALSEthere is no change in the output value If CI=TRUE and ERROR_NUM=0, then CO=TRUE IO_CO BOOL Critical I/O Control Out True indicates that a userdefined function block provides the status for critical I/O modules Three channels are operating without faults on every critical I/O module At least two channels are operating without faults on every critical I/O module At least one channel is operating without faults on every critical I/O module No voter faults exist on critical I/O modules Zero means no errornonzero means there is a programming error or a configuration error
IO_TMR
BOOL
IO_GE_DUAL
BOOL
IO_GE_SINGLE
BOOL
IO_NO_VOTER_FLTS IO_ERROR
BOOL DINT
83
Parameter Inputs MAX_TIME_DUAL
Type TIME
Description Maximum time of continuous operation in dual mode (with only two channels) Maximum time of continuous operation in single mode (with only one channel) 50% of the maximum response time Control Out Shutdown if FALSE Three channels operating Dual mode Single mode Zero mode Shutdown timer is running Time remaining to shutdown True if application changes are permitted True if remote-host writes are enabled True if actual scan time MAX_SCAN_TIME True if one or more points are disabled
MAX_TIME_SINGLE
TIME
MAX_SCAN_TIME Outputs CO OPERATING TMR DUAL SINGL ZERO TIMER_RUNNING TIME_LEFT ALARM_PROGRAMMING_ PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS
TIME BOOL BOOL BOOL BOOL BOOL BOOL BOOL TIME BOOL BOOL BOOL BOOL
Appendix A
84
Parameter Outputs ERROR_NUM
Type DINT
Description Error Number: 0 = No error 1 = Error in maximum time 2 = Error in I/O function block (IO_ERROR input is non-zero) 3 = Error in status function block
Return Value
Condition
Bad parameter
Note If there is a programming error, then CO is false and the error number is non-zero. For more information, see ERROR_NUM.
Attribute Application Type Programming Usage CEM Feature Usage Safety, Control N/A N/A
Library Tricon
85
Related Topics TR_64_POINT_STATUS TR_CALENDAR TR_CRITICAL_IO TR_MP_STATUS TR_PEER_STATUS TR_POINT_STATUS TR_PORT_STATUS TR_PROGRAM_STATUS TR_SCAN_STATUS TR_SLOT_STATUS TR_VOTE_MODE
Appendix A
86
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: *
87
* Example EX01_SHUTDOWN shows one way to check that * the safety system is operating within spec when * 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=============================================================================== *)
Appendix A
88
IF CI THEN (* Get Status *) MP( CI := TRUE ) ; 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 := SINGL := ZERO := GE_DUAL AND NOT TMR ; GE_SINGLE AND NOT GE_DUAL ; NOT GE_SINGLE ;
89
TIMER_RUNNING := OPERATING AND NOT TMR ; (* Output time remaining to shutdown. *) IF NOT OPERATING THEN 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; ; ; ; ; ; ; ; ; TRUE TRUE TRUE TRUE ; ; ; ;
ALARM_PROGRAMMING_PERMITTED := ALARM_REMOTE_ACCESS := ALARM_RESPONSE_TIME := ALARM_DISABLED_POINTS := END_IF ; END_IF ; END_FUNCTION_BLOCK
Appendix A
90
TR_VOTE_MODE Function Block

Converts Redundancy Status The TR_VOTE_MODE function block provides an easy way to convert redundancy status from one voting mode to another, as shown in the following truth table.
TMR GE_DUAL GE_SINGLE TMR DUAL SINGL ZERO
T F F F
T T F F Other1
T T T F
T F F F F
F T F F F
F F T F F
F F F T F
1. If there is an error in the inputs, then CO is false, the mode outputs are false, and the function block reports a bad parameter error (EBADPARAM).
Note To save memory and reduce scan time when using this function block, create a single instance of the function block in your program and invoke it multiple times. Do not use the same instance more than once in a network.
Parameter Inputs CI Type BOOL Description Control Inenables operation If CI=FALSE, then CO=FALSEthere is no change in the output value If CI=TRUE and ERROR_NUM=0, then CO =TRUE IN_TMR GE_DUAL GE_SINGLE Outputs CO BOOL BOOL BOOL BOOL Three critical I/O channels operating Two or more critical I/O channels operating One or more critical I/O channels operating Control Outindicates completion of the operation with no errors
91
Parameter Output TMR DUAL SINGL ZERO Runtime Error Code EBADPARAM
Type BOOL BOOL BOOL BOOL
Description Three critical I/O channels operating Dual mode Single mode Zero mode Condition
Return Value
Bad parameter
Note If there is a programming error, then CO is false and the mode outputs are set to false.
Attribute Application Type Programming Usage CEM Feature Usage Safety, Control Space Saver N/A
Library Tricon Related Topics TR_64_POINT_STATUS TR_CALENDAR TR_CRITICAL_IO TR_MP_STATUS TR_PEER_STATUS TR_POINT_STATUS TR_PORT_STATUS TR_PROGRAM_STATUS TR_SCAN_STATUS TR_SHUTDOWN TR_SLOT_STATUS
Appendix A
92
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. *)
(* *=F=============================================================================== * FUNCTION_BLOCK: TR_VOTE_MODE * Purpose: Convert redundancy status. * * Return: none * * 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 ;
93
Appendix A
94
APPENDIX B
Shutdown Function Blocks
This appendix provides information about shutdown function blocks. Topics include: TR_CRITICAL_IO Function Block . . . . . . . . . . . . . . . . . . . . . . . 96 TR_SHUTDOWN Function Block . . . . . . . . . . . . . . . . . . . . . . . 103 TR_VOTE_MODE Function Block . . . . . . . . . . . . . . . . . . . . . . 111
96

Accumulates Status of Critical I/O Modules The TR_CRITICAL_IO function block provides an easy way to accumulate the status of all safety-critical I/O modules in a Tricon system.
Instructions for Use

The following instructions for using the TR_CRITICAL_IO function block apply to the Structured Text (ST) language.
M To obtain the accumulated status of critical I/O modules: 1 Initialize TR_CRITICAL_IO by invoking it once with INIT := TRUE.
SCIO( INIT := TRUE );

2 To complete initialization, invoke TR_CRITICAL_IO again as follows:
SCIO( INIT := FALSE, CI := TRUE, APP:=DE_ENERGIZED, RELAY_OK:=FALSE );

3 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 the following 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);
97
4 Read the output values:
CO TMR GE_DUAL GE_SINGLE NO_VOTER_FAULTS 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.
Parameter Inputs CI INIT CHASSIS SLOT APP RELAY_OK Outputs CO TMR Type BOOL BOOL DINT DINT DINT BOOL BOOL BOOL Description Control Inenables operation Initialize Chassis number (115) Physical slot number must be odd (1, 3...15) Application number (12) Relay is energized and not stuck Critical I/O Control Out Three channels are operating without faults on every critical I/O module At least two channels are operating without faults on every critical I/O module At least one channel is operating without faults on every critical I/O module No voter faults on critical I/O modules
GE_DUAL
BOOL
GE_SINGLE
BOOL
NO_VOTER_FLTS
BOOL
Appendix B
98
Parameter Outputs ERROR
Type DINT
Description Error Number: 0 = No error -1 = Slot is not odd or not numbered 115 -2 = Invalid chassis or slot -3 = Module not configured -4 = Reserved (not used) -5 = Invalid application number -6 = Not initialized
Return Value
Condition
Bad parameter
Note If there is a programming error, then CO is false and the error number is non-zero. For more information, see ERROR above.
App RELAY Relay_OK True Description A single fault (even 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 ouput voter channel) that can deenergize the output. A voter fault degrades the mode to single. A non-voter fault degrades the mode to dual.
RELAY DE-ENERGIZED Attribute Application Type Programming Usage CEM Feature
False Usage
Safety, Control N/A N/A
Library Tricon
99
Related Topics TR_64_POINT_STATUS TR_CALENDAR TR_MP_STATUS TR_PEER_STATUS TR_POINT_STATUS TR_PORT_STATUS TR_PROGRAM_STATUS TR_SCAN_STATUS TR_SHUTDOWN TR_SLOT_STATUS TR_VOTE_MODE
Appendix B
100
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. *) LEFT_GE_DUAL : BOOL ; (* Left slot, mode >= dual. *) LEFT_TMR : BOOL ; (* Left slot, mode = tmr. *) RIGHT_GE_SINGLE : BOOL ; (* Right slot, mode >= single. *) RIGHT_GE_DUAL : BOOL ; (* Right slot, mode >= dual. *) RIGHT_TMR : BOOL ; (* Right slot, mode = tmr. *) VOTER_FAULT : BOOL ; (* Voter fault on either slot. *) END_VAR (* *=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
101
* 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 sinlge 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 ; 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) ;
Appendix B
102
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 ; END_IF ; IF ERROR = 0 AND NOT CO THEN ERROR := -6 ; (* Not initialized *) 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
103

Enable System Shutdown The TR_SHUTDOWN function block provides an easy way to enable system shutdown according to industry guidelines.
Parameter Inputs CI Type BOOL Description Control Inenables operation If CI=FALSE, then CO=FALSEthere is no change in the output value If CI=TRUE and ERROR_NUM=0, then CO=TRUE IO_CO BOOL Critical I/O Control Out True indicates that a userdefined function block provides the status for critical I/O modules Three channels are operating without faults on every critical I/O module At least two channels are operating without faults on every critical I/O module At least one channel is operating without faults on every critical I/O module No voter faults exist on critical I/O modules Zero means no errornonzero means there is a programming error or a configuration error
IO_TMR
BOOL
IO_GE_DUAL
BOOL
IO_GE_SINGLE
BOOL
IO_NO_VOTER_FLTS IO_ERROR
BOOL DINT
Appendix B
104
Parameter Inputs MAX_TIME_DUAL
Type TIME
Description Maximum time of continuous operation in dual mode (with only two channels) Maximum time of continuous operation in single mode (with only one channel) 50% of the maximum response time Control Out Shutdown if FALSE Three channels operating Dual mode Single mode Zero mode Shutdown timer is running Time remaining to shutdown True if application changes are permitted True if remote-host writes are enabled True if actual scan time MAX_SCAN_TIME True if one or more points are disabled
MAX_TIME_SINGLE
TIME
MAX_SCAN_TIME Outputs CO OPERATING TMR DUAL SINGL ZERO TIMER_RUNNING TIME_LEFT ALARM_PROGRAMMING_ PERMITTED ALARM_REMOTE_ACCESS ALARM_RESPONSE_TIME ALARM_DISABLED_POINTS
TIME BOOL BOOL BOOL BOOL BOOL BOOL BOOL TIME BOOL BOOL BOOL BOOL
105
Parameter Outputs ERROR_NUM
Type DINT
Description Error Number: 0 = No error 1 = Error in maximum time 2 = Error in I/O function block (IO_ERROR input is non-zero) 3 = Error in status function block
Return Value
Condition
Bad parameter
Note If there is a programming error, then CO is false and the error number is non-zero. For more information, see ERROR_NUM.
Attribute Application Type Programming Usage CEM Feature Usage Safety, Control N/A N/A
Library Tricon
Appendix B
106
Related Topics TR_64_POINT_STATUS TR_CALENDAR TR_CRITICAL_IO TR_MP_STATUS TR_PEER_STATUS TR_POINT_STATUS TR_PORT_STATUS TR_PROGRAM_STATUS TR_SCAN_STATUS TR_SLOT_STATUS TR_VOTE_MODE
107
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: *
Appendix B
108
* Example EX01_SHUTDOWN shows one way to check that * the safety system is operating within spec when * 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=============================================================================== *)
109
IF CI THEN (* Get Status *) MP( CI := TRUE ) ; 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 := SINGL := ZERO := GE_DUAL AND NOT TMR ; GE_SINGLE AND NOT GE_DUAL ; NOT GE_SINGLE ;
Appendix B
110
TIMER_RUNNING := OPERATING AND NOT TMR ; (* Output time remaining to shutdown. *) IF NOT OPERATING THEN 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; ; ; ; ; ; ; ; ; TRUE TRUE TRUE TRUE ; ; ; ;
ALARM_PROGRAMMING_PERMITTED := ALARM_REMOTE_ACCESS := ALARM_RESPONSE_TIME := ALARM_DISABLED_POINTS := END_IF ; END_IF ; END_FUNCTION_BLOCK
111

Converts Redundancy Status The TR_VOTE_MODE function block provides an easy way to convert redundancy status from one voting mode to another, as shown in the following truth table.
TMR GE_DUAL GE_SINGLE TMR DUAL SINGL ZERO
T F F F
T T F F Other1
T T T F
T F F F F
F T F F F
F F T F F
F F F T F
1. If there is an error in the inputs, then CO is false, the mode outputs are false, and the function block reports a bad parameter error (EBADPARAM).
Note To save memory and reduce scan time when using this function block, create a single instance of the function block in your program and invoke it multiple times. Do not use the same instance more than once in a network.
Parameter Inputs CI Type BOOL Description Control Inenables operation If CI=FALSE, then CO=FALSEthere is no change in the output value If CI=TRUE and ERROR_NUM=0, then CO =TRUE IN_TMR GE_DUAL GE_SINGLE Outputs CO BOOL BOOL BOOL BOOL Three critical I/O channels operating Two or more critical I/O channels operating One or more critical I/O channels operating Control Outindicates completion of the operation with no errors
Appendix B
112
Parameter Output TMR DUAL SINGL ZERO Runtime Error Code EBADPARAM
Type BOOL BOOL BOOL BOOL
Description Three critical I/O channels operating Dual mode Single mode Zero mode Condition
Return Value
Bad parameter
Note If there is a programming error, then CO is false and the mode outputs are set to false.
Attribute Application Type Programming Usage CEM Feature Usage Safety, Control Space Saver N/A
Library Tricon Related Topics TR_64_POINT_STATUS TR_CALENDAR TR_CRITICAL_IO TR_MP_STATUS TR_PEER_STATUS TR_POINT_STATUS TR_PORT_STATUS TR_PROGRAM_STATUS TR_SCAN_STATUS TR_SHUTDOWN TR_SLOT_STATUS
113
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. *)
(* *=F=============================================================================== * FUNCTION_BLOCK: TR_VOTE_MODE * Purpose: Convert redundancy status. * * Return: none * * 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 ;
Appendix B
114
Index
115
Index
A
actual scan time 53 alarms Analog Input Module 44 Analog Output Module 44 Digital Input Module 43 Digital Output Module 43 disabled points 24, 68 I/O modules 45 output operation 59, 64 programming permitted 68 Relay Output Module 45 remote access 68 semaphore flags 46 system attributes 47 Analog Input Module alarms 44 diagnostics 44 Analog Output Module alarms 44 diagnostics 44 analysis hazard and risk 5 ANSI/ISA S84.01 16 application-specific standards 17 architecture system 38 TMR 38
C
calculating PFDavg equation for block valves 9 equation for sensors 9 equation for system 9 calculation SIL example 8 certification TV Rheinland 20 commands Compare to Last Download 52 Download All 25 Download Change 51 Upload and Verify 52 communication external 46 serial 32 Compare to Last Download command 52 contacting Triconex viii converting redundancy status 90, 111 critical I/O modules accumulating status 75, 96 CSA C22.2 NO 199 17 customer support viii
D
design requirements 33 development guidelines 50 diagnostics Analog Input Module 44 Analog Output Module 44 Digital Input Module 43 Digital Output Module 43 disable output voter 25
B
block valve equation for calculating PFDavg 9 burner management systems 21 bus Tribus 38
116
Index
Relay Output Module 45 system 39 Digital Input Module alarms 43 diagnostics 43 Digital Output Module alarms 43 diagnostics 43 DIN V 19250 15 DIN V VDE 0801 15 DIN VDE 0116 17 disable output voter diagnostics 25 disabled points alarms 24, 68 Download All command 25 Download Change command 51
G
general guidelines 20 guidelines development 50 general 20 SIL 2730 SIL fire and gas 28, 30 SIL general 27, 29 Tricon controller 23
H
hazard and risk analysis 5
I
I/O modules accumulating status 75, 96 alarms 45 system-critical 55 IEC 61508, parts 17 16 IEC 61511 16 Input Module alarms Analog 44 Digital 43 Input Module diagnostics Analog 44 Digital 43 input parameters 57, 62 installation check TriStation 50 internal faults 40
E
emergency shutdown system 21 EN 54, part 3 17 equations calculating PFDavg for sensors 9 calculating PFDavg for system 9 calculating PFDavgfor block valves 9 EX01_shutdown program 56 EX02_shutdown program 61 EX03_shutdown program 67 external communication 46 external faults 40
F
factors SIL 4 SIS 5 faults external 40 internal 40 types 40 fire and gas systems 22 flags semaphore 46 functions Modbus master 25
L
layers protection 5 life cycle model safety 12
M
Main Processor system attributes 47 Tribus 46 maintenance overrides 32
Index
117
Modbus master functions 25 model safety life cycle 12 modes operating 41 module alarms Analog Input 44 Analog Output 44 Digital Input 43 Digital Output 43 I/O 45 Relay Output 45 module diagnostics Analog Input 44 Analog Output 44 Digital Input 43 Digital Output 43 Relay Output 45 modules accumulating status 75, 96 safety-critical 24 system-critical shutdown program for all 55 system-critical shutdown program for some 60
Relay 45 Output Module diagnostics Analog 44 Digital 43 Relay 45 output operation alarms 64 output parameters 58, 63 output voter diagnostics disable 25 OVD See output voter diagnostics overrides maintenance 32 overrun scan 54 overview safety 5
P
parameters input 62 output 58 partitioning processes 66 Peer-to-Peer communication 25 description of function blocks for 70, 96 Peer-to-Peer function blocks data transfer time 70, 96 errors 71 examples 72 rules for correct usage 70, 96 using with critical data 26 permitted alarms programming 68 PFDavg for block valve equation for calculating 9 PFDavg for sensors equation for calculating 9 PFDavg for system equation for calculating 9 points alarms disabled 68 processes partitioning 66
N
NFPA 72 17 NFPA 8501 17 NFPA 8502 17
O
operating modes dual 41 single 41 TMR 41 zero 41 operating requirements 34 operation alarm output 59, 64 Output Module alarms Analog 44 Digital 43
118
Index
programming permitted alarm 68 programs EX01_shutdown 56 EX02_shutdown 61 EX03_shutdown 67 safety-shutdown for all system-critical I/O modules 55 safety-shutdown for some system-critical I/O modules 60 protection layers 5
R
redundancy status converting 90, 111 Relay Output Module alarms 45 diagnostics 45 requested scan time 53 requirements design 33 operating 34 response time and scan time 24, 68
S
safety life cycle model 12 safety overview 5 safety-critical modules 24 safety-shutdown 24 networks 24 programs for all system-critical I/O modules modules 55 programs for some system-critical I/O modules 60 scan overrun 54 scan surplus 53 scan time 53 actual 53 requested 53 response time and 24, 68 semaphore flags 46 sensors equation for calculating PFDavg 9 serial communication 32
shutdown enabling for Tricon 82, 103 programs for all system-critical I/O modules 55 programs for some system-critical I/O modules 60 safe 24 systems emergency 21 SIL calculation example 8 factors 4 fire and gas guidelines 28, 30 general guidelines 27, 29 guidelines 2730 SIS factors 5 standards application-specific 17 general 1516 status of critical I/O modules 75, 96 surplus scan 53 SYS_SHUTDOWN parameters input 57 output 63 system architecture 38 attributes as alarms 47 attributes of Main Processor 47 diagnostics 39 enabling shutdown for Tricon 82, 103 equation for calculating PFDavg 9 system-critical I/O modules safety-shutdown program for all 55 safety-shutdown program for some 60 systems burner management 21 emergency shutdown 21 fire and gas 22
T
technical support viii
Index
119
time scan 53 TMR architecture 38 TR_SHUTDOWN function block 82, 103 TR_VOTE_MODE function block 90, 111 training x Tribus Main Processor 46 system architecture 38 Triconex support viii Triple Module Redundant See TMR TriStation Install Check 50 TV Rheinland certification 20 types of faults 40
U
Upload and Verify command 52
V
voter diagnostics disable output 25
120
Index

Safety Considerations Guide Tricon v9 6

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Safety Considerations Guide Tricon v9 6

Uploaded by

Copyright:

Available Formats

Tricon Version 9

Safety Considerations Guide

Triconex Corporation An Invensys company

Document No. 9720078-002 Printed in the United States of America.

About This Guide

How This Guide Is Organized

Tricon Safety Considerations Guide

Tricon Safety Considerations Guide

Abbreviations Used vii

How to Contact Triconex

How to Contact Triconex

Requesting Technical Support

Gathering Supporting Documentation

Tricon Safety Considerations Guide

Requesting Technical Support ix

Contacting Triconex Technical Support

For ESD Systems

For Turbomachinery Systems

Tricon Safety Considerations Guide

Tricon Safety Considerations Guide

About This Guide .................................................................................................... v

Safety Concepts ........................................................................... 1

Tricon Safety Considerations Guide

NFPA 8502 ....................................................................................... 17 CSA C22.2 NO 199 ........................................................................... 17

Application Guidelines .............................................................. 19

Fault Management ..................................................................... 37

Tricon Safety Considerations Guide

Application Development .......................................................... 49

Peer-to-Peer Communication .................................................... 69

Tricon Safety Considerations Guide

Shutdown Function Blocks ...................................................... 95

Index .................................................................................................................... 115

Tricon Safety Considerations Guide

Tricon Safety Considerations Guide

Tricon Safety Considerations Guide

Acceptable Risk Level

Mechanical Integrity Inherent Process Risk

Effect of Protection Layers on Process Risk

* BPCSBasic process control system SISSafety-instrumented system SVSafety (relief) valve

Tricon Safety Considerations Guide

Hazard and Risk Analysis 5

Hazard and Risk Analysis

Hazard and Risk Analysis

Safety Integrity Levels

99.999 99.99 99.90 99.00 90.00

Standards and Risk Measures

Determining a Safety Integrity Level

Tricon Safety Considerations Guide

Hazard and Risk Analysis 7

Hazard and Risk Analysis

Example SIL Calculation

99.9999 R i s k 99.999 99.99 99.90 99.00 90.00

Comparison of Percent Availability and PFD

Percent Availability Risk Measures

Simplified Diagram of Key Elements

TMR Controller (2oo3) PES/Logic Solver

2 Block Valves in Series (1oo2) Final Elements

Tricon Safety Considerations Guide

Hazard and Risk Analysis 9

Hazard and Risk Analysis

Using the Equations

PFD 1.00E-04 1.56E-04

2.56E-04 4380 3.33E-05 3.33E-05