9720097-008 safety considerations guide for tricon v9-v10 systems.pdf

7/26/2019 9720097-008 Safety Considerations Guide for Tricon v9-v10 Systems.pdf

1/116

Assembly Number 9700097-008

January 2011

Tricon v9v10

Safety ConsiderationsGuide


2/116

Information in this document is subject to change without notice. Companies, names and data used inexamples herein are fictitious unless otherwise noted. No part of this document may be reproduced ortransmitted in any form or by any means, electronic or mechanical, for any purpose, without the expresswritten permission of Invensys Systems, Inc.

2006-2011 by Invensys Systems, Inc. All rights reserved.

Invensys, the Invensys logo, Triconex, Tricon, Trident, and TriStation are trademarks of Invensys plc, itssubsidiaries and affiliates. All other brands may be trademarks of their respective owners.

Document Number 9720097-008

Printed in the United States of America.


3/116

Safety Considerations Guide for Tricon v9v10 Systems

Contents

Preface viiSummary of Sections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .viiRelated Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .viAbbreviations Used. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiProduct and Training Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiTechnical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixWe Welcome Your Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Chapter 1 Safety Concepts 1Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Protection Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3SIS Factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4SIL Factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Hazard and Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Safety Integrity Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Safety Life Cycle Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Safety Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12General Safety Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Application-Specific Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Chapter 2 Application Guidelines 15Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16TV Rheinland Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

All Safety Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Emergency Shutdown Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Burner Management Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Fire and Gas Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Guidelines for Tricon Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Safety-Critical Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Safety-Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Response Time and Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Disabled Points Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Disabled Output Voter Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Download All at Completion of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Modbus Master Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Triconex Peer-to-Peer Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
http://chp1.pdf/http://chp1.pdf/


4/116

iv Contents


SIL3/AK5 Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23AK6 Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Periodic Offline Test Interval Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Project Change and Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Maintenance Overrides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Safety System Boundary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Chapter 3 Fault Management 33Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34System Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Types of Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

External Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Internal Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Operating Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Module Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Digital Input (DI) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Digital Output (DO) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Analog Input (AI) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Analog Output (AO) Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Pulse Input (PI) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Relay Output (RO) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Input/Output Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Main Processor and TriBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41External Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Chapter 4 Application Development 43

Development Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Invensys Product Alert Notices (PANs). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Safety and Control Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44VAR_IN_OUT Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Array Index Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Infinite Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Important TriStation 1131 Software Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Download Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Verify Last Download to the Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Compare to Last Download. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Setting Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Scan Surplus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Sample Safety-Shutdown Programs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49When All I/O Modules Safety-Critical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49When Some I/O Modules Are Safety-Critical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Defining Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Partitioned Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58


5/116

Contents v


Alarm Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Programming Permitted Alarm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Remote Access Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Response Time and Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Disabled Points Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Appendix A Triconex Peer-to-Peer Communication 61Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Data Transfer Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Estimating Memory for Peer-to-Peer Data Transfer Time. . . . . . . . . . . . . . . . . . . . . . 63Estimating the Data Transfer Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Examples of Peer-to-Peer Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Example 1: Fast Send to One Triconex Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Example 2: Sending Data Every Second to One Node. . . . . . . . . . . . . . . . . . . . . . . . . 66Example 3: Controlled Use of SEND/RECEIVE Function Blocks . . . . . . . . . . . . . . . 66Example 4: Using SEND/RECEIVE Function Blocks for Safety-Critical Data. . . . . 67

Appendix B HART Communication 69Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70HART Position Paper from TV Rheinland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Appendix C Safety-Critical Function Blocks 79Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80GATDIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81GATENB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82TR_CRITICAL_IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

TR_SHUTDOWN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90TR_VOTE_MODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Index 101


6/116

vi Contents



7/116


Preface

This guide provides information about safety concepts and standards that apply to the Triconcontroller. This document replaces all previous versions of the Safety Considerations Guide forTricon Systems.

Summary of Sections

Chapter 1, Safety ConceptsDescribes safety issues, safety standards, andimplementation of safety measures.

Chapter 2, Application GuidelinesProvides information on industry guidelines andrecommendations.

Chapter 3, Fault ManagementDiscusses fault tolerance and fault detection.

Chapter 4, Application DevelopmentDiscusses methods for developing applicationsproperly to avoid application faults.

Appendix A, Triconex Peer-to-Peer CommunicationProvides examples of usingTriconexPeer-to-Peer function blocks to transfer data between applications.

Appendix B, HART Communicationcontains a position paper from TV Rheinlandon using the HART communication protocol in safety-related applications withinSafety Instrumented Systems (SIS).

Appendix C, Safety-Critical Function BlocksDescribes the function blocks intendedfor use in safety-critical applications and shows their Structured Text code.

Related Documents

Communication Guide for Tricon v9v10 Systems

Field Terminations Guide for Tricon v9v10 Systems

Planning and Installation Guide for Tricon v9v10 Systems

TriStation 1131 Developers Guide

TriStation 1131 Libraries Reference


8/116

viii Chapter


Abbreviations Used

The TriStation 1131 Developers Workbench is hereafter called TriStation 1131 software.

The following list provides full names for abbreviations of safety terms used in this guide.

Product and Training Information

To obtain information about Invensys products and in-house and on-site training, see theInvensys web site or contact your regional customer center.

Web Site

http://www.iom.invensys.com

BPCS Basic process control systemESD Emergency shutdown

HAZOP Hazard and operability study

MOC Management of change

MTBF Mean time between failure

PES Programmable electronic system

PFDavg Average probability of failure toperform IES design function ondemand

PHA Process hazard analysis

PSM Process safety management

RMP Risk management program

RRF Risk reduction factor

SFF Safe failure fraction

SIL Safety integrity level

SIS Safety-instrumented system

SOV Solenoid-operated valve

SRS Safety requirements specification

SV Safety (relief) valve


9/116

Preface ix


Technical Support

Customers in the U.S. and Canada can obtain technical support from the Invensys GlobalCustomer Support (GCS) Center at the numbers below. International customers should contacttheir regional support center.

Requests for support are prioritized as follows: Emergency requests are given the highest priority

Requests from participants in the System Watch Agreement (SWA) and customers withpurchase order or charge card authorization are given next priority

All other requests are handled on a time-available basis

If you require emergency or immediate response and are not an SWA participant, you mayincur a charge. Please have a purchase order or credit card available for billing.

Telephone

Toll-free number 866-746-6477, orToll number 508-549-2424 (outside U.S.)

Fax

Toll number 508-549-4999

Web Site

http://support.ips.invensys.com (registration required)

E-mail

[email protected]
http://support.ips.invensys.com/http://support.ips.invensys.com/


10/116

x Chapter


We Welcome Your Comments

