Safety Considerations Guide For Tricon Systems

Tricon™ v9–v11 Systems
Safety Considerations
Guide
Assembly Number 9700097-013

April 2016
Information in this document is subject to change without notice. Companies, names and data used in
examples herein are fictitious unless otherwise noted. No part of this document may be reproduced or
transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express
written permission of Invensys Systems, Inc., now part of Schneider Electric.
© 2006-2016 Invensys Systems, Inc. All rights reserved.
Schneider Electric, Triconex, Tricon, Trident, and TriStation are trademarks of Schneider Electric SE, its
subsidiaries and affiliates. All other brands may be trademarks of their respective owners.
Document Number 9720097-013, Rev 1

Printed in the United States of America.
Contents
Preface vii
Summary of Sections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii
Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii
Abbreviations Used. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Product and Training Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
We Welcome Your Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Chapter 1 Safety Concepts 1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Protection Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
SIS Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
SIL Factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Hazard and Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Safety Integrity Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Safety Life Cycle Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Safety Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
General Safety Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Application-Specific Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Chapter 2 Application Guidelines 15

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
TÜV Rheinland Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
All Safety Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Emergency Shutdown Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Burner Management Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Fire and Gas Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Guidelines for Tricon Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Safety-Critical Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Safety-Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Adding New Chassis while the Controller is Online . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Upgrading Modules While the Controller is Online . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Response Time and Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Disabled Points Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Disabled Output Voter Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Download All at Completion of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Safety Considerations Guide for Tricon v9–v11 Systems

iv Contents
Modbus Master Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Triconex Peer-to-Peer Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
SIL Capability 3/AK5 Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
AK6 Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Proof-Test Interval Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Project Change and Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Maintenance Overrides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Safety System Boundary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Useful Lifetime of the Safety Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Chapter 3 Fault Management 39

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
System Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Types of Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
External Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Internal Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Operating Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Module Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Digital Input (DI) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Digital Output (DO) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Analog Input (AI) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Analog Output (AO) Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Pulse Input (PI) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Relay Output (RO) Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Input/Output Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Main Processor and TriBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Peer-to-Peer Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
External Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Chapter 4 Application Development 49

Development Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Invensys Product Alert Notices (PANs). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Safety and Control Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
VAR_IN_OUT Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Array Index Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Infinite Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Important TriStation 1131 Software Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Download Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Verify Last Download to the Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Compare to Last Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Setting Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Scan Surplus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Sample Safety-Shutdown Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Contents v
When All I/O are Modules Safety-Critical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

When Some I/O Modules are Safety-Critical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Defining Function Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Partitioned Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Alarm Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Programming Permitted Alarm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Remote Access Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Response Time and Scan Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Disabled Points Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Appendix A Triconex Peer-to-Peer Communication 67

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Data Transfer Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Estimating Memory for Peer-to-Peer Data Transfer Time. . . . . . . . . . . . . . . . . . . . . . 70
Estimating the Data Transfer Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Examples of Peer-to-Peer Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Example 1: Fast Send to One Triconex Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Example 2: Sending Data Every Second to One Node . . . . . . . . . . . . . . . . . . . . . . . . . 73
Example 3: Controlled Use of Send/Receive Function Blocks . . . . . . . . . . . . . . . . . . 73
Example 4: Using Send/Receive Function Blocks for Safety-Critical Data . . . . . . . 74
Appendix B HART Communication 77

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
HART Position Paper from TÜV Rheinland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Triconex 4850 HART Multiplexer FMEA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Analysis Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Appendix C Safety-Critical Function Blocks 89

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
GATDIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
GATENB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
TR_CRITICAL_IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
TR_SHUTDOWN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
TR_VOTE_MODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Index 111

vi Contents

Preface
This guide provides information about safety concepts and standards that apply to the Tricon™
controller. This document replaces all previous versions of the Safety Considerations Guide for
Tricon Systems.
Summary of Sections
• Chapter 1, Safety Concepts—Describes safety issues, safety standards, and
implementation of safety measures.
• Chapter 2, Application Guidelines—Provides information on industry guidelines and
recommendations.
• Chapter 3, Fault Management—Discusses fault tolerance and fault detection.
• Chapter 4, Application Development—Discusses methods for developing applications
properly to avoid application faults.
• Appendix A, Triconex Peer-to-Peer Communication—Provides examples of using
Triconex® Peer-to-Peer function blocks to transfer data between applications.
• Appendix B, HART Communication—contains a position paper from TÜV Rheinland
on using the HART™ communication protocol in safety-related applications within
Safety Instrumented Systems (SIS).
• Appendix C, Safety-Critical Function Blocks—Describes the function blocks intended
for use in safety-critical applications and shows their Structured Text code.
Related Documents
• Communication Guide for Tricon v9–v11 Systems
• Field Terminations Guide for Tricon v9–v11 Systems
• Planning and Installation Guide for Tricon v9–v11 Systems
• TriStation 1131 Developer’s Guide
• TriStation 1131 Libraries Reference

viii Chapter
Abbreviations Used
The TriStation™ 1131 Developer’s Workbench is hereafter called TriStation 1131 software.
The following list provides full names for abbreviations of safety terms used in this guide.
BPCS Basic process control system

ESD 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 to
perform IES design function on
demand
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
Product and Training Information

To obtain information about Invensys® products and in-house and on-site training, see the
Invensys web site or contact your regional customer center.
Web Site
http://www.iom.invensys.com

Preface ix
Technical Support
Customers in the U.S. and Canada can obtain technical support from the Global Customer
Support (GCS) center at the numbers below. International customers should contact their
regional support center.
Requests for support are prioritized as follows:
• Emergency requests are given the highest priority
• Requests from participants with a support agreement and customers with purchase
order or charge card authorization are given next priority
• All other requests are handled on a time-available basis
If you require emergency or immediate response and do not have a support agreement, you
may incur a charge. Please have a purchase order or credit card available for billing.
Telephone
Toll-free number 866-746-6477, or
Toll number 508-549-2424 (outside U.S.)
Fax
Toll number 508-549-4999
Web Site
http://support.ips.invensys.com (registration required)

x Chapter
We Welcome Your Comments

To help us improve future versions of Triconex documentation, we want to know about any
corrections, 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:
systemstechpubs@schneider-electric.com
Please keep in mind that this e-mail address is only for documentation feedback. If you have a
technical problem or question, please contact the Global Customer Support (GCS) center. See
Technical Support on page ix for contact information.
Or, you can write to us at:
Attn: Technical Publications - Triconex
Invensys
26561 Rancho Parkway South
Lake Forest, CA 92630
Thank you for your feedback.

1
Safety Concepts
Overview 2
Hazard and Risk Analysis 5
Safety Standards 12
Application-Specific Standards 13

2 Chapter 1 Safety Concepts
Overview
Modern industrial processes tend to be technically complex, involve substantial energies, and
have the potential to inflict serious harm to persons or property during a mishap.
The IEC 61508 standard defines safety as “freedom from unacceptable risk.” In other words,
absolute safety can never be achieved; risk can only be reduced to an acceptable level.
Safety methods to mitigate harm and reduce risk include:
• Changing the process or mechanical design, including plant or equipment layout
• Increasing the mechanical integrity of equipment
• Improving the basic process control system (BPCS)
• Developing additional or more detailed training procedures for operations and
maintenance
• Increasing the testing frequency of critical components
• Using a safety-instrumented system (SIS)
• Installing mitigating equipment to reduce harmful consequences; for example,
explosion walls, foams, impoundments, and pressure relief systems
Another important aspect of reducing risk is security. For guidelines on the security of Tricon
products, see the Planning and Installation Guide for Tricon v9–v11 Systems and the TriStation 1131
Developer’s Guide.
Protection Layers
Methods that provide layers of protection should be:
• Independent
• Verifiable
• Dependable
• Designed for the specific safety risk
This figure shows how layers of protection can be used to reduce unacceptable risk to an
acceptable level. The amount of risk reduction for each layer is dependent on the specific nature
of the safety risk and the impact of the layer on the risk. Economic analysis should be used to
determine the appropriate combination of layers for mitigating safety risks.

Overview 3
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 capability (SIL capability) 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).
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 a safety function at the
time of a process demand. A process demand is defined as the occurrence of a process deviation
that causes a safety function to transition a process to a safe state.
A SIL is the litmus test of acceptable safety function 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.

Hazard and Risk Analysis

In the United States, OSHA Process Safety Management (PSM) and EPA Risk Management
Program (RMP) regulations dictate that a process hazard analysis (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 disruption.
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.
Safety Integrity Levels

This figure shows the relationship of DIN V 19250 classes and SILs (safety integrity levels).
R
I
S 99.999 0.00001 AK 8
K
99.99 0.0001 >10,000 SIL 4 AK 7
R
E AK 6
99.90 0.001 10,000– SIL 3 SIL 3
D 1,000 AK 5
U
C 1,000– AK 4
99.00 0.01 SIL 2 SIL 2
T 100 AK 3
I 100– AK 2
90.00 0.1 SIL 1 SIL 1
O 10 AK 1
N
Percent PFDavg RRF ANSI/ISA IEC DIN V

Availability S84.01 61508 19250
Risk Measures Risk Standards
Figure 2 Standards and Risk Measures
Note DIN V 19250 was withdrawn in August 2004. It is not applicable to Tricon v10 and
Tricon v11 systems, only Tricon v9 systems.

As a required SIL capability 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 capability 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.
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 capability be assigned. The assignment of a SIL capability is a corporate decision based on
risk management and risk tolerance philosophy. Safety regulations require that the assignment
of SIL capabilities 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.
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 probability is an estimate of the likelihood that an expected event will occur. Classified as
high, medium, or low, a risk probability is often based on a company’s or a competitor’s
operating experience.
Several methods of converting HAZOP data into SIL capabilities 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.
Sample Low Demand SIL Calculation

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

99.9999 0.000001
Tricon PES*
R
I 99.999 0.00001
S
K
99.99 0.0001
R
E SIL capability 3 SIS
99.90 0.001
D
U
C 99.00 0.01
T
I
O 90.00 0.1
N
Percent PFD
Availability
Risk Measures
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 Factory
Mutual Research and TÜV 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.
Safety Integrated System
3 Pressure
Transmitters (2oo3) TMR Controller 2 Block Valves
(2oo3) in Series (1oo2)
Sensors
PES/Logic Solver Final Elements
3 Temperature
Transmitters (2oo3)
Figure 4 Simplified Diagram of Key Elements
This table provides simplified equations for calculating the PDFavg for the key elements in an
SIS. Once the PDFavg for each element is known, a SIL can be determined.
Table 1 Simplified Equations for Calculating PFDavg

Variables
Description Equation
(supplied by the manufacturer)
Sensors To calculate PFDavg = (λDU*TI)2 λ = failure rate
PFDavg for + 1/2*β*λDU*TI DU=dangerous, undetected failure rate
sensors (2oo3) TI= test interval in hours
β = common cause factor

Table 1 Simplified Equations for Calculating PFDavg

Variables
Description Equation
(supplied by the manufacturer)
Block To calculate PFDavg = 1/3(λDU*TI)2 λ = failure rate
Valves PFDavg for + 1/2*β*λDU*TI DU=dangerous, undetected failure rate
block valves TI= test interval in hours
(1oo2) in series β = common cause factor
(final elements)
System To calculate System PFDavg =
PFDavg for a Sensors PFDavg +
system Block Valves PFDavg +
Controller PFDavg
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 SIL capability 3 applications.
Table 2 Determining the SIL Using the Equations

β λDU TI PFD Result
Pressure Transmitters (2oo3) .03 2.0E-06 4380 2.1E-04
Temperature 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
Tricon Controller 4380 1.0E-05 0.1E-04
PFDavg for SIF 6.5E-04
For additional information on SIL assignment and SIL verification, visit the Premier Consulting
Services web site at http://www.premier-fs.com.
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:
• Complete a hazard and operability study
• Determine the SIS requirement
• Determine the target SIL capability

START
Establish operation
and maintenance
procedure
Design (Step 5)
conceptual process
Develop safety
requirements
document Pre-start-up
Perform process (Step 1) safety review
hazard analysis assessment
and risk (Step 6)
assessment Perform SIS
conceptual
design and verify SIS start-up
it meets the SRS operation,
Apply non-SIS (Step 2) maintenance,
protection layers to periodic functional
testing
prevent identified (Steps 7 and 8)
hazards or reduce
risk Perform SIS
detail design
(Step 3)
Modify Modify or
SIS decommission
No SIS installation, SIS?
EXIT required? commissioning,
and pre-startup
Yes acceptance test
(Step 4) Decommission
Define target SIL capability
SIS
decommissioning
Conceptual process design (Step 9)
Figure 5 Safety Life Cycle Model
Developing an SIS Using the Safety Life Cycle

1 Develop a safety requirement specification (SRS).
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 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 in
a 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 are
statistically significant.
• Each individual field device shall have its own dedicated wiring to the system I/O.
Using a field bus is not allowed!
• A control valve from the BPCS shall not be used as a single final element for SIL3.
• The operator interface may not be allowed to change the SIS application software.
• Maintenance overrides shall not be used as a part of application software or
operating procedures.
• When online testing is required, test facilities shall be an integral part of the SIS
design.
4 Develop a pre-start-up acceptance test procedure that provides a fully functional test of
the SIS to verify conformance with the SRS.
5 Before startup, establish operational and maintenance procedures to ensure that the SIS
functions comply with the SRS throughout the SIS operational life, including:
• Training
• Documentation
• Operating procedures
• Maintenance program
• Testing and preventive maintenance
• Functional testing
• Documentation of functional testing

6 Before start-up, complete a safety review.

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 (such as OSHA 29 CFR 1910.119)
• Functional testing to detect covert faults that prevent the SIS from operating
according to the SRS
• SIS testing, including sensors, logic solver, and final elements (such as shutdown
valves, motors, etc.)
8 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.

Safety Standards
Over the past several years, there has been rapid movement in many countries to develop
standards and regulations to minimize the impact of industrial accidents on citizens. The
standards described in this section apply to typical applications.
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 (PES) 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.
Note DIN V 19250 and DIN V VDE 0801 were withdrawn in August 2004. They are not
applicable to Tricon v10 and Tricon v11 systems, only Tricon v9 systems.
IEC 61508, Parts 1–7

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 Figure 5 on page 9) to illustrate

Safety Standards 13
that the integrity of an SIS is not limited to device integrity, but is also a function of design,
operation, testing, and maintenance.
The standard includes four SILs that are indexed to a specific probability-to-fail-on-demand
(PFD) (see Figure 2 on page 5). A SIL assignment is based on the required risk reduction as
determined by a PHA.
ANSI/ISA S84.01
ANSI/ISA S84.01-1996 is the United States standard for safety systems in the process industry.
The SIL classes from IEC 61508 are used and the DIN V 19250 relationships are maintained.
ANSI/ISA S84.01-1996 does not include the highest SIL class, SIL 4. The S84 Committee
determined that SIL 4 is applicable for medical and transit systems in which the only layer of
protection is the safety-instrumented layer. In contrast, the process industry can integrate many
layers of protection in the process design. The overall risk reduction from these layers of
protection is equal to or greater than that of other industries.
IEC 61511, Parts 1–3

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.
Application-Specific Standards
EN 50156
EN 50156 “Electrical equipment for furnaces and ancillary equipment” outlines the European
requirements for burner management applications.
EN 54, Part 2
EN 54, Part 2, “Components of Automatic Fire Detection System: Control and Indicating
Equipment” outlines the European requirements for fire detection systems.
NFPA 72
NFPA 72, “National Fire Alarm Code” outlines the United States requirements for fire alarm
systems.

NFPA 85
NFPA 85, “Boiler and Combustion Systems Hazards Code,” outlines the United States
requirements for operations using single burner boilers and multiple burner boilers.
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.