To help us improve future versions of Triconex documentation, we want to know about anycorrections, clarifications, or further information you would find useful. When you contact us,please include the following information:

The title and version of the guide you are referring to A brief description of the content you are referring to (for example, step-by-step

instructions that are incorrect, information that requires clarification or more details,missing information that you would find helpful)

Your suggestions for correcting or improving the documentation

The version of the Triconex hardware or software you are using

Your name, company name, job title, phone number and e-mail address

Send e-mail to us at:

[email protected]

Please keep in mind that this e-mail address is only for documentation feedback. If you have atechnical problem or question, please contact the Customer Satisfaction Center. See TechnicalSupport on page ixfor contact information.

Or, you can write to us at:

Attn: Technical Publications - TriconexInvensys26561 Rancho Parkway SouthLake Forest, CA 92630

Thank you for your feedback.


11/116


1Safety Concepts

Overview 2

Hazard and Risk Analysis 5

Safety Standards 12

Application-Specific Standards 13


12/116

2 Chapter 1 Safety Concepts


OverviewModern industrial processes tend to be technically complex, involve substantial energies, andhave 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 andmaintenance

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


13/116

Overview 3


Protection Layers

Methods that provide layers of protection should be:

Independent

Verifiable

Dependable

Designed for the specific safety risk

This figure shows how layers of protection can be used to reduce unacceptable risk to anacceptable level. The amount of risk reduction for each layer is dependent on the specific natureof the safety risk and the impact of the layer on the risk. Economic analysis should be used todetermine the appropriate combination of layers for mitigating safety risks.

Figure 1 Effect of Protection Layers on Process Risk

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 orIEC 61508 standards during a process hazard analysis (PHA).


14/116



SIS Factors

According to the ANSI/ISA S84.01 and IEC 61508 standards, the scope of an SIS is restricted tothe instrumentation or controls that are responsible for bringing a process to a safe state in theevent of a failure. The availability of an SIS is dependent upon:

Failure rates and modes of components Installed instrumentation

Redundancy

Voting

Diagnostic coverage

Testing frequency

SIL Factors

An SIL can be considered a statistical representation of the availability of an SIS at the time of aprocess demand. Aprocess demandis defined as the occurrence of a process deviation that causesan SIS to transition a process to a safe state.

An SIL is the litmus test of acceptable SIS design and includes the following factors:

Device integrity

Diagnostics

Systematic and common cause failures

Testing

Operation

Maintenance

In modern applications, a programmable electronic system (PES) is used as the core of an SIS.The Tricon controller is a state-of-the-art PES optimized for safety-critical applications.


15/116



Hazard and Risk AnalysisIn the United States, OSHA Process Safety Management (PSM) and EPA Risk ManagementProgram (RMP) regulations dictate that a PHA be used to identify potential hazards in theoperation 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 verysimple 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. AHAZOP provides a prioritized basis for the implementation of risk mitigation strategies, suchas SISs or ESDs.

If a PHA determines that the mechanical integrity of a process and the process control areinsufficient to mitigate the potential hazard, an SIS is required. An SIS consists of theinstrumentation or controls that are installed for the purpose of mitigating a hazard or bringinga process to a safe state in the event of a process disruption.

A compliant program incorporates good engineering practice. This means that the programfollows the codes and standards published by such organizations as the American Society ofMechanical Engineers, American Petroleum Institute, American National Standards Institute,National Fire Protection Association, American Society for Testing and Materials, and NationalBoard of Boiler and Pressure Vessel Inspectors. Other countries have similar requirements.

Safety Integrity Levels

This figure shows the relationship of DIN V 19250 classes and SILs (safety integrity levels).

Figure 2 Standards and Risk Measures

Note DIN V 19250 was withdrawn in August 2004. It is not applicable to Tricon v10 systems,only Tricon v9 systems.

Risk Measures

R

ISK

REDUCTION

99.999

99.99

99.90

99.00

90.00

0.00001

0.0001

0.001

0.01

0.1

>10,000

10,0001,000

1,000100

10010

PercentAvailability PFDavg RRF

Risk Standards

SIL 3

SIL 4

SIL 1

SIL 3

SIL 1

SIL 2 SIL 2

AK 8

AK 6AK 5

AK 4AK 3

AK 2AK 1

ANSI/ISAS84.01

IEC61508

DIN V19250

AK 7


16/116



As a required SIL increases, SIS integrity increases as measured by:

System availability (expressed as a percentage)

Average probability of failure to perform IES design function on demand (PFDavg)

Risk reduction factor (RRF, reciprocal of PFDavg)

The relationship between AK class (see page 12) and SIL is extremely important and should notbe overlooked. These designations were developed in response to serious incidents thatresulted in the loss of life, and are intended to serve as a foundation for the effective selectionand appropriate design of safety-instrumented systems.

Determining a Safety Integrity Level

If a PHA (process hazard analysis) concludes that an SIS is required, ANSI/ISA S84.01 and IEC61508 require that a target SIL be assigned. The assignment of a SIL is a corporate decision basedon risk management and risk tolerance philosophy. Safety regulations require that theassignment of SILs should be carefully performed and thoroughly documented.

Completion of a HAZOP determines the severity and probability of the risks associated with aprocess. Risk severity is based on a measure of the anticipated impact or consequences.

On-site consequences include:

Worker injury or death

Equipment damage

Off-site consequences include:

Community exposure, including injury and death

Property damage

Environmental impact

Emission of hazardous chemicals

Contamination of air, soil, and water supplies

Damage to environmentally sensitive areas

A risk probabilityis an estimate of the likelihood that an expected event will occur. Classified ashigh, medium, or low, a risk probability is often based on a companys or a competitorsoperating 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 IEC61508 risk graph.


17/116



Sample Low Demand SIL Calculation

As a PES, the Tricon controller is designed to minimize its contribution to the SIL, therebyallowing greater flexibility in the SIS design.

Figure 3 Comparison of Percent Availability and PFD

* Tricon controller module failure rates, PFDavg, Spurious Trip Rate, and Safe Failure Fraction(SFF) calculation methods have been independently calculated and/or reviewed by FactoryMutual Research and TV Rheinland. The numbers presented here (and in the following tables)are typical. Exact numbers should be calculated for each specific system configuration. Contact

Invensys for details on calculation methods and options related to the Tricon controller.

Figure 4 Simplified Diagram of Key Elements

3 PressureTransmitters (2oo3)

3 TemperatureTransmitters (2oo3)

Sensors

TMR Controller(2oo3)

PES/Logic Solver

2 Block Valvesin Series (1oo2)

Final Elements

Sa ety Integrate System


18/116



This table provides simplified equations for calculating the PDFavgfor the key elements in anSIS. Once the PDFavgfor each element is known, an SIL can be determined.

Note Equations are approximate

To determine the SIL, compare the calculated PFDavg to the figure on page 5. In this example,the system is acceptable as an SIS for use in SIL3 applications.

For additional information on SIL assignment and SIL verification, visit the Premier ConsultingServices web site at http://www.premier-fs.com.

Table 1 Simplified Equations for Calculating PFDavg

Description EquationVariables(supplied by the manufacturer)

Sensors To calculatePFDavgforsensors (2oo3)

PFDavg = (DU*TI)2

+ 1/2**DU*TI = failure rateDU=dangerous, undetected failure rateTI= test interval in hours = common cause factor

BlockValves

To calculatePFDavgforblock valves(1oo2) in series(final elements)

PFDavg = 1/3(DU*TI)2

+ 1/2**DU*TI = failure rateDU=dangerous, undetected failure rateTI= test interval in hours = common cause factor

System To calculatePFDavg for asystem

System PFDavg =

Sensors PFDavg+Block Valves PFDavg +Controller PFDavg

Table 2 Determining the SIL Using the Equations

DU TI PFD Result

Pressure Transmitters (2oo3) .03 2.0E-06 4380 2.1E-04Temperature Transmitters (2oo3) .03 2.6E-06 4380 3.0E-04

Total for Sensors 5.1E-04

Block Valves (1oo2) .02 2.2E-06 4380 1.3E-04

Total for Block Valves 1.3E-04

Trident Controller 4380 1.0E-05 0.1E-04

PFDavgfor SIF 6.5E-04
http://www.premier-fs.com/http://www.premier-fs.com/


19/116



Safety Life Cycle Model

The necessary steps for designing an SIS from conception through decommissioning aredescribed in the safety life cycle.

Before the safety life cycle model is implemented, the following requirements should be met:

Complete a hazard and operability study

Determine the SIS requirement

Determine the target SIL

Figure 5 Safety Life Cycle Model

START

Designconceptual process

Perform SISdetail design

(Step 3)

Perform processhazard analysis

and riskassessment Perform SIS

conceptualdesign and verifyit meets the SRS

(Step 2)

SIS installation,commissioning,and pre-startupacceptance test

(Step 4)

Develop safetyrequirements

document(Step 1)

Apply non-SISprotection layers toprevent identifiedhazards or reduce

risk

SISrequired?

No

Define target SIL

Yes

SISdecommissioning

(Step 9)

Pre-start-upsafety reviewassessment

(Step 6)

Establish operationand maintenance

procedure(Step 5)

SIS start-upoperation,

maintenance,

periodic functionaltesting

(Steps 7 and 8)

Modify ordecommission

SIS?

Decommission

Conceptual process design

S84.01 Concern(Step 3)

Modify

EXIT


20/116



Developing an SIS Using the Safety Life Cycle

1 Develop a safety requirement specification (SRS).

An SRS consists of safety functional requirementsand safety integrity requirements. An SRScan be a collection of documents or information.

Safety functional requirements specify the logic and actions to be performed by an SISand the process conditions under which actions are initiated. These requirementsinclude such items as consideration for manual shutdown, loss of energy source, etc.

Safety integrity requirements specify a SIL and the performance required for executingSIS 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 Develop the conceptual design, making sure to: Define the SIS architecture to ensure the SIL is met (for example, voting 1oo1, 1oo2,

2oo2, 2oo3).

Define the logic solver to meet the highest SIL (if different SIL levels are required ina single logic solver).

Select a functional test interval to achieve the SIL.

Verify the conceptual design against the SRS.

3 Develop a detailed SIS design including:

General requirements

SIS logic solver

Field devices

Interfaces

Energy sources

System environment

Application logic requirements

Maintenance or testing requirements

Some key ANSI/ISA S84.01 requirements are:

The logic solver shall be separated from the basic process control system (BPCS). Sensors for the SIS shall be separated from the sensors for the BPCS.

The logic system vendor shall provide MTBF data and the covert failure listing,including the frequency of occurrence of identified covert failures.

Note Triconex controllers do not contain undiagnosed dangerous faults that arestatistically significant.


21/116



Each individual field device shall have its own dedicated wiring to the system I/O.Using a field bus is not allowed!

A control valve from the BPCS shall not be used as a single final element for SIL3.

The operator interface may not be allowed to change the SIS application software.

Maintenance overrides shall not be used as a part of application software oroperating procedures.

When online testing is required, test facilities shall be an integral part of the SISdesign.

4 Develop a pre-start-up acceptance test procedure that provides a fully functional test ofthe SIS to verify conformance with the SRS.

5 Before startup, establish operational and maintenance procedures to ensure that the SISfunctions 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.

7 Define procedures for the following:

Start-up

Operations

Maintenance, including administrative controls and written procedures that ensuresafety if a process is hazardous while an SIS function is being bypassed

Training that complies with national regulations (such as OSHA 29 CFR 1910.119)

Functional testing to detect covert faults that prevent the SIS from operatingaccording to the SRS

SIS testing, including sensors, logic solver, and final elements (such as shutdownvalves, motors, etc.)

8 Follow management of change (MOC) procedures to ensure that no unauthorized

changes are made to an application, as mandated by OSHA 29 CFR 1910.119.9 Decommission an SIS before its permanent retirement from active service, to ensure

proper review.


22/116



Safety StandardsOver the past several years, there has been rapid movement in many countries to developstandards and regulations to minimize the impact of industrial accidents on citizens. Thestandards described in this section 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 andControl Equipment. DIN V 19250 establishes the concept that safety systems should bedesigned to meet designated classes, Class 1 (AK1) through Class 8 (AK8). The choice of theclass is dependent on the level of risk posed by the process. DIN V 19250 attempts to force usersto consider the hazards involved in their processes and to determine the integrity of therequired safety-related system.

Note DIN V 19250 was withdrawn in August 2004. It is not applicable to Tricon v10 systems,only Tricon v9 systems.

DIN V VDE 0801

As the use of programmable electronic systems (PES) in safety system designs has becomeprevalent, it is necessary to determine whether the design of a PES is sufficiently rigorous forthe application and for the DIN V 19250 class. DIN V VDE 0801, Principles for Computers inSafety-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 documentedby independent persons. Thus, DIN V VDE 0801 provides a means of determining if a PES meetscertain DIN V 19250 classes.

Note DIN V 19250 and DIN V VDE 0801 were withdrawn in August 2004. They are not

applicable to Tricon v10 systems, only Tricon v9 systems.

IEC 61508, Parts 17