2
Application Guidelines
Overview 16
TÜV Rheinland Certification 16
General Guidelines 17
Guidelines for Tricon Controllers 22

16 Chapter 2 Application Guidelines
Overview
This chapter provides information about the industry-standard guidelines applicable to safety
applications. These guidelines include those that apply to all safety systems, as well as those that
apply only to specific industries, such as burner management or fire and gas systems.
Note The guidelines in this chapter do not apply to nuclear 1E applications. For Tricon v9.x
systems used in nuclear 1E applications, see the Equipment Qualification Summary Report
for Tricon v9 systems, Document Number 7286-545. For Tricon v10.x systems used in
nuclear 1E applications, see the Equipment Qualification Summary Report for Tricon v10
systems, Document Number 9600164-545. Contact the Global Customer Support (GCS)
center to obtain these documents.
Guidelines that apply specifically to the Tricon controller, including SIL capability 3/AK5 and
AK6 guidelines, are also provided. Project change control guidelines and maintenance override
considerations can be found at the end of this chapter.
Note AK classes do not apply to Tricon v10 and Tricon v11 systems, they apply only to Tricon
v9 systems because DIN V 19250 and DIN V VDE 0801 were discontinued in August
2004.
Be sure to thoroughly read and understand these guidelines before you write your safety
application and procedures.
TÜV Rheinland Certification

When used as a PES in an SIS, the Tricon v9 controller has been certified by TÜV Rheinland
Industrie Service GmbH to meet the requirements of DIN 19250 AK5-AK6 and IEC 61508 SIL
capability 3.
When used as a PES in an SIS, the Tricon v10 controller and the Tricon v11 controller have been
certified by TÜV Rheinland Industrie Service GmbH to meet the requirements of IEC 61508 SIL
capability 3.
Tristation 1131 software has been reviewed and evaluated as part of the functional safety
assessment and certification of the Tricon system according to IEC 61508. Based on the review,
and evaluation during certification, TÜV Rheinland Industrie Service GmbH deems the
TriStation 1131 software suitable as a development and deployment tool for SIL capability 3
safety and critical control applications as defined by IEC 61508 and IEC 61511, when it is used
in accordance with Triconex user documentation, which includes the Safety Considerations
Guide.
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

These general guidelines apply to all user-written safety applications and procedures:
• A design-change review, code-change review, and functional testing are recommended
to verify the correct design and operation.
• After a safety system is commissioned, no changes to the system software (operating
system, I/O drivers, diagnostics, etc.) are allowed without type approval and re-
commissioning. Any changes to the application or the control application should be
made under strict change-control procedures. (For more information on change-control
procedures, see Project Change and Control on page 31.) All changes should be
thoroughly reviewed, audited, and approved by a safety change control committee or
group. After an approved change is made, it should be archived.
• In addition to printed documentation of the application, two copies of the application
should be archived on an electronic medium that is write-protected to avoid accidental
changes.
• Under certain conditions, a PES may be run in a mode that allows an external computer
or operator station to write to system attributes. This is normally done by means of a
communication link. The following guidelines apply to writes of this type:
— The communication link should use Modbus or other approved protocols with CRC
checks.
— 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 or
limit before its use.
— For information on the potential impacts of writes to safety-related variables that
result in disabling diagnostics such as Output Voter Diagnostics, see Module
Diagnostics on page 45.
• If the external computer or operator station is certified to a SIL capability according to
IEC 61508, there needs to be a safety protocol to allow safe communication between the
external system and application. The communication link is considered a black channel
(a communication channel without available evidence of design or validation) and it
must be assumed that it can corrupt any communication. The safety protocol will need
to mitigate or protect against the following errors:

— Corruption—Messages may be corrupted due to one or more of the following:

errors within the black channel, errors on the transmission medium, or message
interference.
— Unintended Repetition—An error, fault, or interference causes old un-updated
messages to be repeated at an incorrect point in time.
— Incorrect Sequence—An error, fault, or interference causes the predefined
sequence (for example, natural numbers and time references) associated with
messages from a particular source to be incorrect.
— Loss—An error, fault, or interference causes a message to not be received or not be
acknowledged.
— Unacceptable Delay—Messages may be delayed beyond their permitted arrival
time window due to one or more of the following: errors in the transmission
medium, congested transmission lines, interference, or black channel components
sending messages in such a way that services are delayed or denied (for example:
first in, first outs—FIFOs—in switches, bridges, and routers).
— Insertion—A fault or interference causes a message to be inserted that relates to an
unexpected or unknown source entity.
— Masquerade—A fault or interference causes a message to be inserted that relates to
an apparently valid source entity, resulting in a non-safety-relevant message being
received by a safety-relevant participant, which then incorrectly treats the message
as safety relevant.
— Addressing—A fault or interference causes a safety-relevant message to be sent to
the wrong safety-relevant participant, which then treats the reception of that
message as correct.
• The Modbus and TSAA protocols currently do not have safety measures for the errors
described above. It is up to the system designer to mitigate against these errors in
accordance with the applicable standards of their industry in order to meet the required
SIL capability.
The following table includes several measures commonly used to detect deterministic
errors and failures of a communication system. Each safety measure can provide
protection against one or more errors in the transmission. There is at least one
corresponding safety measure or combination of safety measures for each error.
Safety Measure Description Protects Against

Sequence Number A sequence number is integrated into • Unintended
messages exchanged between message Repetition
source and message sink. It may be • Incorrect Sequence
realized as an additional data field with
a number that changes from one • Loss
message to the next in a predetermined • Insertion
way.


Time Stamp In most cases, the content of a message • Unintended
is only valid at a particular point in Repetition
time.The time stamp may be a time, or • Incorrect Sequence
time and date, included in a message by
the sender. • Unacceptable Delay
Time Expectation During transmission of the message, the Unacceptable Delay

message sink checks whether the delay (required in all cases)
between two consecutively received
messages exceeds a predetermined
value. In this case, an error has to be
assumed.
Connection Messages may have a unique source • Insertion (used only
Authentication and/or destination identifier that for sender
describes the logical address of the identification; only
safety-relevant participant. detects insertion of an
invalid source)
• Masquerade
• Addressing
Feedback Message The message sink returns a feedback • Corruption (effective
message to the source to confirm only if the feedback
reception of the original message. This message includes
feedback message has to be processed original data or
by the safety communication layers. information about the
original data)
• Loss
• Insertion
• Masquerade
Data Integrity The safety-related application process Corruption
Assurance shall not trust the data integrity
assurance methods if they are not
designed from the point of view of
functional safety. Therefore, redundant
data is included in a message to permit
data corruption to be detected by
redundancy checks.


Redundancy with In safety-related Fieldbus applications, • Corruption (only for
Cross-Checking the safety data may be sent twice, within serial busses, and
one or two separate messages, using only comparable with
identical or different integrity measures a high-quality data
independent from the underlying assurance mechanism
Fieldbus. In addition, the transmitted if a calculation can
safety data is cross-checked for validity show that the residual
over the Fieldbus or over a separate error rate reaches the
connection source or sink unit. If a values required when
difference is detected an error has taken two messages are sent
place: through independent
• during transmission receivers)
• in the processing unit of the source • Unintended

Repetition
• in the processing unit of the sink
• Incorrect Sequence
When redundant media are used,
common mode protection using suitable • Loss
measures (for example, diversity and • Insertion
time-skewed transmission) should be
considered.
Different Data If safety-relevant and non-safety- Masquerade
Integrity Assurance relevant data are transmitted via the
Systems same bus, different data integrity
assurance systems or encoding
principles may be used (for example,
different hash functions or different
CRC generator polynomials and
algorithms), to ensure that non-safety-
relevant messages cannot influence any
safety function in a safety-relevant
receiver.
• 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.
• Pointers should not be used for safety-related functions. For TriStation 1131
applications, this includes the use of VAR_IN_OUT variables.
• 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 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 equipment
for furnaces, PES throughput time should ensure that a safe shutdown can be performed within
one 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 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 safety-critical 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 shall monitor the critical
output circuits to ensure that they are properly connected to the end devices.

Guidelines for Tricon Controllers

The following topics relate to industry guidelines that are specific to Tricon controllers when
used as a PES in an SIS:
• Safety-Critical Modules on page 22
• Safety-Shutdown on page 23
• Adding New Chassis while the Controller is Online on page 23
• Upgrading Modules While the Controller is Online on page 24
• Response Time and Scan Time on page 24
• Disabled Points Alarm on page 24
• Disabled Output Voter Diagnostic on page 24
• Download All at Completion of Project on page 25
• Modbus Master Functions on page 25
• Triconex Peer-to-Peer Communication on page 25
• SIL Capability 3/AK5 Guidelines on page 28
• AK6 Guidelines on page 30
• Proof-Test Interval Guidelines on page 31
• Project Change and Control on page 31
• Maintenance Overrides on page 32
• Safety System Boundary on page 35
• Useful Lifetime of the Safety Controller on page 37
Safety-Critical Modules
It is recommended that only the following modules be used for safety-critical applications:
• Main Processor Modules, all models
• Communication Modules (only when using protocols defined for safety-critical
applications)
• Digital Input Modules, all models
• Digital Output Modules, all models
• Analog Input Modules, all models
• Analog Output Module, Model #3805E only
• Pulse Input Module
• Pulse Totalizer Input Module
The Relay Output Module is recommended for non-safety-critical points only.

Safety-Shutdown
A SIL3 safety application should include a network that initiates a safe shutdown of the process
being controlled when a controller operates in a degraded mode for a specified maximum time.
The Triconex Library provides two function blocks to simplify programming a safety-shutdown
application: TR_SHUTDOWN and TR_CRITICAL_IO. To see the Structured Text code for these
function blocks, see Appendix C, Safety-Critical Function Blocks. For more information on
safety-shutdown networks, see Sample Safety-Shutdown Programs on page 56.
Adding New Chassis while the Controller is Online

In Tricon 11.1 and later systems, you can add a new chassis while the controller is online. When
doing this, install the hardware into the chassis in the following order.
Installation Order
1 Install I/O bus cables one at a time.
Before you install each I/O bus cable, ensure there are no system faults.
2 Install the modules one at a time.
Before you install each module, ensure that power is available, field wiring and external
termination panels (ETPs) are properly connected (if applicable), and there are no
system faults. Also, after installing each module, wait for the module to become active
before installing the next module.
See the “Guidelines for Replacing Modules” section in the Planning and Installation Guide for
Tricon v9–v11 Systems for more information.
When adding new RXM Chassis while the controller is online, install the hardware in the
following order.
Installation Order for RXM Chassis

1 Install the Primary RXM Chassis (the RXM Chassis located near the Main Chassis).
2 Install the Primary RXM Module Set.
3 Install I/O bus cables one at a time to connect the Primary RXM Chassis to the Main
Chassis.
Before you install each I/O bus cable, ensure there are no system faults.
4 Install the modules one at a time in the Primary RXM Chassis.
Before you install each module, ensure that power is available, field wiring and external
termination panels (ETPs) are properly connected (if applicable), and there are no
system faults. Also, after installing each module, wait for the module to become active
before installing the next module.
5 Install the RXM Chassis at the remote location.
6 Install the Remote RXM Module Set in the Remote RXM Chassis.

7 Install the fiber-optic cables between the Primary RXM Chassis and the Remote RXM
Chassis one at a time.
After you install each fiber optic cable, make sure there are no system faults before you
install the next fiber-optic cable.
8 Install the modules one at a time in the Remote RXM chassis.
Before you install each module, ensure that power is available, field wiring and ETPs are
properly connected (if applicable), and there are no system faults. Also, after installing
each module, wait for the module to become active before installing the next module.
See the “RXM Chassis Installation” section in the Planning and Installation Guide for Tricon v9–
v11 Systems for more information.
Upgrading Modules While the Controller is Online

Performing an online upgrade enables you to safely upgrade your system while it is online,
without having to shut down your plant.
You can upgrade a Tricon 10.3, 10.4, or 10.5 system, with Model 3008 Main Processors installed,
to a Tricon 11.2 system with Model 3009 Main Processors, while your system is online.
For detailed instructions on performing the online upgrade, including prerequisites,
precautions to be taken while performing the upgrade, and additional information, see
Technical Application Note 51 on the Global Customer Support (GCS) center website.
Before you begin an online upgrade, review Technical Application Note 51, applicable
standards, industry best practices, and your organization's internal safety procedures to
determine if an online upgrade is appropriate for your plant.
Response Time and Scan Time

Scan time must be set below 50 percent of the required response time. If scan time is greater than
50 percent, an alarm should be 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.
Disabled Output Voter Diagnostic

For safety programs, disabling the Output Voter Diagnostics is not recommended; however, if
it is required due to process interference concerns, it can be done if, and only if, the DO is proof
tested every three to six months.

Download All at Completion of Project

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

Modbus Master functions are designed for use with non-critical I/O points only. These
functions should not be used for safety-critical I/O points or for transferring safety-critical data
using the MBREAD and MBWRITE functions.
Triconex Peer-to-Peer Communication

Triconex Peer-to-Peer communication enables Triconex controllers (also referred to as nodes) to
send and receive information. 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 depend on the unique safety requirements
of your particular process. The following sections summarize actions typically required by Peer-
to-Peer send and receive functions.
Enhanced Peer-to-Peer communication is more robust than regular Peer-to-Peer
communication, with significant performance enhancements and added security through the
use of a safer CRC algorithm and redundant messaging. Also, while regular Peer-to-Peer
communication only allows for one outstanding send message, Enhanced Peer-to-Peer
communication allows for up to three outstanding send messages, resulting in improved
overall performance.
Note Due to a lack of information on the reliability and safety of switched or public networks,
Invensys recommends that switched or public networks not be used for safety-critical
Peer-to-Peer communication between Tricon systems.
Sending Node
Actions typically required in the logic of the sending application are:
• The sending node must set the SENDFLG parameter in the send call to true (1) so that
the sending node sends new data as soon as the acknowledgment for the last data is
received from the receiving node.

• The Send function blocks (TR_USEND or TR_EN_USEND) must include a diagnostic

integer variable that is incremented with each new send initiation so that the receiving
node can check this variable for changes every time it receives new data. This new
variable should have a range of 1 to 65,536 where the value 1 is sent with the first
sample of data. When this variable reaches the limit of 65,536, 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 Send and Receive function blocks can transfer data with BOOL, DINT or REAL
data types. Some function blocks transfer a maximum of 32 data values. Starting with
Tricon v11.1 systems, the number of Send function blocks initiated in any one scan
cannot exceed 20. Additionally, no more than 40 Send blocks can be pending (awaiting
acknowledgement of the Sent blocks). In Tricon v9.0 through v11.0 systems, the
number of Send function blocks initiated in any one scan cannot exceed 5, and at any
time no more than 10 Send blocks can be pending (awaiting acknowledgement of the
Sent blocks). The number of Send function blocks that can be initiated in every scan (at a
sustained rate) is further limited as follows:
— Send and Receive Node Scan Times - Since the time to receive and process an
acknowledgement depends on the relative scan times of the sending and receiving
nodes, the number of Send function blocks initiated in every scan is likely to be less
than half of the maximum given above; that is, 10 or less for Tricon v11.1 and later
systems
— Send Node Scan Surplus - The number of communication messages processed per
scan depends on the scan surplus
If proper operation of the application depends on a Send function block being initiated
in a given scan, the status of the Send function block should be monitored by the
application, and the performance should be confirmed during factory or site acceptance
testing (FAT/SAT). Please contact the Global Customer Support (GCS) center if you
need further guidance.
• The sending application must monitor the status of the Receive (TR_URCV or
TR_EN_URCV) and TR_PORT_STATUS functions to determine whether there is a
network problem that requires operator intervention.
Receiving Node
Actions typically required in the logic of the receiving application are:
• To transfer safety-critical data, the basic rule is that the receiving node must receive at
least one sample of new data within the maximum time-out limit. If this does not
happen, the application for the receiving node must take one or more of the following
actions, depending on requirements:
— Use the last data received for safety-related decisions.
— Use default values for safety-related decisions in the application.
— Check the status of the TR_URCV and TR_PORT_STATUS functions to see whether
there is a network problem that requires operator intervention.
• The receiving node must monitor the diagnostic integer variable every time it receives
new data to determine whether this variable has changed from last time.