The IEC 61508 standard, Functional Safety: Safety Related Systems, is an internationalstandard designed to address a complete SIS for the process, transit, and medical industries. Thestandard introduces the concept of a safety life cycle model (see Figure 5 on page 9) to illustrate
http://-/?-http://-/?-


23/116

Safety Standards 13


that the integrity of an SIS is not limited to device integrity, but is also a function of design,operation, testing, and maintenance.

The standard includes four SILs that are indexed to a specific probability-to-fail-on-demand(PFD) (see Figure 2 on page 5). A SIL assignment is based on the required risk reduction asdetermined 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 Committeedetermined that SIL 4 is applicable for medical and transit systems in which the only layer ofprotection is the safety-instrumented layer. In contrast, the process industry can integrate manylayers of protection in the process design. The overall risk reduction from these layers ofprotection is equal to or greater than that of other industries.

Note DIN V 19250 was withdrawn in August 2004. It is not applicable to Tricon v10 systems,

only Tricon v9 systems.

IEC 61511, Parts 13

The IEC 61511 standard, Functional Safety: Safety Instrumented Systems for the ProcessIndustry 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 isintended for SIS designers, integrators, and users in the process-control industry.

Application-Specific Standards

EN 50156

EN 50156 Electrical equipment for furnaces and ancillary equipment outlines the Europeanrequirements for burner management applications.

EN 54, Part 2

EN 54, Part 2, Components of Automatic Fire Detection System: Control and IndicatingEquipment outlines the European requirements for fire detection systems.

NFPA 72

NFPA 72, National Fire Alarm Code outlines the United States requirements for fire alarmsystems.


24/116



NFPA 85

NFPA 85, Boiler and Combustion Systems Hazards Code, outlines the United Statesrequirements for operations using single burner boilers and multiple burner boilers.

CSA C22.2 NO 199CSA C22.2 NO 199, Combustion Safety Controls and Solid-State Igniters for Gas and Oil-Burning Equipment, outlines the Canadian requirements for burner managementapplications.


25/116


2Application Guidelines

Overview 16

TV Rheinland Certification 16

General Guidelines 17

Guidelines for Tricon Controllers 19


26/116

16 Chapter 2 Application Guidelines


OverviewThis chapter provides information about the industry-standard guidelines applicable to safetyapplications. These guidelines include those that apply to all safety systems, as well as those thatapply only to specific industries, such as burner management or fire and gas systems.

Note The guidelines in this chapter do not apply to nuclear 1E applications. For Tricon v9.xsystems used in nuclear 1E applications, see the Equipment Qualification Summary Reportfor Tricon v9 systems, Document Number 7286-545. For Tricon v10.x systems used innuclear 1E applications, see the Equipment Qualification Summary Reportfor Tricon v10systems, Document Number 9600164-545. Contact the Invensys Global CustomerSupport (GCS) Center center to obtain these documents.

Guidelines that apply specifically to the Tricon controller, including SIL3/AK5 and AK6guidelines, are also provided. Project change control guidelines and maintenance overrideconsiderations can be found at the end of this chapter.

Note AK classes do not apply to Tricon v10 systems, they apply only to Tricon v9 systems

because DIN V 19250 and DIN V VDE 0801 were discontinued in August 2004.Be sure to thoroughly read and understand these guidelines beforeyou write your safetyapplication and procedures.

TV Rheinland CertificationWhen used as a PES in an SIS, the Tricon v9 controller has been certified by TV RheinlandIndustrie Service GmbH to meet the requirements of DIN 19250 AK5-AK6 and IEC 61508 SIL3.

When used as a PES in an SIS, the Tricon v10 controller has been certified by TV Rheinland

Industrie Service GmbH to meet the requirements of IEC 61508 SIL3.Note DIN V 19250 was withdrawn in August 2004. It is not applicable to Tricon v10 systems,

only Tricon v9 systems.

Tristation 1131 software has been reviewed and evaluated as part of the functional safetyassessment and certification of the Tricon system according to IEC 61508. Based on the review,and evaluation during certification, TV Rheinland Industrie Service GmbH deems theTriStation 1131 software suitable as a development and deployment tool for SIL3 safety andcritical control applications as defined by IEC 61508 and IEC 61511, when it is used inaccordance with Triconex user documentation, which includes the Safety ConsiderationsGuide.

If these standards apply to your application, compliance with the guidelines described in thischapter is highly recommended.


27/116

General Guidelines 17


General GuidelinesThis 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

These general guidelines apply to all user-written safety applications and procedures:

A design-change review, code-change review, and functional testing are recommendedto verify the correct design and operation.

After a safety system is commissioned, no changes to the system software (operatingsystem, I/O drivers, diagnostics, etc.) are allowed without type approval and re-commissioning. Any changes to the application or the control application should bemade under strict change-control procedures. (For more information on change-controlprocedures, see Project Change and Control on page 26.) All changes should bethoroughly reviewed, audited, and approved by a safety change control committee orgroup. After an approved change is made, it should be archived.

In addition to printed documentation of the application, two copies of the applicationshould be archived on an electronic medium that is write-protected to avoid accidentalchanges.

Under certain conditions, a PES may be run in a mode that allows an external computer

or operator station to write to system attributes. This is normally done by means of acommunication link. The following guidelines apply to writes of this type:

The communication link should use Modbus or other approved protocols with CRCchecks.

The communication link should not be allowed to write directly to output points.

The application must check the value (of each variable written) for a valid range orlimit before its use.

For information on the potential impacts of writes to safety-related variables thatresult in disabling diagnostics such as Output Voter Diagnostics, see ModuleDiagnostics on page 39.

PID and other control algorithms should not be used for safety-related functions. Eachcontrol function should be checked to verify that it does not provide a safety-relatedfunction.

Pointers should not be used for safety-related functions. For TriStation 1131applications, this includes the use of VAR_IN_OUT variables.

An SIS PES should be wired and grounded according to the procedures defined by themanufacturer.


28/116



Emergency Shutdown Systems

The safe state of the plant is a de-energized or low (0) state.

All power supplies should be monitored for proper operation.

Burner Management Systems

The safe state of the plant is a de-energized or low (0) state.

When a safety system is required to conform to the EN 50156 standard for electrical equipmentfor furnaces, PES throughput time should ensure that a safe shutdown can be performed withinone second after a problem in the process is detected.

Fire and Gas Systems

Fire and gas applications 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 detectand 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 suppliesthat are required to activate critical outputs and read safety-critical inputs should beredundant. All power supplies should be monitored for proper operation.

De-energized outputs may be used for normal operation. To initiate action to mitigate aproblem, the outputs are energized. This type of system shall monitor the criticaloutput circuits to ensure that they are properly connected to the end devices.


29/116



Guidelines for Tricon ControllersThe following topics relate to industry guidelines that are specific to Tricon controllers whenused as a PES in an SIS:

Safety-critical modules (page 19)

Safe shutdown (page 20)

Programming lockout alarm

Remote access alarm

Scan time and response time alarm (page 20)

Disabled points alarm (page 20)

Disabled output voters (page 20)

Download all (page 20)

Use of Peer-to-Peer functions (page 20)

Modbus master functions (page 20)

SIL3/AK5 guidelines (page 23)

SIL3/AK5 fire and gas guidelines (page 24)

AK6 guidelines (page 24)

AK6 fire and gas guidelines (page 26)

Project change and control (page 26)

Safety-Critical Modules

It is recommended that only the following modules be used for safety-critical applications:

Main Processor Modules, all models

Communication Modules (only when using protocols defined for safety-criticalapplications)

Digital Input Modules, all models

Digital Output Modules, all models

Analog Input Modules, all models

Analog Output Module, Model #3805E only

Pulse Input Module

Pulse Totalizer Input Module

The Relay Output Module is recommended for non-safety-critical points only.


30/116


31/116



If new data is not received within the time-out period (equal to half of the processing-tolerancetime), the application on the receiving node should be able to determine the action to take. Theactions 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 determinewhether there is a network problem that requires operator intervention.

The specific actions that an application should take depend on the unique safety requirementsof your particular process. The following sections summarize actions typically required by Peer-to-Peer send and receive functions.

Note Due to a lack of information on the reliability and safety of switched or public networks,Invensys recommends that switched or public networks notbe used for safety-criticalPeer-to-Peer communication between Tricon systems.

Sending NodeActions typically required in the logic of the sending application are:

The sending node must set the SENDFLG parameter in the send call to true (1) so thatthe sending node sends new data as soon as the acknowledgment for the last data isreceived from the receiving node.

The SEND function block (TR_USEND) must include a diagnostic integer variable thatis incremented with each new send initiation so that the receiving node can check thisvariable for changes every time it receives new data. This new variable should have arange of 1 to 65,565 where the value 1 is sent with the first sample of data. When thisvariable 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 thecommunication path is not triplicated like the I/O system.

The number of SEND functions in an application must be less than or equal to fivebecause the controller only initiates five SEND functions per scan. To send data as fastas possible, the SEND function must be initiated as soon as the acknowledgment for thelast data is received from the receiving node.

The sending application must monitor the status of the RECEIVE (TR_URCV) andTR_PORT_STATUS functions to determine whether there is a network problem thatrequires operator intervention.

Receiving NodeActions typically required in the logic of the receiving application are:

To transfer safety-critical data, the basic rule is that the receiving node must receive atleast one sample of new data within the maximum time-out limit. If this does nothappen, the application for the receiving node must take one or more of the followingactions, depending on requirements:

Use the last data received for safety-related decisions.


32/116



Use default values for safety-related decisions in the application.

Check the status of the TR_URCV and TR_PORT_STATUS functions to see whetherthere is a network problem that requires operator intervention.

The receiving node must monitor the diagnostic integer variable every time it receivesnew data to determine whether this variable has changed from last time.

The receiving program must monitor the status of the TR_URCV andTR_PORT_STATUS functions to determine if there is a network problem that requiresoperator intervention.

For information on data transfer time and examples of how to use Peer-to-Peer functions totransfer safety-critical data, see Appendix A, Triconex Peer-to-Peer Communication.

Peer-to-Peer Black Channel

The Tricon controller uses an end-to-end check (SEND node to RECEIVE node) for Peer-to-Peercommunication, and as such does not make any assumptions about the network topology or

hardware used. In other words, the Tricon controller considers the network and the associatedhardware and software as a black channel, as shown in the following diagram.

Figure 6 Tricon Controller Peer-to-Peer Black Channel

The SEND node prepares and sends a Peer-to-Peer message with the following items:

A receive node number

Send and receive context

Number and types of data

A 32-bit CRC for the message.The RECEIVE node checks the message for

The correct CRC

The correct receive node number

The correct send and receive context

The correct data type and number of data items.

Send Node

Communication

Module

Black Channel

Receive Node

Tricon MP

Tricon MP

Tricon MP

Tricon MP

Tricon MP

Tricon MPCommunication

Module

Switch, Hub,

etc.

802.3

cable

802.3

cableCommunication

Bus

CommunicationBus

CommunicationBus


33/116



If all parts of the messageincluding the CRCare verified, the Main Processor provides thedata to the application. If there is a problem in the black channel, the RECEIVE node will eithernot receive the message, or will receive a corrupted message that will be rejected. In this way,the integrity of the message is independent from the communication channel and thecommunication equipment used in the channel; for example, routers, hubs, switches, orsatellites.

The RECEIVE node application receives Peer-to-Peer data only if the integrity of the Peer-to-Peer message has been validated.

SIL3/AK5 Guidelines

For Tricon v9 and v10 SIL3, or Tricon v9 AK5 applications, these guidelines should be followed

If non-approved modules are used, the inputs and outputs should be checked to verifythat they do not affect safety-critical functions of the controller.

Three modes control write operations from external hosts:

Remote ModeWhen the keyswitch setting is REMOTE, external hosts, such as aModbus Master or DCS, can write to aliased variables in the controller. When false,writes are prohibited except for the use of gated access functions in RUN mode.

Program ModeWhen the keyswitch setting is PROGRAM, the TriStation 1131software can make program changes, including operations that modify thebehavior of the currently running application. For example, Download All,Download Change, declaring variables, enabling/disabling variables, changingvalues of variables and scan time, etc.

Run ModeWhen the keyswitch setting is RUN, external hosts, such as a ModbusMaster or DCS, can write to aliased variables in the controller onlyby theapplication calling gated access functions that allow external writes during adesignated window of time. Once the Writes have been performed and confirmed,the writing window should be closed using gated access functionality and closureof the writing access should be confirmed. For more information, see thedescriptions of the GATENBand GATDISfunction blocks in Appendix C.

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 thecontroller from external hosts should be prohibited. If remote mode or program modebecomes true, the application program should include the following safeguards:

When remote mode is true, the application should turn on an alarm. For example, ifusing the TR_SHUTDOWN function block, the ALARM_REMOTE_ACCESS

output could be used. Verify that aliased variables adhere to the guidelinesdescribed in Maintenance Overrides on page 27.

When program mode is true, the application should turn on an alarm. For example,if using the TR_SHUTDOWN function block, theALARM_PROGRAMMING_PERMITTED output could be used.

Wiring and grounding procedures outlined in the Planning and Installation Guide forTricon v9v10 Systemsshould be followed.