• The receiving program must monitor the status of the TR_URCV and
TR_PORT_STATUS functions to determine if there is a network problem that requires
operator intervention.
For information on data transfer time and examples of how to use Peer-to-Peer functions to
transfer safety-critical data, see Appendix A, Triconex Peer-to-Peer Communication.
Peer-to-Peer Black Channel

The Tricon controller uses an end-to-end check (Send node to Receive node) for Peer-to-Peer
communication, 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 associated
hardware and software as a black channel, as shown in the following diagram.
Tricon MP Communication Tricon MP

Bus
Communication Communication 802.3 Switch, Hub, 802.3 Communication

Tricon MP Module cable etc. cable Module Tricon MP
Bus
Communication
Tricon MP Tricon MP
Bus Black Channel
Send Node Receive Node
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.
If all parts of the message—including the CRC—are verified, the Main Processor provides the
data to the application. If there is a problem in the black channel, the Receive node will either
not receive the message, or will receive a corrupted message that will be rejected. In this way,
the integrity of the message is independent from the communication channel and the
communication equipment used in the channel; for example, routers, hubs, switches, or
satellites.

The Receive node application receives Peer-to-Peer data only if the integrity of the Peer-to-Peer
message has been validated. Once the message has been validated, the Receive node will also
send an Acknowledge to the Send node.
SIL Capability 3/AK5 Guidelines

For Tricon v9, v10, and v11 SIL capability 3, or Tricon v9 AK5 applications, these guidelines
should be followed:
• If non-approved modules are used, the inputs and outputs should be checked to verify
that they do not affect safety-critical functions of the controller.
• Three modes control write operations from external hosts:
— Remote Mode—When the keyswitch setting is REMOTE, external hosts, such as a
Modbus Master or DCS, can write to aliased variables in the controller. When false,
writes are prohibited except for the use of gated access functions in RUN mode.
— Program Mode—When the keyswitch setting is PROGRAM, the TriStation 1131
software can make program changes, including operations that modify the
behavior of the currently running application. For example, Download All,
Download Change, declaring variables, enabling/disabling variables, changing
values of variables and scan time, etc.
— Run Mode—When the keyswitch setting is RUN, external hosts, such as a Modbus
Master or DCS, can write to aliased variables in the controller only by the
application calling gated access functions that allow external writes during a
designated window of time. Once the Writes have been performed and confirmed,
the writing window should be closed using gated access functionality and closure
of the writing access should be confirmed. For more information, see the
descriptions of the GATENB and GATDIS function blocks in Appendix 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 the
controller from external hosts should be prohibited. If remote mode or program mode
becomes true, the application program should include the following safeguards:
— When remote mode is true, the application should turn on an alarm. For example, if
using the TR_SHUTDOWN function block, the ALARM_REMOTE_ACCESS
output could be used. Verify that aliased variables adhere to the guidelines
described in Maintenance Overrides on page 32.
— When program mode is true, the application should turn on an alarm. For example,
if using the TR_SHUTDOWN function block, the
ALARM_PROGRAMMING_PERMITTED output could be used.
• Wiring and grounding procedures outlined in the Planning and Installation Guide for
Tricon v9–v11 Systems should be followed.
• Maintenance instructions outlined in the Planning and Installation Guide for Tricon v9–
v11 Systems should be followed.
• The time in each operating mode should not exceed the time in this table.

Tricon Controller SIL Capability 1 SIL Capability 2 SIL Capability 3

Operating Mode Operating Time Operating Time Operating Time
TMR Mode PTIa PTI PTI
Dual Mode PTIb PTIb PTIb
Single Mode 72 hoursb 72 hoursb 72 hoursbc
a. PTI = proof-test interval
b. Operating in dual mode significantly reduces the availability of the safety
controller. The spurious trip rate can increase by a factor of 100 or more.
Operating in single mode reduces the availability of the safety controller even
further than operating in dual mode.
c. While in single mode, the SIL3 requirement for fault tolerance 1 is not satisfied.
• The maximum operating time for your safety function should be assessed depending
on the configuration.
• The GATENB function allows external hosts to write to selected aliased variables even
when the remote mode is false. A network using the GATENB function should be
thoroughly validated to ensure that only the intended aliased variable range is used.
• Peer-to-Peer communication must be programmed according to the recommendations
in Triconex Peer-to-Peer Communication on page 25.
All Tricon logic solver faults can be repaired online without further degradation of the system
and should be performed before a second fault occurrence to maintain the highest availability
of the system. The highly effective means of modular insertion and replacement of faulted
Tricon system components is transparent to the operation of the system and the ease of
replacement mitigates the risk of systematic and human induced failure as defined by IEC
61508. It is highly recommended that a faulted component be replaced 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. 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 Tricon controller operation is degraded to dual mode or single mode, repairs should
be timely. To ensure maximum availability, limits for maximum time in degraded
mode 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 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.
• Three modes control write operations from external hosts:
— Remote Mode—When the keyswitch setting is REMOTE, external hosts, such as a
Modbus Master or DCS, can write to aliased variables in the controller. When false,
writes are prohibited.
— Program Mode—When the keyswitch setting is PROGRAM, the TriStation 1131
software can make program changes, including operations that modify the
behavior of the currently running application. For example, Download All,
Download Change, declaring variables, enabling/disabling variables, changing
values of variables and scan time, etc.
— Run Mode—When the keyswitch setting is RUN, external hosts, such as a Modbus
Master or DCS, can write to aliased variables in the controller only by the
application calling gated access functions that allow external writes during a
designated window of time. Once the Writes have been performed and confirmed,
the writing window should be closed using gated access functionality and closure
of the writing access should be confirmed. For more information, see the
descriptions of the GATENB and GATDIS function blocks in Appendix 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 the
controller from external hosts should be prohibited. If remote mode or program mode
becomes true, the application program should include the following safeguards:
— When remote mode is true, the application should turn on an alarm. For example, if
using the TR_SHUTDOWN function block, the ALARM_REMOTE_ACCESS
output could be used. Verify that aliased variables adhere to the guidelines
described in Maintenance Overrides on page 32.
— When program mode is true, the application should turn on an alarm. For example,
if using the TR_SHUTDOWN function block, the
ALARM_PROGRAMMING_PERMITTED output could be used.
• Wiring and grounding procedures outlined in the Planning and Installation Guide for
Tricon v9–v11 Systems should be followed.
• Maintenance instructions outlined in the Planning and Installation Guide for Tricon v9–
v11 Systems should be followed.
• Continued operation in dual and single modes should be as recommended in SIL
Capability 3/AK5 Guidelines on page 28.

• The GATENB function allows external hosts to write to selected aliased variables even
when the remote mode is false. A network using the GATENB function should be
thoroughly validated to ensure that only the intended aliased variable range is used.
• Peer-to-Peer communication must be programmed according to the recommendations
in Appendix A, Triconex Peer-to-Peer Communication.
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 Tricon controller operation is degraded to dual mode or single mode, repairs should
be timely. To ensure maximum availability, limits for maximum time in degraded
mode should not be imposed.
Proof-Test Interval Guidelines

A safety instrumented function (SIF) may be tested periodically to satisfy the requirements for
the specified safety integrity level (SIL). This period is called the proof-test interval.
The proof-test interval for your safety function should be assessed depending on the
configuration.
Project Change and Control

A change to a project, however minor, should comply with the guidelines of your organization’s
Safety 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 downloaded
configuration, use the Verify Last Download to the Controller command on the
Controller Panel. For details, see the TriStation 1131 Developer’s Guide .

5 Compare the configuration in your project with the configuration that was last
downloaded to the controller by printing the Compare Project to Last Download report
from the Controller Panel. For details, see the TriStation 1131 Developer’s Guide .
6 Print all logic elements and verify that the changes to networks within each element do
not affect other sections of the application.
7 Test the changes according to the test specification using the Emulator Panel. For details,
see the TriStation 1131 Developer’s Guide .
8 Write a test report.
9 Review and audit all changes and test results with the SCCC.
10 When approved by the SCCC, download the changes to the controller.
• You may make minor changes online only if the changes are absolutely necessary
and are tested thoroughly.
• To enable a Download Change command, select the Enable Programming and
Control option in the Set Programming Mode dialog box on the Controller Panel if
it is not already selected.
Note Changing the operating mode to PROGRAM generates an alarm to remind the
operator to return the operating mode to RUN as soon as possible after the
Download Change. For more information, see Programming Permitted Alarm
on page 65.
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 the
logic of the control application.
• Sensors and actuators are electrically disconnected from a controller and manually
checked using special measures.
• Communication to a controller activates the maintenance override condition. This
method is useful when space is limited; the maintenance console should be integrated
with the operator display.
TÜV 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 safety

measures in a controller to prevent downloading a program change during
maintenance intervals. For more information, see Alarm Usage on page 65.
Table 3 describes the design requirements for handling maintenance overrides when using
Tricon system communication capabilities.
Table 3 Design Requirements for Maintenance Override Handling

Responsible Person
Design Requirements TriStation 1131
DCS
Software
Control program logic and the controller Project Engineer, Project Engineer,
configuration determine whether the desired Commissioner Commissioner
signal can be overridden.
Control program logic and/or system Project Engineer Project Engineer,
configuration specify whether simultaneous Type Approval
overriding in independent parts of the application
is acceptable.
Controller activates the override. The operator Operator, Maintenance
should confirm the override condition. Maintenance Engineer,
Engineer Type Approval
Direct overrides on inputs and outputs are not Project Engineer Project Engineer,
allowed, but should be checked and implemented Type Approval
in relation to the application. Multiple overrides in a
controller are allowed as long as only one override
applies to each safety-critical group. The controller
alarm should not be overridden.
DCS warns the operator about an override Project Engineer, N/A
condition. The operator continues to receive Commissioner
warnings until the override is removed.
A second way to remove the maintenance override Project Engineer
condition should be available.
If urgent, a maintenance engineer may remove the Maintenance
override using a hard-wired switch. Engineer,
Type Approval
During an override, proper operating measures Project Engineer,
should be implemented. The time span for Commissioner,
overriding should be limited to one shift (typically DCS, TriStation
no longer than eight hours). A maintenance 1131 software
override switch (MOS) light on the operator
console should be provided (one per controller or
process unit).
Table 4 describes the operating requirements for handling maintenance overrides when using
Tricon system communication capabilities.

Table 4 Operating Requirements for Maintenance Override Handling

Responsible Person
Operating Requirements TriStation 1131
DCS
Software
Maintenance overrides are enabled for an entire Operator, Maintenance
controller or for a subsystem (process unit). Maintenance Engineer, Type
Engineer Approval
Controller activates an override. The operator Operator, Maintenance
should confirm the override condition. Maintenance Engineer, Type
Engineer Approval
Controller removes an override. Operator, Maintenance
Maintenance Engineer
Engineer
Additional Recommendations
These 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. This figure shows the procedure:
Safety-Instrumented System
Controller
Sensors Actuators
Safeguarding
Application
Program
Hard- Maintenance
Override Handling Operator
Wired
(Application Program) Warning
Switch
Distributed
Engineering
Control System
Workstation
Inputs
• Use of the maintenance override capability should be documented in a DCS or

TriStation 1131 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.
• For more information about maintenance override operation, please see the TÜV web
site 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 cables
only. The use of unapproved, unauthorized cables and/or ETPs compromises the TÜV safety
certification and potentially the ability of the logic solver to respond to safety demands. False
trips resulting from the use of unapproved components can cause end-user economic loss.
When using fanned-out interface cables or third-party ETPs—such as

CAUTION those from P&F or MTL—please consult the Global Customer Support
(GCS) center for the safety-boundary impact of using such cables or ETPs.
Background
IEC 61508 and IEC 61511 define a programmable electronic Safety Instrumented System (SIS) as
consisting of sensors, logic solvers, and final control elements, as shown in this figure.
Logic Final
Sensors
Solver Elements
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 must
choose safety-certified loop elements, including sensors, final elements, logic solvers, and other
interconnecting components.
In addition to the components shown in Figure 7, a typical SIS consists of components such as
cables and external termination panels. These components are used to connect the sensors and
final elements to the logic solvers. Figure 8 shows the SIS including these components.
Approved ETPs and interconnecting cables are listed in the Planning and Installation Guide for
Tricon v9–v11 Systems and the Technical Product Guide for Tricon v9–v11 Systems, which are
available on the Global Customer Support (GCS) center website.
Design Control, Configuration Management, Supply Chain Management, and Quality
Assurance for Triconex ETPs and cable assemblies are controlled by Invensys. Sourcing of
approved ETPs and interconnecting cables is also controlled by Invensys.

Certifications
• TÜV approves the use of Triconex ETPs and interconnecting cables with the Tricon
Safety Logic Solver.
• TÜV certifies the use of the Tricon Safety Logic Solver in SIL 3 applications with the
TÜV approved ETPs and interconnecting cables.
• Triconex ETPs are certified for electrical safety in full compliance with international
standards by CSA. They are qualified for general use in North America and other
jurisdictions requiring compliance with these standards, as well as the European CE
mark as per the Low Voltage Directive.
• Triconex ETPs and interconnecting cables comply with the applicable IEC EMC
standard (IEC 61326-3-1,2,), which includes the European CE mark per the EMC
directive.
• Triconex ETPs that are approved for hazardous locations also comply with North
America 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.
Approved cable Approved cable connects

connects Tricon to ETP (for outputs)
Approved external
Tricon to ETP
termination panel
Approved external
termination panel
End-user
installed End-user
field wiring installed
field wiring
External Logic External

Final
Sensors Termination Solver Termination
Elements
Panel (Tricon) Panel
Boundary of
TÜV-Certified
Tricon Safety System
Figure 8 Safety System Boundary
Use of Unapproved Components

The use of unapproved cables and unapproved ETPs can negatively impact the safety integrity
of the safety function and the compliance with the applicable safety standards. This causes a
liability issue in the event of a plant incident.
The use of such unapproved components can also impact the availability of the safety system
by causing false trips in the plant. This results in unnecessary economic loss for the plant.

Useful Lifetime of the Safety Controller

The useful lifetime of Triconex safety controllers is assumed to be 20 years. Some individual
components of the controller, such as Main Chassis batteries, have known lifetimes of less than
20 years. These components are replaced as part of normal maintenance procedures.
For more information about maintenance and support of Tricon controllers, see the
“Implementation and Maintenance” section in the Planning and Installation Guide for Tricon v9-
v11 Systems and the Triconex Lifecycle Product Support Guide for Customers, available on the Global
Customer Support website.


3
Fault Management
Overview 40
System Diagnostics 41
Types of Faults 42
Operating Modes 43
Module Diagnostics 45