34/116



Maintenance instructions outlined in thePlanning and Installation Guide for Tricon v9v10 Systemsshould be followed.

The operating time restrictions in this table should be followed.

The GATENB function allows external hosts to write to selected aliased variables evenwhen the remote mode is false. A network using the GATENB function should bethoroughly validated to ensure that only the intended aliased variable range is used.

Peer-to-Peer communication must be programmed according to the recommendationsin Appendix A, Triconex Peer-to-Peer Communication.

Note All Tricon logic solver faults can be repaired online without further degradation of thesystem and should be performed before a second fault occurrence to maintain thehighest availability of the system. The highly effective means of modular insertion andreplacement of faulted Tricon system components is transparent to the operation of thesystem and the ease of replacement mitigates the risk of systematic and human inducedfailure as defined by IEC 61508. It is highly recommended that a faulted component bereplaced within industry accepted Mean-Time-To-Repair (MTTR) periods.

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. TheTriconex library function LINEMNTR should be used to simplify programdevelopment.

A controller should be powered by two independent sources.

If outputs are normally de-energized, a supervised digital output module should beused to verify proper connection to the final control element and to check the load andthe wiring for potential shorts.

If Tricon controller operation is degraded to dual mode or single mode, repairs shouldbe timely. To ensure maximum availability, limits for maximum time in degradedmode should not be imposed.

AK6 Guidelines

For Tricon v9 system AK6 applications, these guidelines should be followed:

DIN V 19250 was discontinued in August 2004, so it applies only to Tricon v9 systems.According to DIN V 19250, AK6 applications that require continued operation afterdetecting an output failure must have a secondary means of operating the output. Asecondary means may be an external group relay or a single point on an independent

Tricon Controller

Operating Mode

SIL 1

Operating Time

SIL 2

Operating Time

SIL 3

Operating TimeTMR Mode Continuous Continuous Continuous

Dual Mode Continuous Continuous 3,000 hours

Single Mode Continuous 1,500 hours 150 hours


35/116



output module that controls a group of outputs. If a relay is used, it should be checkedat least every six months, manually or automatically.

If non-approved modules are used, the inputs and outputs should be checked to verifythat they do not affect safety-critical functions of the controller.

Three modes control write operations from external hosts:

Remote ModeWhen the keyswitch setting is REMOTE, external hosts, such as aModbus Master or DCS, can write to aliased variables in the controller. When false,writes are prohibited.

Program ModeWhen the keyswitch setting is PROGRAM, the TriStation 1131software can make program changes, including operations that modify thebehavior of the currently running application. For example, Download All,Download Change, declaring variables, enabling/disabling variables, changingvalues of variables and scan time, etc.

Run ModeWhen the keyswitch setting is RUN, external hosts, such as a ModbusMaster or DCS, can write to aliased variables in the controller onlyby the

application calling gated access functions that allow external writes during adesignated window of time. Once the Writes have been performed and confirmed,the writing window should be closed using gated access functionality and closureof the writing access should be confirmed. For more information, see thedescriptions of the GATENBand GATDISfunction blocks in Appendix C.

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 thecontroller from external hosts should be prohibited. If remote mode or program modebecomes true, the application program should include the following safeguards:

When remote mode is true, the application should turn on an alarm. For example, ifusing the TR_SHUTDOWN function block, the ALARM_REMOTE_ACCESS

output could be used. Verify that aliased variables adhere to the guidelinesdescribed in Maintenance Overrides on page 27.

When program mode is true, the application should turn on an alarm. For example,if using the TR_SHUTDOWN function block, theALARM_PROGRAMMING_PERMITTED output could be used.

Wiring and grounding procedures outlined in the Planning and Installation Guide forTricon v9v10 Systemsshould be followed.

Maintenance instructions outlined in thePlanning and Installation Guide for Tricon v9v10 Systemsshould be followed.

If Tricon controller operation is degraded to dual mode, continued operation without

repair should be limited to 1500 hours (two months). If Tricon controller operation is degraded to single mode, continued operation without

repair should be limited to one hour.

The GATENB function allows external hosts to write to selected aliased variables evenwhen the remote mode is false. A network using the GATENB function should bethoroughly validated to ensure that only the intended aliased variable range is used.

Peer-to-Peer communication must be programmed according to the recommendationsin Appendix A, Triconex Peer-to-Peer Communication.


36/116



Additional Fire and Gas Guidelines

Analog input cards with current loop terminations should be used to read digitalinputs. Opens and shorts in the wiring to the field devices should be detectable. TheTriconex library function, LINEMNTR, should be used to simplify programdevelopment.

A controller should be powered by two independent sources.

If outputs are normally de-energized, a supervised digital output module should beused to verify proper connection to the final control element and to check the load andthe wiring for potential shorts.

If Tricon controller operation is degraded to dual mode or single mode, repairs shouldbe timely. To ensure maximum availability, limits for maximum time in degradedmode should not be imposed.

Periodic Offline Test Interval Guidelines

A safety instrumented function (SIF) may be tested periodically to satisfy the requirements forthe specified safety integrity level (SIL). This period is called the periodic offline test interval.

Project Change and Control

A change to a project, however minor, should comply with the guidelines of your organizationsSafety Change Control Committee (SCCC).

Change Procedure

1 Generate a change request defining all changes and the reasons for the changes, then

obtain approval for the changes from the SCCC.2 Develop a specification for the 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.

4 To verify that the configuration in the controller matches the last downloadedconfiguration, use the Verify Last Download to the Controller command on theController Panel. For details, see the TriStation 1131 Developers Guide .

5 Compare the configuration in your project with the configuration that was lastdownloaded to the controller by printing the Compare Project to Last Download report

from the Controller Panel. For details, see the TriStation 1131 Developers Guide .6 Print all logic elements and verify that the changes to networks within each element do

not affect other sections of the application.

7 Test the changes according to the test specification using the Emulator Panel. For details,see the TriStation 1131 Developers Guide .

8 Write a test report.

9 Review and audit all changes and test results with the SCCC.


37/116



10 When approved by the SCCC, download the changes to the controller.

You may make minor changes online only if the changes are absolutely necessaryand are tested thoroughly.

To enable a Download Changecommand, select the Enable Programming andControl option in theSet Programming Mode dialog box on the Controller Panel if

it is not already selected.Note Changing the operating mode to PROGRAM generates an alarm to remind the operator

to return the operating mode to RUN as soon as possible after the Download Change.For more information, see Programming Permitted Alarm on page 60.

11 Save the downloaded project in the TriStation 1131 software and back up the project.

12 Archive two copies of the project file and all associated documentation.

Maintenance Overrides