40 Chapter 3 Fault Management
Overview
The Tricon controller has been designed from its inception with self-diagnostics as a primary
feature. Triple-Modular Redundant (TMR) architecture (shown in Figure 9) ensures fault
tolerance and provides error-free, uninterrupted control in the event of hard failures of
components or transient faults from internal or external sources.
Each I/O module houses the circuitry for three independent channels. Each channel on the
input modules reads the process data and passes that information to its respective main
processor. The three Main Processor (MP) modules communicate with each other using a
proprietary, high-speed bus system called the TriBus.
Extensive diagnostics on each channel, module, and functional circuit quickly detect and report
operational faults by means of indicators or alarms. This fault information is available to an
application. It is critical that an application properly manage fault information to avoid an
unnecessary shutdown of a process or plant.
This section discusses the methods for properly handling faults.
Auto Spare Auto Spare
Input I/O Bus Output

Channel Main Channel
A Processor A
TriBus A
Main TriBus
Input Output
Channel Processor I/O Bus Voter
B Channel
B B
Input Output
Termination TriBus Main Termination
Processor
Input I/O Bus Output
C
Channel Channel
C C
Figure 9 Typical Tricon System

System Diagnostics 41
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 controller’s diagnostics may be
categorized as:
• Reference diagnostics: Comparing an operating value to a predetermined reference,
such as a system specification.
• Comparison diagnostics: Comparing one component to another, such as one
independent channel with two other independent channels.
• Field device diagnostics: Diagnostics are extended to a system’s field devices and
wiring.

Types of Faults
A controller is subject to external faults and internal faults, which are reported by:
• The status indicators on a module’s 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 communicated
is module-specific. In some cases, a yellow alarm indicator is provided on the module. For
example, a Load/Fuse alarm is provided on digital output modules. In most cases, the System
alarm is asserted, and the System alarm indicators on the main chassis power modules are lit.
The Triconex Enhanced Diagnostic Monitor identifies the faulting module by displaying a red
frame around it. For instructions on responding to specific alarm conditions, see the Planning
and Installation Guide for Tricon v9–v11 Systems.
Internal Faults
Internal faults are usually isolated to one of the controller’s three channels (A, B, or C). When an
internal fault occurs on one of the three channels, the remaining two healthy channels maintain
full control. Depending on the type of fault, the controller either remains in TMR mode or
degrades to dual mode for the system component that is affected by the fault. For more
information about operating modes, see Operating Modes on page 43.
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 43
Operating Modes
Each input or output point is considered to operate in one of three modes:
• Triple Modular Redundant (TMR)
• Dual Mode
• 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. For safety reasons,
system mode is defined as the mode of the point controlled by the fewest number of channels.
System variables summarize the status of input and output points. When a safety-critical point
is in dual or single mode, the application may need to shut down the controlled process within
a pre-determined time.
You can further simplify and customize shutdown logic by using special function blocks
provided by Invensys. By considering only faults in safety-critical modules, system availability
can be improved. Using shutdown function blocks is essential to preventing potential false trips
in dual mode and to guaranteeing fail-safe operation in single mode. For more information, see
Appendix C, Safety-Critical Function Blocks.
While operating in TMR mode, during each scan the process is protected from the effect of a
single safety-critical system fault. The system can also tolerate multiple faults and continue to
operate correctly unless the combined effects of multiple faults affects the same point on
multiple channels.
If a system fault occurs, the loss of redundancy causes an increased probability-of-failure-on-
demand. To keep the PFD within industry acceptable guidelines, you must adhere to the
industry accepted MTTR.
A safety-critical fault is defined as a fault that prevents the system from executing the safety
function on demand. Safety-critical faults include:
• Inability to detect a change of state on a digital input point
• Inability to detect a change of value on an analog input point
• Inability to change the state of a digital output point
• Inability of the system to:
— Read each input point
— Vote the correct value of each input
— Execute the control program
— Determine the state of each output point correctly

Also, during each execution of the control application, each channel independently verifies the:
• Integrity of the data path between the MPs
• Proper voting of all input values
• Proper evaluation of the control application
• Calculated value of each output point

Module Diagnostics
Each system component detects and reports operational faults.
Digital Input (DI) Modules

Digital input module points typically use a combination of comparison and force-to-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 de-energized. These diagnostics are executed independently by each channel,
thus assuring nearly 100 percent fault coverage and fail-safe operation under all single-fault
scenarios, 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 to
increase availability during specific multiple fault conditions. Loss of logic power is reported to
the control application.
Digital Output (DO) Modules

Digital output modules use output voter diagnostics (OVD). Under system control, each output
point is commanded sequentially to both the energized and de-energized states. The forced
state is maintained until the value is detected by the system or a time-out occurs (500
microseconds, typical case; 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 percent fault coverage and fail-safe operation
under all single-fault scenarios.
Digital Output Module Alarms

Digital output module faults are reported to the control application and can be used to increase
availability during specific multiple-fault conditions. Loss of logic power is reported to the
control application.
The inability of a digital output module to control an output point is reported to the control
application as a Load/Fuse alarm. This condition can result from a loss of field power or a field
short condition. The alarm can be used to modify the control strategy or direct effective
maintenance action.
Analog Input (AI) 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 channel’s 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 nearly 100 percent fault coverage and fail-safe operation under all
single-fault scenarios and most common multiple-fault scenarios.
Analog Input Module Alarms

Analog input module faults are reported to the control application. These alarms can be used to
increase availability during specific multiple fault conditions. Loss oflogic power is reported to
Analog Output (AO) 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 percent fault coverage and fail-safe
operation under all single-fault scenarios and most common multiple-fault scenarios.
Analog Output Module Field Alarms

Analog output module faults are reported to the control application. 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 application.
Pulse Input (PI) Modules

Pulse input module points use comparison diagnostics. Under system control, each channel is
independently compared against the measured value of all channels. If a mismatch is found, an
alarm is set. These diagnostics are executed independently by each channel, thus assuring
nearly 100 percent fault coverage and fail-safe operation under all single-fault scenarios and
most common multiple-fault scenarios.
Pulse Input Module Alarms

Pulse input module faults are reported to the control application. These alarms can be used to
increase availability during specific multiple-fault conditions. Loss of logic power is reported to
Relay Output (RO) 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 application.
Input/Output Processing
Each processor on an I/O module is protected by an independent watchdog that verifies the
timely execution of the I/O module firmware and diagnostics. If an I/O processor fails to
execute correctly, the I/O processor enters the fail-safe state. The I/O bus transceiver and all
outputs for the faulting channel are disabled, leaving all outputs under control of the remaining
healthy channels.
The integrity of the I/O bus is continuously monitored and verified independently by each
channel of the system. A catastrophic bus fault results in affected I/O module channels
reverting to the fail-safe state in less than 500 milliseconds (0.5 seconds), worst case.
• Each digital input point is reported to the control program as de-energized.
• Each analog input point is reported to the control program as zero.
• Each digital output point goes to the de-energized state.
• Each analog output point goes to 0.0 mA.
• Each relay output point goes to the normally open (NO) position.
I/O Module Alarms

Loss of communication with an I/O module is reported to the control application and can be
used to increase availability during specific multiple-fault conditions.
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 the MP memory
and compare the control program instructions and the internal status.
An important feature of the Tricon System's fault-tolerance architecture is the use of a single
transmitter to send data to both the upstream and downstream MPs. This ensures that the same
data is transmitted to the upstream processor and the downstream processor.
The TriBus consists of three independent serial links, which operate at 1000 Mbps with the
Model 3009 MPs, and at 25 Mbps with the Model 3008 MPs. 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 (the watchdog period). If an MP fails to execute the scan, the watchdog forces the
MP to the fail-safe state. The I/O processor adds a sequential element to the MP watchdog. If an
MP fails to report the proper sequence of execution, the I/O processor causes the MP to enter
the fail-safe state.
Peer-to-Peer Communication
Faults in the MPs or in the communication modules may affect peer-to-peer communication.
The occurrence of a second fault in these modules may cause peer-to-peer communication to
cease for a period of time. In some cases, communication may cease and then automatically
reestablish. If necessary, you can restore communication by replacing the faulty module(s).
External Communication
Loss of external communication is not indicated by a system alarm. However, alarms can be
generated by using semaphore flags and system attributes.
External communications are intended for transporting non-safety-

CAUTION critical data. The guidelines outlined in Using Triconex System
Communication Capabilities 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.
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 following manuals:
• Communication Guide for Tricon v9–v11 Systems
• Planning and Installation Guide for Tricon v9–v11 Systems
• TriStation 1131 Libraries Reference
• TriStation 1131 Developer’s Guide

4
Application Development
Development Guidelines 50
Important TriStation 1131 Software Commands 52
Setting Scan Time 54
Sample Safety-Shutdown Programs 56
Alarm Usage 65

50 Chapter 4 Application Development
Development Guidelines
To avoid corruption of project files while developing an application (also known as a control
program), you should:
• Use a dedicated PC that is not connected to a network.
• Use a PC with ECC memory, if possible.
• Use, according to the vendor’s instructions, a regularly-updated, always-on virus
scanner.
• Use system utilities such as Checkdisk and vendor diagnostics to periodically
determine the health of the PC.
• Use dependable media, such as a CD-ROM instead of a floppy disk.
• Not use battery power if using a notebook computer.
• Not copy a project file while it is open in the TriStation 1131 software.
• Not e-mail project files.
• Not use a system prone to crashing.
• Verify proper installation of the TriStation 1131 software using TriStation Install Check.
You should run the TriStation Install Check program to verify that the TriStation 1131
software is correctly installed on your PC and that no associated files are corrupted. This
is especially helpful if applications besides the TriStation 1131 software reside on your
PC. See the TriStation 1131 Developer’s Guide for instructions on using the TriStation
Install Check program.
Invensys Product Alert Notices (PANs)

Product Alert Notices document conditions that may affect the safety of your application. It is
essential that you read all current PANs before starting application development, and that you
keep up-to-date with any newly released PANs. All PANs can be found on the Global Customer
Support (GCS) center website at support.ips.invensys.com, or contact the Global Customer
Support (GCS) center for assistance (see page ix for contact information).
Safety and Control Attributes

Each element and tagname in the TriStation 1131 application has a safety attribute, and a control
attribute. When the safety attribute is set, the TriStation 1131 software provides extra
verification. If you are developing a safety application, you should set the safety attribute.
VAR_IN_OUT Variables
You should not use the VAR_IN_OUT variable in a safety application. Safety standards (such
as IEC 61508) recommend limiting the use of pointers in safety applications; VAR_IN_OUT is
used as a pointer in the TriStation 1131 application. To automatically check for the use of
VAR_IN_OUT in your safety application, set the safety attribute (as described above).

Development Guidelines 51
Array Index Errors

If an array index error is detected during runtime, the default behavior is to trap. This results in
the Tricon controller going to the safe state, with all outputs de-energized.
If your application requires some other behavior, you can use a CHK_ERR function block to
detect the error, and a CLR_ERR function block to clear the error and prevent a trap.
Note If an array index is too small or tool large, the array operation is performed on the last
element of the array. Array bounds checking is always turned on—there is no means to
disable the array index checking.
See the TriStation 1131 Libraries Reference for more information about the CHK_ERR and
CLR_ERR function blocks.
Infinite Loops
If the actual scan time exceeds the maximum allowable scan time for the Tricon controller, the
main processors will reset, causing the Tricon controller to go to the safe state, with all outputs
de-energized. The maximum allowable scan time for the Tricon controller is 450 milliseconds.
Although it is not possible to program an endless loop with the TriStation 1131 software, it is
possible to create a loop with a very long time, enough to increase the actual scan time beyond
the controller’s maximum allowable scan time.
See Setting Scan Time on page 54 for more information about actual and maximum scan times.

Important TriStation 1131 Software Commands

Several commands in TriStation 1131 Developer’s Workbench are of special interest when
developing a safety application:
• Download Change
• Verify Last Download to the Controller
• Compare to Last Download
Download Changes
The Download Changes command is a convenient means of making simple modifications to an
offline system during application development.
Download Changes is intended for offline use during application

WARNING development. If you use Download Changes to modify a safety-critical
application that is running online, you must exercise extreme caution
because an error in the modified application or system configuration may
cause a trip or unpredictable behavior.
If you must make online changes to a controller, you should always
follow the guidelines provided in the TriStation 1131 Developer’s Guide
and fully understand the risks you are taking by using the Download
Changes command.
Note that the scan time of the controller is doubled momentarily after you
use the Download Changes command.
Changing the resolution type on model 3720 and 3721 AI modules will
cause all input points on the module to change. A change from high to
low resolution (or vice-versa) results in a value change by a factor of four.
Changing field power monitoring from On to Off (or vice-versa) will have
a similar effect, causing all input points on the module to temporarily
change to 0 for 1-2 scans.
You must modify your application to take these changes into account.
During a Download Changes operation, the implementation of the logic
change will occur before the implementation of the change on the
modules. This may result in a mismatch between what the application
expects and the actual value from the module. All points should be
bypassed during a resolution or field power monitoring change to
prevent any unintended application problems.
Before a Download Changes, use the Triconex Enhanced Diagnostic Monitor to verify that the
Scan Surplus is sufficient for the application and changes being made. As a rule, the value for

Important TriStation 1131 Software Commands 53
Scan Surplus should be at least 10 percent of Scan Time to accommodate newly added elements.
For more information on scan time, see Setting Scan Time on page 54
Do not attempt a Download Change if you have less than 10 percent Scan
WARNING Surplus. First, adjust Scan Time to make the surplus value greater than or
equal to 10 percent. Please note that adjusting the scan time of a running
system may degrade communication performance.
For more information on the Download Changes command, see the TriStation 1131 Developer’s
Guide .
Verify Last Download to the Controller

Before you make changes to a project in the TriStation 1131 software, you should run the Verify
Last Download to the Controller command to verify that the project in the TriStation 1131
software matches the application running in the controller. (You can find this command on the
Commands menu on the Controller Panel in the TriStation 1131 software.) This command
compares the current application running in the controller to a record of the last downloaded
application. To use the Verify Last Download to the Controller command, you must be able to
connect to the controller using the Connect command on the Controller panel in the TriStation
1131 software.
For more information on the Verify Last Download to the Controller command, see the
TriStation 1131 Developer’s Guide .
Compare to Last Download

After you have run the Verify Last Download to the Controller 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. (You can find this command on the Project menu
in the TriStation 1131 software.) To test the changes, use the Emulator Panel in the TriStation
1131 software.

Setting Scan Time
Setting appropriate scan time for an application is essential to avoid

WARNING improper controller behavior. When changing an application running in
an online 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 application—including print statements,
conditional statements, and future download changes.
Use the Scan Time parameter in the TriStation Program Execution List to suggest the desired
scan time before downloading an application—this is the Requested Scan Time. Upon
downloading, the controller determines the minimum and maximum allowable scan times for
your application and uses your requested scan time if it falls within the acceptable limits. The
default scan time is 200 milliseconds. The maximum allowable scan time is 450 milliseconds and
the minimum allowable scan time is 20 milliseconds for Tricon v9.5 and earlier, 10 milliseconds
for Tricon v9.6 to Tricon v10.x systems, and 20 milliseconds for Tricon v11.x and later systems.
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.
To guarantee that the controller provides a deterministic response time,

CAUTION the scan time should always be set to a value greater than the I/O poll
time (the maximum time needed by the controller to obtain data from the
input modules). You can view the I/O poll time on the System Overview
screen in the Triconex Enhanced Diagnostic Monitor.
Scan Surplus
Scan Surplus is the scan time remaining after application elements have been executed. Scan
Surplus must be positive—if it is negative, the Scan Time parameter must be adjusted (using the
Set Scan Time command on the Commands menu in the Controller Panel) to set the surplus
value to greater than or equal to 10 percent of the minimum scan time. The Scan Time parameter
in the TriStation 1131 software Program Execution List applies only when you perform a
Download All.

Setting Scan Time 55
Scan Overruns:
SCAN_STATUS
If Scan Surplus becomes negative and a scan overrun TR_SCAN_STATUS

occurs, the relevant status attributes are set as follows 1 C1 CO
POWERUP
• SCAN_OVERRUNS is incremented once for FIRSTSCAN

SCANREQUEST
each time that a longer scan time is needed. SCANSURPLUS SCAN_SURPLUS
SCANDELTA
• SURPLUS_SCAN is set to a negative number to DELTAT
indicate the additional time period used by a SCANOVERRUN SCAN_OVERRUNS

KEYSWITCH
scan overrun. 001
For more information, see the TriStation 1131 Developer’s Guide and the TriStation 1131 Libraries
Reference.

Sample Safety-Shutdown Programs

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

The sample 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.
Note The sample program is an element of project ExTUV.pt2, included as part of the
TriStation 1131 software installation. The default location of the project is C:\Documents
and Settings\<user>\My Documents\Triconex\TriStation 1131 4.1\Projects.
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 and single modes should be as
described in SIL Capability 3/AK5 Guidelines on page 28.
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.
The sample program called EX01_SHUTDOWN does not handle detected

CAUTION field faults, rare combinations of faults detected as field faults, or output
voter faults hidden by field faults. The control program, not the
TR_SHUTDOWN function block, must read the NO_FLD_FLTS module
status or FLD_OK point status to provide the required application-
specific action.
In this example, loss of all three channels (for example, if someone
accidentally removes an active IO module) results in a transition to
SINGLE, not ZERO. If you want a transition to ZERO, then use example
EX02_shutdown or EX03_shutdown.
For information on improving availability using external, power-disconnect relays and

advanced programming techniques, see the sample program EX02_SHUTDOWN.

Program EX01_SHUTDOWN
CRITICAL_MODULES
TR_SHUTDOWN
CI CO
IO_CO OPERATIING CRITICAL_MODULES_OPERATING
IO_TMR TMR
IO_GE_DUAL DUAL
IO_GE_SINGLE SINGL
IO_NO_VOTER_FLTS ZERO
IO_ERROR TIMER_RUNNING
T#1500h MAX_TIME_DUAL TIME_LEFT
T#3d MAX_TIME_SINGLE ALARM_PROGRAMMING_PERMITTED ALARM_PROGRAMMING_PERMITTED
T#400ms MAX_SCAN_TIME ALARM_REMOTE_ACCESS ALARM_REMOTE_ACCESS
ALARM_RESPONSE_TIME ALARM_RESPONSE_TIME
ALARM_DISABLED_POINTS ALARM_DISABLED_POINTS
ERROR
001
Figure 10 EX01_SHUTDOWN Sample Program
CO false indicates a programming error; for example, MAX_TIME_SINGLE greater than

MAX_TIME_DUAL. The error number shows more detail.
Table 5 Input Parameters for TR_SHUTDOWN Function Block in EX01_SHUTDOWN
Parameter Description
CI Do not connect when all I/O modules are system-critical
IO_CO Do not connect when all I/O modules are system-critical
IO_TMR Do not connect when all I/O modules are system-critical
IO_GE_DUAL Do not connect when all I/O modules are system-critical
IO_GE_SINGLE Do not connect when all I/O modules are system-critical
IO_NO_VOTER_FLTS Do not connect when all I/O modules are system-critical
IO_ERROR Do not connect when all I/O modules are system-critical
MAX_TIME_DUAL Maximum time with only two channels operating
MAX_TIME_SINGLE Maximum time with only one channel operating
MAX_SCAN_TIME 50 percent of the maximum response time

Table 6 Output Parameters for TR_SHUTDOWN Function Block in EX01_SHUTDOWN
CO Control out
OPERATING When true, all safety-critical modules are operating
properly
When false, the time in degraded operation exceeds
the specified limits; therefore, the control program
should shut down the process
TMR System is operating in triple modular redundant
mode
DUAL At least one safety-critical point is controlled by two
channels
SINGL At least one safety-critical point is controlled by one
channel
ZERO At least one safety-critical point is not controlled by
any channel
TIMER_RUNNING Time left to shutdown is decreasing
TIME_LEFT Time remaining before shutdown
ALARM_PROGRAMMING_PERMITTED True if application changes are permitted
ALARM_REMOTE_ACCESS True if remote-host writes are enabled
ALARM_RESPONSE_TIME True if actual scan time is greater than
MAX_SCAN_TIME
ALARM_DISABLED_POINTS True if one or more points are disabled.
ERROR_NUM Error Number:
0 = No error
1 = Error in maximum time
2 = I/O function block error—IO_ERROR is non-zero
3 = Function block error—system status or MP Status

Table 7 Alarm Output Parameter Operation in EX01_SHUTDOWN

ALARM_PROGRAMMING_PERMITTED 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.
ALARM_REMOTE_ACCESS For applications in which remote changes are not
allowed, connect the ALARM_REMOTE_ACCESS
output to an alarm.
ALARM_RESPONSE_TIME 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.
ALARM_DISABLED_POINTS 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.
When Some I/O Modules are 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.
Notes
• The sample program is an element of project ExTUV.pt2, included as part of the
TriStation 1131 software installation. The default location of the project is
C:\Documents and Settings\<user>\My Documents\Triconex\TriStation 1131
4.x\Projects.
• For an alternative method that allows you to select which modules to include in the
shutdown strategy, see Application Note 42, Module-Configurable TÜV Application Logic
Examples for Triconex Emergency Shutdown (ESD) Systems available on the Global
Customer Support (GCS) center website.
When the output CRITICAL_MODULES_OPERATING is true, all critical modules are
operating properly. The input MAX_TIME_DUAL specifies the maximum time allowed with
two channels operating (with no connection, defaults to 40,000 days). The input
MAX_TIME_SINGLE specifies the maximum time allowed with one channel operating (three
days in the example).

Note In typical applications, continued operation in dual and single modes should be as
described in SIL Capability 3/AK5 Guidelines on page 28.
When CRITICAL_MODULES_OPERATING is false, the time in degraded operation exceeds
the specified limits; therefore, the control program should shut down the plant.
The EX02_SHUTDOWN sample program does not handle detected field

CAUTION faults, rare combinations of faults detected as field faults, or output voter
faults hidden by field faults. The application program, not the
specific action.
CRITICAL_MODULES
CRITICAL_IO TR_SHUTDOWN
EX02_CRITICAL_IO
CI CO
CI CO IO_CO OPERATING CRITICAL_MODULES_OPERATING
RELAY1_OK TMR IO_TMR TMR
GE_DUAL IO_GE_DUAL DUAL
GE_SINGLE IO_GE_SINGLE SINGL
NO_VOTER_FLTS IO_NO_VOTER_FLTS ZERO
001 ERROR IO_ERROR TIMER_RUNNING

ERROR
002

CI Control in
If false, then CO is false—no change in the output value
If true and ERROR_NUM is 0, then CO is true
IO_CO Critical I/O control out
IO_TMR All critical I/O points are operating in triple modular redundant mode
IO_GE_DUAL All critical I/O points are operating are operating in dual or TMR mode
IO_GE_SINGLE All critical I/O points are operating are operating in single, dual, or TMR
mode
IO_NO_VOTER_FLTS 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
IO_ERROR Error number—zero indicates no error. Non-zero indicates a
programming or configuration error
MAX_TIME_DUAL Maximum time with only two channels operating


MAX_TIME_SINGLE Maximum time with only one channel operating
MAX_SCAN_TIME 50% of the maximum response time
Table 9 Output Parameters for TR_SHUTDOWN Function Block in EX02_SHUTDOWN

CO Control out
OPERATING When true, all safety-critical modules are operating
properly
When false, the time in degraded operation exceeds the
specified limits; therefore, the control program should
shut down the process
TMR System is operating in triple modular redundant mode
DUAL At least one safety-critical point is controlled by two
channels
SINGL At least one safety-critical point is controlled by one
channel
ZERO At least one safety-critical point is not controlled by any
channel
TIMER_RUNNING Time left to shutdown is decreasing
TIME_LEFT Time remaining before shutdown
ALARM_PROGRAMMING_PERMITTED True if application changes are permitted
ALARM_REMOTE_ACCESS True if remote-host writes are enabled
ALARM_RESPONSE_TIME True if actual scan time is greater than
MAX_SCAN_TIME
ALARM_DISABLED_POINTS True if one or more points are disabled
ERROR_NUM Error Number:
0 = No error
1 = Error in maximum time
2 = I/O function block error—IO_ERROR is non-zero
3 = Function block error—system status or MP Status

Table 10 Alarm Output Parameter Operation in EX02_SHUTDOWN

ALARM_PROGRAMMING_PERMITTED 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
ALARM_REMOTE_ACCESS For applications in which remote changes are not
allowed, connect the ALARM_REMOTE_ACCESS
output to an alarm
ALARM_RESPONSE_TIME 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
ALARM_DISABLED_POINTS 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
Defining Function Blocks

You can create your own user-defined function blocks for a safety-critical module:
Procedure
1 Copy the example EX02_CRITICAL_IO function block in the ExTUV.pt2 sample project
provided with the TriStation 1131 Developer’s Workbench.
2 Edit the lines following the comment “Include here all safety-critical I/O modules.”
Each line calls the safety-critical I/O (SCIO) function block for one safety-critical I/O
module.
Example
**************************************************************)
(* Include here all safety-critical I/O modules: *)
SCIO( CHASSIS:=1,SLOT:=1, APP:=DE_ENERGIZED,RELAY_OK:=FALSE):(*DI*)
SCIO( CHASSIS:=1,SLOT:=2, APP:=RELAY, RELAY_OK:=RELAY1_OK);(*DO*)
SCIO( CHASSIS:=1,SLOT:=3, APP:=RELAY, RELAY_OK:=RELAY1_OK);(*DO*)
(* ( CHASSIS:=1,SLOT:=4, NOT CRITICAL) *)(*RO*)
3 Enter the correct CHASSIS number, SLOT number, APP (application), and RELAY_OK
parameters for the safety-critical I/O module.