Three methods can be used to check safety-critical devices connected to controllers: Special switches are connected to the inputs on a controller that deactivate the actuators

and sensors undergoing maintenance. The maintenance condition is handled in thelogic of the control application.

Sensors and actuators are electrically disconnected from a controller and manuallychecked using special measures.

Communication to a controller activates the maintenance override condition. Thismethod is useful when space is limited; the maintenance console should be integratedwith the operator display.

TV recommends that the TriStation 1131 workstation used for programming is not also used

for maintenance.

Using Triconex System Communication Capabilities

For maintenance overrides, two options for connection are available:

DCS connection using an approved protocol.

TriStation 1131 PC connection, which requires additional, industry-standard safetymeasures in a controller to prevent downloading a program change duringmaintenance intervals. For more information, see Alarm Usage on page 60.


38/116



Table 3 describes the design requirements for handling maintenance overrides when usingTricon system communication capabilities.

Table 3 Design Requirements for Maintenance Override Handling

Design Requirements

Responsible Person

DCS TriStation 1131Software

Control program logic and the controllerconfiguration determine whether the desiredsignal can be overridden.

Project Engineer,Commissioner


Control program logic and/or systemconfiguration specify whether simultaneousoverriding in independent parts of the applicationis acceptable.

Project Engineer Project Engineer,Type Approval

Controller activates the override. The operatorshould confirm the override condition.

Operator,Maintenance

Engineer

MaintenanceEngineer,

Type ApprovalDirect overrides on inputs and outputs are notallowed, but should be checked and implementedinrelation to the application. Multiple overrides in acontroller are allowed as long as only one overrideapplies to each safety-critical group. The controlleralarm should not be overridden.

Project Engineer Project Engineer,Type Approval

DCS warns the operator about an overridecondition. The operator continues to receivewarnings until the override is removed.


N/A

A second way to remove the maintenance override

condition should be available.

Project Engineer

If urgent, a maintenance engineer may remove theoverride using a hard-wired switch.

MaintenanceEngineer,Type Approval

During an override, proper operating measuresshould be implemented. The time span foroverriding should be limited to one shift (typicallyno longer than eight hours). A maintenanceoverride switch (MOS) light on the operatorconsole should be provided (one per controller orprocess unit).

Project Engineer,Commissioner,DCS, TriStation1131 software


39/116



Table 4 describes the operating requirements for handling maintenance overrides when usingTricon system communication capabilities.

Additional Recommendations

These procedures are recommended in addition to the recommendations described in the tableson page 28and page 29:

A DCS program should regularly verify that no discrepancies exist between theoverride command signals issued by a DCS and override-activated signals received bya DCS from a PES. This figure shows the procedure:

Use of the maintenance override capability should be documented in a DCS orTriStation 1131 log. The documentation should include:

Begin- and end-time stamps of the maintenance override.

Table 4 Operating Requirements for Maintenance Override Handling

Operating Requirements

Responsible Person

DCS TriStation 1131Software

Maintenance overrides are enabled for an entirecontroller or for a subsystem (process unit).

Operator,MaintenanceEngineer

MaintenanceEngineer, TypeApproval

Controller activates an override. The operatorshould confirm the override condition.

Operator,MaintenanceEngineer

MaintenanceEngineer, TypeApproval

Controller removes an override. Operator,MaintenanceEngineer

MaintenanceEngineer

Safeguarding

ApplicationProgram

Controller

Sensors Actuators

OperatorWarning

Distributed

Control System

Inputs

Engineering

Workstation

Maintenance

Override Handling(Application Program)

Hard-Wired

Switch

Safety-Instrumented System


40/116



Identification of the maintenance engineer or operator who activates a maintenanceoverride. 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 overrideshould occur after a warning to the operator.

For more information about maintenance override operation, please see the TV website at http://www.tuv-fs.com/m_o202.pdf.

Safety System Boundary

The boundary of the safety system includes the External Termination Panels (ETPs) and

interconnecting cables. Triconex safety systems must be used with approved ETPs and cablesonly. The use of unapproved, unauthorized cables and/or ETPs compromises the TV safetycertification and potentially the ability of the logic solver to respond to safety demands. Falsetrips resulting from the use of unapproved components can cause end-user economic loss.

Background

IEC 61508 and IEC 61511 define a programmable electronic Safety Instrumented System (SIS) asconsisting of sensors, logic solvers, and final control elements, as shown in this figure.

Figure 7 Simplified SIS

Together, these elements implement Safety Instrumented Functions (SIF) of the target Safety

Integrity Level (SIL). In order to implement a safety-certified SIF, the system designer mustchoose safety-certified loop elements, including sensors, final elements, logic solvers, and otherinterconnecting components.

In addition to the components shown in Figure 7, a typical SIS consists of components such ascables and external termination panels. These components are used to connect the sensors andfinal elements to the logic solvers. Figure 8shows the SIS including these components.

CAUTIONWhen using fanned-out interface cables or third-party ETPssuch asthose from P&F or MTLplease consult the Invensys Global CustomerSupport (GCS) Center for the safety-boundary impact of using suchcables or ETPs.

SensorsLogic

Solver

Final

Elements
http://www.tuv-fs.com/m_o202.pdfhttp://-/?-http://-/?-http://-/?-http://-/?-http://www.tuv-fs.com/m_o202.pdf


41/116



Approved ETPs and interconnecting cables are listed in the Planning and Installation Guide forTricon v9v10 Systemsand the Technical Product Guide for Tricon v9v10 Systems, which areavailable on the Invensys Global Customer Support (GCS) Center website.

Design Control, Configuration Management, Supply Chain Management, and QualityAssurance for Triconex ETPs and cable assemblies are controlled by Invensys in Irvine,

California (the Triconex factory). Sourcing of approved ETPs and interconnecting cables is alsocontrolled by Invensys in Irvine.

Certifications

TV approves the use of Triconex ETPs and interconnecting cables with the TriconSafety Logic Solver.

TV certifies the use of the Tricon Safety Logic Solver in SIL 3 applications with theTV approved ETPs and interconnecting cables.

Triconex ETPs are certified for electrical safety in full compliance with internationalstandards by CSA. They are qualified for general use in North America and other

jurisdictions requiring compliance with these standards, as well as the European CEmark as per the Low Voltage Directive.

Triconex ETPs and interconnecting cables comply with the applicable IEC EMCstandard (IEC 61326-3-1,2,), which includes the European CE mark per the EMCdirective.

Triconex ETPs that are approved for hazardous locations also comply with NorthAmerica Class1 Div2 (C1D2) and Zone 2 as per the European ATEX directive.