Table 11 Parameters for Safety-Critical Modules

Application Type Relay_OK
Description
(App) Parameter
RELAY True A voter fault degrades the mode to dual.
(de-energized to trip The relay provides a third channel for
with relay) 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.
RELAY False A voter fault degrades the mode to
(de-energized to trip single. A non-voter fault degrades the
with relay) mode to dual.
DE-ENERGIZED — A voter fault degrades the mode to
(de-energized to trip single. A non-voter fault degrades the
with no relay) mode to dual.
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
You do this by partitioning processes.
Procedure
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 64.
The EX03_SHUTDOWN sample program does not handle detected field

CAUTION faults, rare combinations of faults detected as field faults, or output voter
faults hidden by field faults. The application program, not the
specific action.

SHARED
SHARED_IO TR_SHUTDOWN
EX03_SHARED_IO CI CO
CI CO IO_CO OPERATING
GE_DUAL IO_GE_DUAL DUAL
GE_SINGLE IO_GE_SINGLE SINGL
NO_VOTER_FLTS IO_NO_VOTER_FLTS ZERO

ERROR
002
PROCESS_1
PROCESS_1_IO TR_SHUTDOWN
EX03_PROCESS_1_IO
CI CO
AND PROCESS_1_
CI CO IO_CO OPERATING OPERATING
005
GE_DUAL IO_GE_DUAL DUAL If PROCESS_1_OPERATING
GE_SINGLE IO_GE_SINGLE SINGL = FALSE, shut down
NO_VOTER_FLTS IO_NO_VOTER_FLTS ZERO process 1 because the
time in degraded mode
exceeds the specified limit
MAX_TIME_DUAL TIME_LEFT for safety-critical modules
T#1500h
MAX_TIME_SINGLE ALARM_PROGRAMMING_PERMITTED that affect process 1.
T#3d
MAX_SCAN_TIME ALARM_REMOTE_ACCESS
T#400ms
ALARM_RESPONSE_TIME
ALARM_DISABLED_POINTS
ERROR
004
PROCESS_2
PROCESS_2_IO TR_SHUTDOWN
EX03_PROCESS_2_IO
CI CO
AND PROCESS_2_
CI CO IO_CO OPERATING OPERATING
006
GE_DUAL IO_GE_DUAL DUAL If PROCESS_2_OPERATING
GE_SINGLE IO_GE_SINGLE SINGL = FALSE, shut down
NO_VOTER_FLTS IO_NO_VOTER_FLTS ZERO process 2 because the
time in degraded mode
exceeds the specified limit
MAX_TIME_DUAL TIME_LEFT for safety-critical modules
T#1500h
MAX_TIME_SINGLE ALARM_PROGRAMMING_PERMITTED that affect process 2.
T#3d
MAX_SCAN_TIME ALARM_REMOTE_ACCESS
T#400ms
ALARM_RESPONSE_TIME
ALARM_DISABLED_POINTS
ERROR
006

Alarm Usage 65
Alarm Usage
To implement the guidelines, the alarms described below are provided with the TriStation 1131
software.
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
percent 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 operator that a point is disabled.


A
Triconex Peer-to-Peer Communication
Overview 68
Data Transfer Time 70
Examples of Peer-to-Peer Applications 73

68 Appendix A Triconex Peer-to-Peer Communication
Overview
Triconex Peer-to-Peer protocol is designed to allow multiple Triconex controllers in a closed
network to exchange safety-critical data. (If you plan to implement a complex Peer-to-Peer
network, please contact the Global Customer Support (GCS) center.
To enable Peer-to-Peer communication, you must connect each controller to an Ethernet
network. This table identifies the ports in a communication module that support Peer-to-Peer
communication. The controllers exchange data by using Send and Receive function blocks in
their TriStation 1131 applications.
Communication Modules Peer-to-Peer Communication Ports

NCM NET 1 (Ethernet) port
TCM Models 4353 and 4354 NET 1 (Ethernet) port
TCM Models 4351A, 4351B, 4352A, or 4352B NET 1 or NET 2 port
UCM NET 1 or NET 2 port
Peer-to-Peer Network
CIM or CM CIM or CM
NN
MMM CC
P P P MM
A B C 1 2
MP MP
Tri-GP Controller Tricon Controller Trident Controller
Figure 13 Basic Triconex Peer-to-Peer Network Configuration
To configure a TriStation 1131 application for Peer-to-Peer communication, you must:

• Configure the physical port connection for Peer-to-Peer mode
• Allocate memory for Send and Receive function blocks
• Add Send and Receive function blocks to the TriStation 1131 application
• Observe restrictions on data transmission speed
In addition, Invensys recommends that you calculate the data transfer time to determine
whether your control algorithms will operate correctly. Instructions for performing this
calculation are provided on page 70.

Overview 69
The sample programs described in this appendix can be found in the Expeer.pt2 project
included as part of the TriStation 1131 software installation. These programs show how to send
data at high speed and under controlled conditions.
For more detailed information on Triconex Peer-to-Peer communication, please refer to the
Communication Guide for Tricon v9–v11 Systems.

Data Transfer Time

In a Peer-to-Peer application, data transfer time includes the time required to initiate a send
operation, send the message over the network, and have the message read by the receiving
node. Additional time (at least two scans) is required for a sending node to get an
acknowledgment from the MPs that the message has been acted on.
These time periods are a function of the following parameters of the sending and receiving
controllers:
• Scan time
• Configuration size
• Number of bytes for aliased variables
• Number of Send function blocks, Receive function blocks, printing function blocks, and
Modbus master function blocks
• Number of controllers (nodes) on the Peer-to-Peer network
The Send and Receive function blocks can transfer data with BOOL, DINT, or REAL data types.
Some function blocks transfer a maximum of 20 data values, and others transfer a maximum of
32 data values. Starting with Tricon v11.1 systems, the number of Send function blocks initiated
in any one scan cannot exceed 20. Additionally, no more than 40 Send blocks can be pending
(awaiting acknowledgement of the Sent blocks). In Tricon v9.0 through Tricon v11.0 systems,
the number of Send function blocks initiated in any one scan cannot exceed 5, and at any time no
more than 10 Send blocks can be pending (awaiting acknowledgement of the Sent blocks). The
number of Send function blocks that can be initiated in every scan (at a sustained rate) is further
limited as follows:
• Send and Receive Node Scan Times - Since the time to receive and process an
acknowledgement depends on the relative scan times of the sending and receiving
nodes, the number of Send function blocks initiated in every scan is likely to be less than
half of the maximum given above; that is, 10 or less for Tricon v11.1 and later systems.
• Send Node Scan Surplus - The number of communication messages processed per
scan depends on the scan surplus.
If proper operation of the application depends on a Send function block being initiated in a
given scan, the status of the Send function block should be monitored by the application, and
the performance should be confirmed during factory or site acceptance testing (FAT/SAT).
Please contact the Global Customer Support (GCS) center if you need further guidance.
Note that using enhanced Peer-to-Peer function blocks, with enhanced window size enabled,
can increase the data transfer up to two times that of non-enhanced Peer-to-Peer function
blocks. The amount of increase depends on the scan rate of the sending and receiving nodes.
Estimating Memory for Peer-to-Peer Data Transfer Time

This procedure explains how to estimate memory for Peer-to-Peer data transfer time between a
pair of Triconex controllers (nodes). The more memory allocated for aliased points the slower
the transfer time.

Data Transfer Time 71
Procedure
1 In the TriStation 1131 software, on the sending controller, expand the Controller tree,
and double-click Configuration. On the Configuration tree, click Memory Allocation.
2 Find the bytes allocated for BOOL, DINT, and REAL points by doing this:
• On the Configuration tree, click Memory Points, Input Points, or Output Points.
Double-click the graphic for the point type.
• Add the number of bytes allocated for all BOOL input, output, and aliased memory
points. Enter the number on step 1 of the following worksheet. Enter the number for
DINT and REAL points on step 1.
3 On the receiving controller, get the BOOL, DINT, and REAL points and enter the
numbers on step 3 of the Data Transfer Time worksheet.
Estimating the Data Transfer Time

The basic formula for estimating the data transfer time is as follows:
• Data transfer time in milliseconds = 2 * (larger of TS or SS) + 2 * (larger of TR or SR)
Table 12 Data Transfer Time Formula Parameters

TS Time for sending node to transfer Aliased data over the communication bus in
milliseconds = (Number of aliased variables in bytes ÷ 100,000) * 1000
SS Scan time of sending node in milliseconds
TR Time for receiving node to transfer Aliased data over the communication bus in
milliseconds = (Number of aliased variables in bytes ÷ 100,000) * 1000
SR Scan time of receiving node in milliseconds
Procedure
1 Use the instructions in the following worksheet to estimate the transfer time.
Point Allocated
Steps Operation Result
Type Bytes
1. Enter the number of bytes for each BOOL _________ ÷8= _________
point type on the sending controller and
DINT _________ x4= _________
divide or multiply as indicated. Add the
results. REAL _________ x4= _________
Total bytes of aliased points TBS = _________
2. Multiple total bytes sending TBS (step 1) by 0.01 TS = _________

Point Allocated
Steps Operation Result
Type Bytes
3. Enter the number of bytes for each BOOL _________ ÷8= _________
point type on the receiving controller and
DINT _________ x4= _________
divide or multiply as indicated. Add the
results. REAL _________ x4= _________
Total bytes of aliased points TBR = _________
4. Multiple total bytes receiving TBR (step 3) by 0.01 TR = _________
5. Get the scan time of sending node in milliseconds by viewing _________
SS =
the Scan Time in the Execution List.
6. Get the scan time of receiving node in milliseconds by viewing _________
SR =
the Scan Period in the Execution List.
7. Multiply the sum of TS and SS by 2. _________
8. Multiply the sum of TR and SR by 2. _________
9. Add the results of step 7 and 8 to get the data transfer time = DT _________
10. If the number of pending send requests in the application is
greater than 10, divide the number of send requests by 10. _________
11. Multiply the results of steps 9 and 10 to get the adjusted data Adjusted
transfer time. DT _________
12. Compare the adjusted DT to the process-tolerance time to determine if it is
acceptable.
A typical data transfer time (based on a typical scan time) is 1 to 2 seconds, and the time-out
limit for a Peer-to-Peer send (including three retries) is 5 seconds. Consequently, the process-
tolerance time of the receiving controller must be greater than 5 seconds. Process-tolerance time
is the maximum length of time that can elapse before your control algorithms fail to operate
correctly. If these limitations are not acceptable, further analysis of your process is required.
For an example that shows how to measure the maximum data transfer time and use
Send/Receive function blocks to transfer-safety critical data, see Example 4: Using
Send/Receive Function Blocks for Safety-Critical Data on page 74. While testing your system,
you should measure the actual maximum time it takes to transfer data to ensure the validity of
your calculations.
Using the information available in Table 12 and the procedure that follows it, you can calculate
and find that it takes a time duration of two to 30 seconds to detect and report time-out and
communication errors. This is why a receiving node that uses the received data to make safety-
critical decisions must include logic to verify that new data is received within the specified time
period. If the data is not received within the specified process-tolerance time, the application
must take appropriate actions depending on requirements.
For an example that shows how to use Send and Receive function blocks for transferring safety
critical data, see Example 4: Using Send/Receive Function Blocks for Safety-Critical Data on
page 74.
Refer to the TriStation 1131 Libraries Reference for additional information.

Examples of Peer-to-Peer Applications

Triconex 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 Send function block in such a way that each
Send is initiated only when the acknowledgment for the last Send is received and new data is
available for sending. You can do this through effective use of the SENDFLG parameter in the
Send function block and the STATUS output of the Send function block, as shown in Examples
3 and 4.
The examples described below can be found in the Expeer.pt2 project included as part of the
TriStation 1131 software installation.
Example 1: Fast Send to One Triconex Node

This example shows how to send 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)
Example 2: Sending Data Every Second to One Node

This example shows how to send 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:
Example 3: Controlled Use of Send/Receive Function Blocks

This example shows how to use Send/Receive 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:

Example 4: Using Send/Receive Function Blocks for Safety-Critical Data

This example shows how to use Send/Receive 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 use two NCMs, TCMs, or UCMs, and
two Peer-to-Peer networks. However, this is for availability reasons only, and is not necessary
if you have already included in your safety logic that a loss of communications will cause a
shutdown of the process under safety control.
Sending Node #1 Parameters:

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

• Scan time (SR) = 100 milliseconds
• Number of aliased variables in bytes = 15,000
• Time to transfer aliased data over the communication bus in milliseconds (TR) =
(15,000/100,000) * 1000 = 150 milliseconds
• Process tolerance time = 4 seconds
• Estimated data transfer time = 2 * 125 + 2 * 150 = 550 milliseconds
If the sending controller does not receive acknowledgment from the receiving controller in one
second, it automatically retries the last TR_USEND message. Because of network collisions,
communication bus loading, etc., the sending controller occasionally has to retry once to get the
message to the receiving node. This is why the general rule for data transfer time is one to two
seconds, even though the estimated time is 550 milliseconds.
The receiving node has a network to measure the actual time so you can validate the assumed
four-second maximum transfer time, since the process-tolerance time of the receiving node is
four seconds. The receiving node should receive at least one data transfer within the maximum
time-out limit. Using this criteria meets the basic requirement for using Peer-to-Peer
communication to transfer safety-critical data.