Thus, the boundary of the safety system (Tricon Safety Logic Solver) extends up to the ETPs,including the interconnecting cables, as shown in Figure 2 below.

Figure 8 Safety System Boundary

Final

Elements

ExternalTermination

Panel

LogicSolver

(Tricon)

ExternalTermination

Panel

Approved cable connectsTricon to ETP (for outputs)

Boundary ofTV-CertifiedTricon Safety System

Approved external

termination panel

Sensors

End-user

installedfield wiring

End-user

installed

field wiring

Approved cable

connectsTricon to ETP

Approved external

termination panel


42/116



Use of Unapproved Components

The use of unapproved cables and unapproved ETPs can negatively impact the safety integrityof the safety function and the compliance with the applicable safety standards. This causes aliability issue in the event of a plant incident.

The use of such unapproved components can also impact the availability of the safety systemby causing false trips in the plant. This results in unnecessary economic loss for the plant.


43/116


3Fault Management

Overview 34

System Diagnostics 35

Types of Faults 36

Operating Modes 37

Module Diagnostics 39


44/116

34 Chapter 3 Fault Management


OverviewThe Tricon controller has been designed from its inception with self-diagnostics as a primaryfeature. Triple-Modular Redundant (TMR) architecture (shown in Figure 9) ensures faulttolerance 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 theinput modules reads the process data and passes that information to its respective mainprocessor. The three Main Processor (MP) modules communicate with each other using aproprietary, high-speed bus system called the TriBus.

Extensive diagnostics on each channel, module, and functional circuit quickly detect and reportoperational faults by means of indicators or alarms. This fault information is available to anapplication. It is critical that an application properly manage fault information to avoid anunnecessary shutdown of a process or plant.

This section discusses the methods for properly handling faults.

Figure 9 Typical Tricon System

InputChannel

A

InputChannel

B

InputChannel

C

OutputChannel

A

OutputChannel

B

OutputChannel

C

MainProcessor

C

MainProcessor

B

I/O Bus

I/O Bus

I/O Bus

TriBus

TriBus

TriBus

Voter

MainProcessor

A

InputTermination

OutputTermination

Auto Spare Auto Spare


45/116

System Diagnostics 35


System DiagnosticsTo improve system availability and safety, a safety system must be able to detect failures andprovide the means for managing failures properly. The controllers diagnostics may becategorized as:

Reference diagnostics: Comparing an operating value to a predetermined reference,such as a system specification.

Comparison diagnostics: Comparing one component to another, such as oneindependent channel with two other independent channels.

Field device diagnostics: Diagnostics are extended to a systems field devices andwiring.


46/116



Types of FaultsA controller is subject to external faults and internal faults, which are reported by:

The status indicators on a modules front panels

The Triconex Enhanced Diagnostic Monitor System attributes on the Controller Panel in the TriStation 1131 software

External Faults

A controller may experience the following types of external faults:

Logic power faults

Field power faults

Load or fuse faults

When an external fault occurs, the controller asserts an alarm. How the alarm is communicatedis module-specific. In some cases, a yellow alarm indicator is provided on the module. Forexample, a Load/Fuse alarm is provided on digital output modules. In most cases, the Systemalarm is asserted, and the System alarm indicators on the main chassis power modules are lit.The Triconex Enhanced Diagnostic Monitor identifies the faulting module by displaying a redframe around it. For instructions on responding to specific alarm conditions, see the Planningand Installation Guide for Tricon v9v10 Systems.

Internal Faults

Internal faults are usually isolated to one of the controllers three channels (A, B, or C). When aninternal fault occurs on one of the three channels, the remaining two healthy channels maintainfull control. Depending on the type of fault, the controller either remains in TMR mode ordegrades to dual mode for the system component that is affected by the fault. For moreinformation about operating modes, see Operating Modes on page 37.

When an internal fault occurs, the controller lights the red Fault indicator on the faultingmodule and the System alarm on the main chassis power modules to alert the operator toreplace the faulting module.


47/116

Operating Modes 37


Operating ModesEach input or output point is considered to operate in one of three modes:

The current mode indicates the number of channels controlling a point; in other words, thenumber of channels controlling the output or having confidence in the input. For safety reasons,system modeis defined as the mode of the point controlled by the fewest number of channels.

System variables summarize the status of input and output points. When a safety-critical pointis in dual or single mode, the application may need to shut down the controlled process withina pre-determined time.

You can further simplify and customize shutdown logic by using special function blocksprovided by Invensys. By considering only faults in safety-critical modules, system availabilitycan be improved. Using shutdown function blocks is essential to preventing potential false trips

in dual mode and to guaranteeing fail-safe operation in single mode. For more information, seeAppendix C, Safety-Critical Function Blocks.

While operating in TMR mode, during each scan the process is protected from the effect of asingle safety-critical system fault. The system can also tolerate multiple faults and continue tooperate correctly unless the combined effects of multiple faults affects the same point onmultiple 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 therecommended maximum operating period of 3000 hours in dual mode (SIL3/AK5-6) and 150hours in single mode (SIL3/AK5-6) should be observed.

A safety-critical faultis defined as a fault that prevents the system from executing the safetyfunction on demand. Safety-critical faults include:

Inability to detect a change of state on a digital input point

Inability to detect a change of value on an analog input point

Inability to change the state of a digital output point

Inability of the system to:

Read each input point

Vote the correct value of each input

Execute the control program Determine the state of each output point correctly

Also, during each execution of the control application, each channel independently verifies the

Integrity of the data path between the MPs

Proper voting of all input values

Proper evaluation of the control application

Triple Modular Redundant (TMR) Dual Mode

Single Mode


48/116



Calculated value of each output point


49/116

Module Diagnostics 39


Module DiagnosticsEach system component detects and reports operational faults.

Digital Input (DI) Modules

Digital input module points typically use a combination of comparison and force-to-valuediagnostics (FVD). Under system control, each channel is independently compared against themeasured value of all channels. If a mismatch is found, an alarm is set. Using the integral FVDcapability, each point can be independently verified for its ability to accurately detect atransition to the opposite state. A channel that has detected a fault on a digital input point votesthat point to be de-energized. These diagnostics are executed independently by each channel,thus assuring nearly 100 percent fault coverage and fail-safe operation under all single-faultscenarios, and most common multiple-fault scenarios.

Digital Input Module Alarms

Digital input module faults are reported to the control application. These alarms can be used toincrease availability during specific multiple fault conditions. Loss of logic power is reported tothe control application.

Digital Output (DO) Modules

Digital output modules use output voter diagnostics (OVD). Under system control, each outputpoint is commanded sequentially to both the energized and de-energized states. The forcedstate is maintained until the value is detected by the system o