This example packs 32 BOOL values into a DWORD and sends the DWORD and a diagnostic
variable to a receiving node as fast as possible by setting the sendflag parameter to 1 all the time.
The diagnostic variable is incremented every time a new Send is initiated. The receiving node
checks the diagnostic variable to verify that it has changed from the previous value received.
The receiving node also determines whether it has received at least one data transfer within the
process-tolerance time. If not, the application takes appropriate action, such as using the last
data received or using default data to make safety-critical decisions.
This example uses the following project elements:
• PEER_EX4_SEND_FBD (for sending Node #1)
• PEER_EX4_RCV_FBD (for receiving Node #3)


B
HART Communication
Overview 78
HART Position Paper from TÜV Rheinland 78
Triconex 4850 HART Multiplexer FMEA 86

78 Appendix B HART Communication
Overview
This appendix contains a position paper from TÜV Rheinland on using the HART
communication protocol in safety-related applications within Safety Instrumented Systems
(SIS). The paper includes rules and guidelines that should be followed.
HART Position Paper from TÜV Rheinland

2008-04-01
Automation, Software and Information Technology
Position paper about

the use of HART communication
in safety related applications within
Safety Instrumented Systems
Version 1.0
Date: 2008-04-01
TÜV Rheinland Industrie Service GmbH

Automation, Software and Information Technology (ASI)
Am Grauen Stein
51105 Köln
Germany
v1.0 Page 1 of 7

2008-04-01
Revision History
Revision Date Change Author Approval

1.0 2008-04-01 Initial Release O. Busa H. Gall
HART_in_Safety_Related_Applications_pdf.doc
Revision 1.0 Page 2 of 7

2008-04-01
Contents Page
1. Scope 4
2. Standards 4
3. Analysis 4
3.1 General analysis 4
3.2 Safety analysis 4
4. Rules and Guidelines for the use of a HART protocol within SIS 6
5. Summary 7
This paper must not be copied in an abridged version without the written permission of TÜV
Rheinland Industrie Service GmbH.

2008-04-01
1. Scope
The scope of this paper is to review the use of the HART communication as a non-safety
related communication protocol within safety related applications using a Safety Instrumented
System (SIS).
2. Standards
Functional Safety
[1] IEC 61508:2000, parts 1 - 7

Functional safety of electrical/electronic/programmable electronic safety related systems
[2] IEC 61511:2004, parts 1 - 3

Functional safety - Safety instrumented systems for the process industry sector
3. Analysis
3.1 General analysis
The HART (Highway Addressable Remote Transducer) communication protocol is a widely

accepted standard used for communication between intelligent field instruments and host
systems.
HART is a master-slave field communication protocol, which use a phase-continuous

Frequency Shift Keying (FSK) to extend analog signaling, whereas a high-frequency current is
superimposed on a low-frequency analog current typically 4-20 mA.
The benefit of HART that it can be used in parallel to the analog 4-20 mA field devices using the
same wiring in which a bi-directional communication to several HART capable field devices is
supported.
Devices which use HART as a communication protocol can be divided into two groups:
HART Master Devices
The master devices are typically multiplexer devices with a HART modem which are connected
directly through the field wiring of a host system (input/output system) typically a programmable
logic controller. They are in general used to configure slave devices and provide additional
diagnostics to a host system.
HART Slave devices
The slave devices are in general HART capable intelligent field devices using an analog
4-20 mA current for process values.
3.2 Safety analysis
The HART communication protocol was developed to be used within standard process control
systems for device configuration and diagnostics. The development itself was not performed in
accordance to the IEC 61508 [1] and it was not approved as a safety related communication
protocol.
Considering the development of the HART communication protocol the following assumptions
can be made according to the safety impact and interference of HART capable devices, which
are intended to be used together with a safety related system.

2008-04-01
A possible impact to the safety function could be related to:
- Interference to the analog 4-20 mA signal

- Interference to the field interface input of the safety related system
- Interference to the HART capable field device
The possible effects could be negative reactions, process signal corruption or unintended
configuration changes of the connected field devices.
As a matter of principle that the HART master devices are directly connected to the field wiring
of a safety related programmable system, it must be assumed that an impact on the analog
process signal to/from the field devices is possible. Under normal circumstances the
superimposed high frequency current should be interference free to low-frequency analog
4-20 mA current, because it will be filtered by standard analog input circuit filters.
Considering abnormal function resulting from the failures (e.g., random hardware failures) of the
HART master devices, the impact to the safety related programmable system could be safety
critical resulting in negative electrical reactions on the input side or output side of the Safety
Instrumented System or corruption of the measured analog signal.
Further impact could be related to the connected field devices. The configuration could be
changed unintended resulting in non reliable analog input values to the Safety Instrumented
System. These failures could happen from a random hardware or systematic software faults or
an accidentally re-configuring from personnel.
In summary, in order to use a HART protocol, which is not approved for safety related
communication within an SIS, the following concerns must be taken into account to ensure that
the use of HART is non-interfering the 4-20 mA signal (safety input or output):
1. HART Master (AMS and MUX) directly connected to the field wiring of safety related
system could impact the process signal.
2. Abnormal function of HART Master or slave due to random hardware faults, systematic
software failures, etc. could impact the process signal
3. Unintended configuration changes (accidental re-configuring from personnel, random

hardware or systematic software faults) to the field device resulting in non-reliable analog
input values to the SIS.

2008-04-01
Picture 1: HART usage within SIS
DCS, AMS,
Diagnostic
Monitor, or
Maintenance
SIS System
RS 485
HART Protocol
Isolator
HART MUX
Isolator
4 – 20 mA
HART Master
SIS = Safety Instrumented System

MUX = Multiplexer connectd to AMS one one side, and to
4-20 mA signal on the other side.
HART AMS = Asset Management System that is connected to
Enabled MUX using RS 485. The AMS uses the HART protocol to
Field Device communicate with the HART enabled device.
DCS = Dstributed Control System
In order to ensure that the HART Master/MUX connection to the 4-20 mA signal (input/output)
connected to the SIS and use of HART protocol is non-interfering the 4-20 mA safety signal, the
rules/guidelines specified in the following must be followed by the end user.
Note, that the end user could incorporate some of the guidelines in the management of safety,
management of change, and management of maintenance policies and procedures.
4. Rules and Guidelines for the use of a HART protocol within SIS
x AMS/MUX connection to 4-20 mA signal must be isolated and decoupled such that a failure
of the MUX does not affect the 4-20 mA signal
x A detailed FMEA of the MUX interface to the 4-20 mA signal must be performed to show that
the normal operation or the failure of MUX won’t affect the 4-20 mA signal. In this case, the
MUX and associated AMS are non-interfering the 4-20 mA safety signal. If non-interfering
can not be shown by FMEA the probability of failure must be considered to determine the
safety parameters in accordance to IEC 61508 to include them into safety loop
consideration.
x The HART enabled devices used with SIS must be suitable for the SIL rating of the safety
loop as per IEC 61511 guidelines. HART enabled field devices shall be documented to be
non-interfering the 4-20 mA safety signal. In compliance with IEC 61511 -1 clause 11.5.2,
the HART enabled devices used within an SIS (Safety Instrumented System) shall be
documented to be in accordance with IEC 61508-2 and IEC 61508-3 as applicable to the SIL
(Safety Integrity Level) of the individual SIF (Safety Instrumented Function), or else they
shall meet the requirements of IEC 61511-1 clause 11.4 for hardware fault tolerance and
clauses 11.5.3 to 11.5.6 for prior use, as appropriate.

2008-04-01
x To avoid failures resulting from unintended configuration changes of the HART capable field
devices, protection mechanisms, which may be provided by the HART devices, shall be
used.
x The data (Secondary variables, device information, diagnostics, and status data) received
from the HART device must not be used for safety related reactions in the SIS.
x The data received from the HART devices could be used in control, diagnostics, or asset
management systems for device diagnostics and maintenance purposes. The Asset
Management, Diagnostics, maintenance systems and operating procedures is to act as an
independent layer of protection; in this case the role of asset management is to identify a
potential failure on a field element (i.e. valve) that might prevent the safety function to act if
demanded.
x As a part of management of safety policy, practices and procedures, the AMS (HART
master) must be password protected to allow maintenance of and modifications to the HART
enabled field devices connected to SIS by authorized people only. The Safety procedure
should include provisions to avoid re-configuration of HART enabled field devices by
mistake.
x Online changes to the field device configuration, online calibration and online maintenance
shall be avoided and must be evaluated depending on the application.
x Safety procedures must be established to ensure proper use of the AMS or hand-held
communicator for configuration changes, calibration or maintenance of HART enabled field
devices connected to SIS. Any change to the HART enable field device must be followed by
verification to prove the correct implementation.
5. Summary
Following the rules and guidelines as listed in chapter 4. the HART communication can be used
within safety related applications using Safety Instrumented Systems (SIS).
Besides, the available safety- and user guidelines of the SIS and HART devices shall be
considered for further information and restrictions.

Triconex 4850 HART Multiplexer FMEA

After conducting a failure mode and effects analysis (FMEA)/non-interfering analysis of the
Triconex 4850 HART Multiplexer and its use in Tricon systems, Invensys concluded that the
Triconex 4850 HART Multiplexer, which is used with Tricon HART AO and AI Interface
Modules and HART MUX Modules, is suitable for use as a non-interfering module in a Safety
Instrumented System (SIS), according to the requirements of IEC 61508.
You should consider the need for additional diagnostics in your TriStation 1131 control
application, as described in the Analysis Summary.
Analysis Summary
Figure 14 Typical Tricon AI
Figure 15 Typical Tricon AO
The analysis considered the following categories of faults:

Triconex 4850 HART Multiplexer FMEA 87
• 24 VDC field power signal and ground in Triconex 4850 HART Multiplexer faults,
including 24 VDC, 6.5 VDC, 5 VDC, GND shorts to ground and I/O pins and
overvoltage conditions.
• Tricon AO/AI Interface Module, HART MUX module, or Triconex 4850 HART
Multiplexer faults, including I/O pin-to-pin shorts, wrong board address, I/O pin-
to-pin cross-talk, and I/O pin open.
• PC or Triconex 4850 HART Multiplexer faults, including faults associated with
corrupted RS-485 signals.
• Faults associated with transient signals at the I/O pins.
• Triconex 4850 HART Multiplexer faults, including faults associated with shorting of
the AC coupling capacitors.
• Field environment faults, including faults associated with the injection of high
frequency signals in the 4 to 20 mA lines.
Invensys concluded the most of the faults on the interface modules will not result in more than
the loss of HART communication or decreased noise immunity. However, failures to the RLC
inductor, capacitor, or resistor and the snubber capacitors may cause the 4 to 20 mA loop to
move from the expected value. You can develop detection of such faults through your TriStation
1131 control application.


C
Safety-Critical Function Blocks
GATDIS 91
GATENB 92
TR_CRITICAL_IO 94
TR_SHUTDOWN 100
TR_VOTE_MODE 107

90 Appendix C Safety-Critical Function Blocks
Overview
This appendix describes these function blocks, which are intended for use in safety-critical
applications:
• GATDIS on page 91
• GATENB on page 92
• TR_CRITICAL_IO on page 94
• TR_SHUTDOWN on page 100
• TR_VOTE_MODE on page 107

GATDIS 91
GATDIS
Disables remote writes to aliased variables in a Tricon controller.
Syntax
GATDIS(CI:=b)
Input Parameters
Name Data Type Description
CI BOOL Enables GATDIS.
Output Parameters
CO BOOL True if GATDIS execute successfully.
Description
In a Tricon controller, the GATDIS function block disables remote writes for all ranges of
read/write aliased variables that were previously enabled by GATENB, thereby restricting
write operations by external hosts. GATDIS must be executed after the GATENB function. For
more information, see GATENB on page 92.
Example
VAR GATE_IS_DISABLED : BOOL ; END_VAR
VAR DISABLED_GATE : GATDIS ; END_VAR
DISABLE_GATE(TRUE);
GATE_IS_DISABLED = GATDIS.CO ;
Runtime Errors
None.
Application Notes
• Can be used in Safety or Control applications.
• Only Once: each instance should be executed only once per scan, but does not need to
be executed every scan.
Library
Tricon (TX1LIB)

GATENB
Enables remote writes to aliased variables in a Tricon controller.
Syntax
GATENB(CI:=b,DRWFRST:=k1,DRWLAST:=k2,IRWFRST:=k3,IRWLAST:=k4,RRWFRST:=k5,KRW
LAST:=k6
Input Parameters
CI BOOL Enables GATENB.
DRWFRST DINT The starting alias number for memory discrete (BOOL) read/write range.
DRWLAST DINT The ending alias number for memory discrete (BOOL) read/write range.
IRWFRST DINT The starting alias number for memory integer (DINT) read/write range.
IRWLAST DINT The ending alias number for memory integer (DINT) read/write range.
RRWFRST DINT The starting alias number for memory real read/write range.
RRWLAST DINT The ending alias number for memory real read/write range.
Output Parameters
CO BOOL True if GATENB executes successfully.
Description
In a Tricon controller, the GATENB function block opens a gate for external-host read/writes to
a specified range of Modbus aliased variables when the controller is operating in RUN mode.
In a safety shutdown application, the keyswitch is typically set to RUN mode for normal
operation. However, this mode does not support Modbus writes from external hosts. To solve
this problem, the TriStation 1131 software provides gated-access function blocks to
programmatically enable and disable external-host writes to a Tricon controller.
GATENB allows you to specify a range of aliases for each of these data types:
• Discrete Read/Write
• Integer Read/Write
• Real Read/Write
You should use only one GATENB function block in a program. If you do not want to specify
alias ranges for certain data types, leave their starting and ending values at zero (the default).

GATENB 93
Example
This example opens a gate for external-host writes to selected Modbus read/write memory
BOOL and DINT variables.
VAR ENABLE_GATE : GATENB; END_VAR
ENABLE_GATE( CI:=TRUE,DRWFRST:=2001, DRWLAST:=2020,
IRWFRST:=40251,IRWLAST:=40258,
RRWFRST:=0, RRWLAST:=0 );
Runtime Errors
Condition Return Value Error Flags

If a specified alias range is invalid CO=false None
If this is a second function block with the same specified alias range CO=false None
Upon detection of a runtime error condition, the function block returns the indicated values and
sets the error flags to true. For more information about error flags and runtime errors, see the
CHK_ERR function block description in the TriStation 1131 Libraries Reference.
Application Notes
• Only Once: each instance should be executed only once per scan, but does not need to
be executed every scan.
Library
Tricon (TX1LIB)

TR_CRITICAL_IO
Accumulates the status of safety-critical I/O modules in a Tricon controller.
Syntax
MY_TR_CRITICAL_IO( CI:=b1, INIT:=b2, CHASSIS:=n1, SLOT:=n2, APP:=n3,
RELAY_OK:=b3 ) ;
Input Parameters
CI BOOL Enables TR_CRITICAL_IO.
INIT BOOL Initializes TR_CRITICAL_IO.
CHASSIS DINT The chassis number (1–15).
SLOT DINT The physical slot number.
APP DINT The application number (1-2).
RELAY_OK BOOL The relay is energized and not stuck.
Output Parameters
CO BOOL True if TR_CRITICAL_IO executes successfully.
TMR BOOL Three channels are operating without fatal faults on critical I/O
modules detected.
GE_DUAL BOOL Two channels are operating without fatal faults on critical I/O
modules detected.
GE_SINGLE BOOL At least one channel is operating without faults on critical I/O
modules detected.
NO_VOTER_FLTS BOOL No voter faults on critical I/O modules detected.
ERROR DINT Error Number:
0 = No error.
–1 The slot is not odd or not numbered 1–15.
–2 = Invalid chassis or slot.
–3 = The module is not configured.
–4 = An invalid application number is used.
–5 = Not initialized.
Description
The TR_CRITICAL_IO function block accumulates the status of all safety-critical I/O modules
in a Tricon controller.

TR_CRITICAL_IO 95
Instructions for Use

The following instructions for using the TR_CRITICAL_IO function block apply to the
Structured Text (ST) language.
To obtain the accumulated status of critical I/O modules:

1 Initialize TR_CRITICAL_IO by invoking it once with INIT := TRUE.
2 To complete initialization, invoke TR_CRITICAL_IO again with these input settings:
• 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 this example applies. SCIO is the function block instance
name:
SCIO(CHASSIS:=1,SLOT:=1,APP:=DE-ENERGIZED,RELAY_OK:=FALSE);
SCIO(CHASSIS:=1,SLOT:=2,APP:=RELAY,RELAY_OK:=RELAY1_OK);
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.
Example
For shutdown examples, see this sample project:
My Documents\Triconex\TriStation 1131 4.x\Projects\ExTUV.pt2

Runtime Errors

If ERROR_NUM is non-zero Reset all BOOL outputs to false BADPARAM, ERROR
CHK_ERR function block in the TriStation 1131 Libraries Reference.
Application Notes
Library
Tricon (TR1LIB/TX1LIB)
Structured Text
FUNCTION_BLOCK TR_CRITICAL_IO
VAR_INPUT
CI : BOOL := TRUE ; (* Control in. *)
INIT : BOOL ; (* Initialize *)
CHASSIS : DINT ; (* Chassis number 1-15 *)
SLOT : DINT ; (* Physical SLOT odd number 1,3..15 *)
APP : DINT ; (* Application number 1-2 *)
RELAY_OK : BOOL := TRUE ; (* Relay is energized and not stuck. *)
END_VAR
VAR_OUTPUT
CO : BOOL ; (* Critical IO Control out. *)
TMR : BOOL := TRUE ; (* Critical IO 3 channels operating. *)
GE_DUAL : BOOL ; (* Critical IO 2 or more channels operating. *)
GE_SINGLE : BOOL ; (* Critical IO 1 or more channels operating. *)
NO_VOTER_FLTS : BOOL ; (* No voter faults on critical modules. *)
ERROR : DINT ; (* Error number. *)
(*
* Error number:
* 0 = No error.
* -1 = Slot is not odd or not in 1..15.
* -2 = Chassis or slot is invalid.
* -3 = Module not configured.
* -4 = Reserved (not used).
* -5 = Application number is invalid.
* -6 = Not initialized.
*)
END_VAR
VAR
PREVIOUS_INIT : BOOL ; (* INIT on previous evaluation. *)
MP : TR_MP_STATUS ; (* MP status. *)

TR_CRITICAL_IO 97
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
* RELAY_OK := FALSE to complete initialization.
* 3. Invoke repeatedly, once for each critical IO module.
* 4. Read outputs CO, TMR, GE_DUAL, and GE_SINGLE for safety critical results.
*
* In step 3, invoke with the CHASSIS and SLOT of the critical IO module,
* the module application, and the relay status.
* For example, if CHASSIS 1 SLOT 5 is a critical DO module with a relay,
* and SCIO is the function block instance name:
* SCIO( CHASSIS:=1, SLOT:= 5, APP:=RELAY, RELAY_OK:=RELAY1_OK );
*
* Slot Number
* Each logical IO slot consists of two physical slots,
* a left slot and a right slot. By convention,
* the physical slot number of the left slot is always odd.
* The SLOT parameter is the physical slot number of the left slot.
*
* Application
* The APP parameter for a module selects the effect of a fault
* on the vote mode outputs of the shutdown function blocks.
* APP:=RELAY with RELAY_OK:=true
* A single fault (even a voter fault) degrades the mode to DUAL.
* The relay provides a third channel for shutdown,
* so if an output voter fails, there are still

* two independent channels that can de-energize the output,

* i.e., the relay and the other output voter channel.
* APP:=RELAY with RELAY_OK:=false, or
* APP:=DE_ENERGIZED
* A voter fault degrades the mode to SINGLE.
* A non-voter fault degrades the mode to DUAL.
*
* Runtime Errors
* EBADPARAM Bad parameter
* CO=FALSE indicates a programming error.
* See ERROR number parameter for details.
*=F=========================================================================
======
*)
IF INIT THEN
MP( CI := TRUE ) ;
CO := MP.CO ;
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. *)
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. *)
CO := FALSE ;
END_IF ;
END_IF ;

TR_CRITICAL_IO 99
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 *)
CO := FALSE ;
END_IF ;
END_IF ;
END_IF ;
IF ERROR = 0 AND NOT CO THEN
ERROR := -6 ; (* Not initialized *)
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

TR_SHUTDOWN
Enables a Tricon system shutdown according to industry guidelines.
Syntax
MY_TR_SHUTDOWN( CI:=b1, IO_CO:=b2, IO_TMR:=b3, IO_GE_DUAL:=b4,
IO_GE_SINGLE:=b5, IO_NO_VOTER_FLTS:=b6, IO_ERROR:=n1, MAX_TIME_DUAL:=t1,
MAX_TIME_SINGLE:=t2, MAX_SCAN_TIME:=t3 ) ;
Input Parameters
CI BOOL Enables TR_SHUTDOWN.
IO_CO BOOL True if TR_SHUTDOWN executes successfully.
IO_TMR BOOL Three channels are operating without fatal faults detected.
IO_GE_DUAL BOOL Two channels are operating without fatal faults detected.
IO_GE_SINGLE BOOL One channel is operating without fatal faults detected.
IO_NO_VOTER_FLTS BOOL No failed critical modules detected.
IO_ERROR DINT Zero = no error.
Non-zero = programming or configuration error.
MAX_TIME_DUAL TIME The maximum time of continuous operation in dual mode
(two channels operating).
MAX_TIME_SINGLE TIME The maximum time of continuous operation in single mode
(one channel operating).
MAX_SCAN_TIME TIME 50% of the maximum response time.
Output Parameters
CO BOOL True if TR_SHUTDOWN executes
successfully.
OPERATING BOOL If false, shut down.
TMR BOOL Three channels are operating.
DUAL BOOL Two channels are operating.
SINGL BOOL One channel is operating.
ZERO BOOL No channels are operating.
TIMER_RUNNING BOOL The shutdown timer is running
TIME_LEFT TIME The time remaining to shutdown.
ALARM_PROGRAMMING_PERMITTED BOOL True if application changes are permitted.
ALARM_REMOTE_ACCESS BOOL True if remote-host writes are enabled.

TR_SHUTDOWN 101
Output Parameters (continued)

ALARM_RESPONSE_TIME BOOL True if actual scan time is greater than or
equal to MAX_SCAN_TIME.
ALARM_DISABLED_POINTS BOOL True if one or more points are disabled.
ERROR DINT 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.
Description
The TR_SHUTDOWN function block enables a Tricon system shutdown according to industry
guidelines.
Example
Runtime Errors

If ERROR is non-zero Set alarm outputs to true, reset the other BOOL BADPARAM, ERROR
outputs to false, and reset TIME_LEFT to zero.
CHK_ERR function block.
If a programming error or configuration error occurs, then CO is false and the error number is
non-zero. For error numbers, see the description of the ERROR output.
Application Notes
Library

Structured Text
FUNCTION_BLOCK TR_SHUTDOWN
VAR_INPUT
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

TR_SHUTDOWN 103
(*
*=F=========================================================================
======
* FUNCTION_BLOCK: TR_SHUTDOWN
* Purpose: Implement TUV restrictions.
*
* Return: none
*
* Remarks:
*
* Example EX01_SHUTDOWN shows one way to check that
* the safety system is operating within spec when
* 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
* CO=FALSE indicates a programming error.
* See ERROR number parameter for details.
*=F=========================================================================
======
*)
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
);

TR_SHUTDOWN 105
GE_DUAL := NOT MP.MPBAD AND

(
NOT IO_CO AND NOT MP.IOBAD
OR IO_CO AND IO_GE_DUAL
);
GE_SINGLE :=
(
NOT IO_CO
OR IO_CO AND IO_GE_SINGLE
);
(* Update timers. *)
DUAL_TIME( IN := NOT TMR, PT := MAX_TIME_DUAL ) ;
SINGLE_TIME( IN := NOT GE_DUAL, PT := MAX_TIME_SINGLE ) ;
(* Shutdown if excessive time in degraded operation. *)

OPERATING :=
GE_SINGLE
AND NOT DUAL_TIME.Q
AND NOT SINGLE_TIME.Q
;
(* Output current status. *)

DUAL := GE_DUAL AND NOT TMR ;
SINGL := GE_SINGLE AND NOT GE_DUAL ;
ZERO := NOT GE_SINGLE ;
TIMER_RUNNING := OPERATING AND NOT TMR ;
(* Output time remaining to shutdown. *)

IF NOT OPERATING THEN
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. *)
OPERATING := FALSE ;
TMR := FALSE ;
GE_DUAL := FALSE ;
GE_SINGLE := FALSE ;
DUAL := FALSE ;
SINGL := FALSE ;
ZERO := FALSE ;
TIMER_RUNNING := FALSE ;
TIME_LEFT := T#0S;
ALARM_PROGRAMMING_PERMITTED := TRUE ;
ALARM_REMOTE_ACCESS := TRUE ;
ALARM_RESPONSE_TIME := TRUE ;
ALARM_DISABLED_POINTS := TRUE ;
END_IF ;
END_IF ;
END_FUNCTION_BLOCK

TR_VOTE_MODE 107
TR_VOTE_MODE
Converts redundancy status.
Syntax
MY_TR_VOTE_MODE( CI:=b1, IN_TMR:=b2, GE_DUAL:=b3, GE_SINGLE:=b4 ) ;
Input Parameters
CI BOOL Enables TR_VOTE_MODE.
IN_TMR BOOL Three channels are operating.
GE_DUAL BOOL Two or more channels are operating.
GE_SINGLE BOOL One or more channels are operating.
Output Parameters
CO BOOL True if TR_VOTE_MODE executes successfully.
TMR BOOL Three channels are operating.
DUAL BOOL Two channels are operating.
SINGL BOOL One channel is operating.
ZERO BOOL No channels are operating.
Description
The TR_VOTE_MODE function block converts redundancy status, as shown in this truth table.
Truth Table
TMR GE_DUAL GE_SINGLE TMR DUAL SINGL ZERO
T T T T F F F
F T T F T F F
F F T F F T F
F F F F F F T
Othera F F F F
a. If an error in the inputs occurs, then CO is false, the mode

outputs are false, and the function block reports a bad
parameter error (BADPARAM).
Note GE_ means greater than or equal to.

Example
Runtime Errors

If the inputs do not match one of the first Reset all BOOL outputs to false BADPARAM, ERROR
four rows of the truth table
CHK_ERR function block in the TriStation 1131 Libraries Reference.
Application Notes
• Space Saver: a single instance can be executed more than once per scan to reduce
memory usage and increase performance. For directions, see the TriStation 1131
Libraries Reference.
Library
Structured Text
FUNCTION_BLOCK TR_VOTE_MODE
VAR_INPUT
IN_TMR : BOOL ; (* 3 channels operating. *)
GE_DUAL : BOOL ; (* 2 or more channels operating. *)
GE_SINGLE : BOOL ; (* 1 or more channels operating. *)
END_VAR
VAR_OUTPUT
CO : BOOL ; (* Control out. *)
TMR : BOOL ; (* Triple Modular Redundant. *)
DUAL : BOOL ; (* Dual mode. *)
SINGL : BOOL ; (* Single mode. *)
ZERO : BOOL ; (* Zero mode. *)
END_VAR
VAR
U : BOOL ; (* Unused Value. *)
END_VAR
(*

TR_VOTE_MODE 109
*=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
* 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 AND GE_SINGLE OR NOT GE_DUAL AND NOT IN_TMR;
IF CO THEN
TMR := IN_TMR ;
DUAL := GE_DUAL AND NOT IN_TMR ;
SINGL := GE_SINGLE AND NOT GE_DUAL ;
ZERO := NOT GE_SINGLE ;
ELSE
TMR := FALSE ;
DUAL := FALSE ;
SINGL := FALSE ;
ZERO := FALSE ;
END_IF ;
END_IF ;
END_FUNCTION_BLOCK


Index
A chassis
abbreviations, list of viii adding while the controller is online 23
actual scan time 54 commands
addressing error 18 Compare to Last Download 53
Download All 25
alarms
Download Change 52
analog input module 46
Verify Last Download to Controller 53
analog output module 46
digital input module 45 communication
digital output modules 45 external 48
disabled points 24, 65 for maintenance overrides 32
I/O modules 47 communication errors
output operation 61 description of 17
programming permitted 65 preventing 18
pulse input module 46 Compare to Last Download command 53
relay output module 47 connection authentication safety measure 19
remote access 65 corruption error 17
semaphore flags 48 CSA C22.2 NO 199 14
system attributes 48 customer support ix
analog input module
alarms 46 D
diagnostics 45
data integrity assurance safety measure 19
analog output module
data transfer time 70–75
alarms 46
diagnostics 46 DCS programs, recommendations 34
analysis design requirements 33
hazard and risk 5 development guidelines 50
ANSI/ISA S84.01 13 diagnostics
analog input module 45
application-specific standards 13, 14
analog output module 46
architecture, system 40
digital input module 45
array index errors 51 digital output module 45
disable output voter 24
B pulse input module 46
black channel communication relay output module 46
errors 17 system 41
safety measures 18 different data integrity safety measure 20
burner management systems, guidelines 21 digital input module
bus, Tribus 40 alarms 45
diagnostics 45
C digital output module
calculating PFDavg alarms 45
equation for sensors 7 diagnostics 45
calculations, SIL examples 6 DIN V 19250 12
certification, TÜV Rheinland 16 DIN V VDE 0801 12
change control 31 disable output voter diagnostics 24

112 Index
disabled points alarms 24, 65 guidelines (continued)

Download All command 25 fire and gas systems 21
Download Change command 52 general 17
maintenance overrides 32–35
proof-test interval 31
E
safety system boundary 35
emergency shutdown systems, guidelines 20 safety system useful lifetime 37
EN 50156 13 SIL 28–31
EN 54, part 2 13 SIL fire and gas 29, 31
equations SIL general 28, 30
calculating PFDavg for sensors 7 Tricon controller 22
errors in external communication 17–18
EX01_shutdown program 57 H
EX02_shutdown program 60 HART
EX03_shutdown program 64 position paper from TÜV Rheinland 78
external communication 48 hazard and risk analysis 5
errors in 17 HAZOP 5
safety measures for 18
external faults 42
I
I/O bus
F faults 47
factors integrity of 47
SIL 3 I/O modules
SIS 3, 5 alarms 47
faults processors 47
external 42 status 94
internal 42 system-critical 56
safety-critical 43 IEC 61508, parts 1–7 12
types 42 incorrect sequence error 17
feedback message safety measure 19
infinite loops 51
fire and gas systems, guidelines 21 input module alarms
flags analog 46
semaphore 48 digital 45
function blocks pulse 46
GATDIS 91 input module diagnostics
GATENB 92 analog 45
TR_URCV 75 digital 45
TR_USEND 75 pulse 46
Triconex Peer-to-Peer 73–75 insertion error 18
functions
internal faults 42
Modbus master 25
K
G
keyswitch settings 28
GATDIS function block 91
gate disable 91
gate enable 92
L
layers
GATENB function block 92
protection 5
guidelines
all safety systems 17–20 loss error 17
burner management systems 21
development 50
emergency shutdown systems 20

Index 113
M output module diagnostics (continued)

Main Processor relay 46
Tribus 47 output operation alarms 61
maintenance overrides output parameters 58
design requirements for handling 33 output voter diagnostics 24
guidelines 32–35 OVD
methods for 32 See output voter diagnostics
operating requirements for handling 34 overrides
masquerade error 18 maintenance 32
message errors, external communication overrides, maintenance guidelines 32–35
description of 17 overrun
safety measures for 18 scan 55
Modbus master functions 25 overview
modes safety 5
operating 43
module alarms P
analog input 46 parameters
analog output 46 output 58
digital input 45
partitioning processes 63
digital output 45
Peer-to-Peer communication
I/O 47
description of function blocks for 68
pulse input 46
overview 25, 68
relay output 47
Peer-to-Peer function blocks
module diagnostics
errors 72
analog input 45
examples 73
analog output 46
rules for correct usage 68
digital input 45
using with critical data 26
digital output 45
permitted alarms
pulse input 46
programming 65
relay output 46
module processors PFDavg for sensors
I/O 47 equation for calculating 7
modules points
safety-critical 22 disabled 65
system-critical shutdown program for all 56 processes
system-critical shutdown program for some 59 partitioning 63
upgrading while the controller is online 24 processors
I/O modules 47
Product Alert Notices 50
N
Program mode 28
NFPA 72 13
programmable electronic systems 4
NFPA 85 14
programming permitted alarms 65
programs
O EX01_shutdown 57
online upgrade 24 EX02_shutdown 60
operating modes 43 EX03_shutdown 64
output module alarms recommendations for DCS programs 34
analog 46 safety-shutdown for all system-critical I/O
digital 45 modules 56
relay 47 safety-shutdown for some system-critical I/O
output module diagnostics modules 59
analog 46 project change and control 31
digital 45

114 Index
proof-test interval scan time

guidelines 31 actual 54
protection layers 2, 5 allowable exceeded 51
protection, external comminication 18 overview 54
pulse input module requested 54
alarms 46 response time and 24, 65
diagnostics 46 security
guidelines 2
R semaphore flags 48
SEND function
redundancy with cross-checking safety measure 20
peer-to-peer communication 25
relay output module
sensors
alarms 47
equation for calculating PFDavg 7
diagnostics 46
sequence number safety measure 18
remote access 92
remote access alarms 65 serial communication, operating requirements 34
Remote mode 28 shutdown
programs for all system-critical I/O modules 56
remote write access 91
programs for some system-critical I/O modules 59
requested scan time 54
safe 23
requirements, design 33 system emergencies 20
response time and scan time 24, 65 TR_CRITICAL_IO function block 94
risk probability 6 TR_SHUTDOWN function block 100
risk reduction factor 6 TR_VOTE_MODE 107
risks, described 6 SILs
calculation examples 6
S determining 6, 8
safety factors 3
attribute 50 fire and gas guidelines 29, 31
methods 2 guidelines 28–31
overview 5 SIS factors 3, 5
requirement specifications 9 specifications, safety requirements 9
safety integrity levels standards
See SILs application-specific 13, 14
safety life cycle general safety 12–13
model 9 relation to SILs 6
PES steps 9–11 status
safety measures for external communication 18–20 critical I/O modules 94
safety system boundary 35 surplus
safety system useful lifetime 37 scan 54
safety systems, guidelines 17–20 system
architecture 40
safety-critical
attributes as alarms 48
faults 43
availability 6
modules 22
burner management 21
safety-instrumented systems
diagnostics 41
See SISs
emergency shutdown 20
safety-shutdown
fire and gas 21
networks 23
system-critical I/O modules
overview 23
safety-shutdown program for all 56
programs for all system-critical I/O modules
safety-shutdown program for some 59
modules 56
programs for some system-critical I/O modules 59
scan overrun 55 T
scan surplus 52, 54 technical support ix

Index 115
threats, external communication 17

time
scan 54
time expectation safety measure 19
time stamp safety measure 19
TMR architecture 40
TR_CRITICAL_IO function block 94
TR_SHUTDOWN function block 100
TR_URCV function blocks 73–75
TR_USEND function blocks 73–75
TR_VOTE_MODE function block 107
training viii
Tribus
Main Processor 47
system architecture 40
Triconex contact information viii
Triconex Peer-to-Peer function blocks 73–75
TÜV Rheinland certification 16
types of faults 42
U
unacceptable delay error 18
unintended repetition error 17
V
VAR_IN_OUT variables 50
voter diagnostics
disable output 24
W
watchdog period 47
write access 91

116 Index

Invensys Systems, Inc.
10900 Equity Drive
Houston, TX 77041
United States of America
http://www.iom.invensys.com
Global Customer Support

Inside U.S.: 1-866-746-6477
Outside U.S.: 1-508-549-2424
Website: http://support.ips.invensys.com

Safety Considerations Guide For Tricon Systems

Uploaded by

Document Information

Original Title

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 For Tricon Systems

Uploaded by

Copyright:

Available Formats

Tricon™ v9–v11 Systems

Assembly Number 9700097-013

© 2006-2016 Invensys Systems, Inc. All rights reserved.

Document Number 9720097-013, Rev 1

Chapter 1 Safety Concepts 1

Chapter 2 Application Guidelines 15

Safety Considerations Guide for Tricon v9–v11 Systems

Modbus Master Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Chapter 3 Fault Management 39

Chapter 4 Application Development 49

Safety Considerations Guide for Tricon v9–v11 Systems

When All I/O are Modules Safety-Critical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Appendix A Triconex Peer-to-Peer Communication 67

Appendix B HART Communication 77

Appendix C Safety-Critical Function Blocks 89

Safety Considerations Guide for Tricon v9–v11 Systems

Safety Considerations Guide for Tricon v9–v11 Systems

Safety Considerations Guide for Tricon v9–v11 Systems

BPCS Basic process control system

Product and Training Information

Safety Considerations Guide for Tricon v9–v11 Systems

Safety Considerations Guide for Tricon v9–v11 Systems

We Welcome Your Comments

Safety Considerations Guide for Tricon v9–v11 Systems

Safety Considerations Guide for Tricon v9–v11 Systems

Safety Considerations Guide for Tricon v9–v11 Systems

Figure 1 Effect of Protection Layers on Process Risk

When an SIS is required, one of the following should be determined:

Safety Considerations Guide for Tricon v9–v11 Systems

Safety Considerations Guide for Tricon v9–v11 Systems

Hazard and Risk Analysis

Safety Integrity Levels

Percent PFDavg RRF ANSI/ISA IEC DIN V

Risk Measures Risk Standards

Figure 2 Standards and Risk Measures

Safety Considerations Guide for Tricon v9–v11 Systems

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

Determining a Safety Integrity Level

Sample Low Demand SIL Calculation

Safety Considerations Guide for Tricon v9–v11 Systems

Figure 3 Comparison of Percent Availability and PFD

Safety Integrated System

Figure 4 Simplified Diagram of Key Elements

Table 1 Simplified Equations for Calculating PFDavg

Safety Considerations Guide for Tricon v9–v11 Systems

Table 1 Simplified Equations for Calculating PFDavg

Note Equations are approximate

Table 2 Determining the SIL Using the Equations

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

Tricon Controller 4380 1.0E-05 0.1E-04

PFDavg for SIF 6.5E-04

Safety Life Cycle Model

Safety Considerations Guide for Tricon v9–v11 Systems

Figure 5 Safety Life Cycle Model

Developing an SIS Using the Safety Life Cycle

Safety Considerations Guide for Tricon v9–v11 Systems

• Select a functional test interval to achieve the SIL.

Safety Considerations Guide for Tricon v9–v11 Systems

6 Before start-up, complete a safety review.

Safety Considerations Guide for Tricon v9–v11 Systems

General Safety Standards

DIN V VDE 0801

IEC 61508, Parts 1–7