safety manual safety manager rel 101

Safety ManagerSafety Manual

EP-SM.MAN.6283Issue 5

20 June 2005

Release 101

ii

NoticeThis document contains Honeywell proprietary information. Information contained herein is to be used solely for the purpose submitted, and no part of this document or its contents shall be reproduced, published, or disclosed to a third party without the express permission of Honeywell Safety Management Systems.

While this information is presented in good faith and believed to be accurate, Honeywell disclaims the implied warranties of merchantability and fitness for a purpose and makes no express warranties except as may be stated in its written agreement with and for its customer.

In no event is Honeywell liable to anyone for any direct, special, or consequential damages. The information and specifications in this document are subject to change without notice.

Copyright 2005 – Honeywell Safety Management Systems, a division of Honeywell Aerospace B.V.

Honeywell trademarksSafety Manager™ is a trademark of Honeywell International Inc.

Experion PKS®, PlantScape®, SafeBrowse®, TotalPlant® and TDC 3000® are U.S. registered trademarks of Honeywell International Inc.

Other trademarksMicrosoft and SQL Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Trademarks that appear in this document are used only to the benefit of the trademark owner, with no intention of trademark infringement.

Document Release Issue DateEP-SM.MAN.6283 101 5 June 2005

iii

Support and other contacts

United States and Canada

Europe

Pacific

Contact: Honeywell IAC Solution Support Center

Phone: 1-800 822-7673. In Arizona: (602) 313-5558Calls are answered by dispatcher between 6:00 am and 4:00 pm Mountain Standard Time. Emergency calls outside normal working hours are received by an answering service and returned within one hour.

Facsimile: (602) 313-5476

Mail: Honeywell IS TAC, MS P132500 West Union Hills DrivePhoenix, AZ, 85027

Contact: Honeywell PACE TAC

Phone: +32-2-728-2657

Facsimile: +32-2-728-2278

Mail: Honeywell PACE TACAvenue du Bourget, 1B-1140 Brussels, Belgium

Contact: Honeywell Global TAC - Pacific

Phone: 1300-300-4822 (toll free within Australia)+61-2-9353-7255 (outside Australia)

Facsimile: +61-2-9353-8044

Mail: Honeywell Global TAC - Pacific5 Thomas Holt DriveNorth Ryde, NSW, 2113, Australia

Email [email protected]

iv

India

Korea

People’s Republic of China

Contact: Honeywell Global TAC - India

Phone: +91-20-687-5531

Facsimile: +91-20-687-9404

Mail: TATA Honeywell Ltd.55 A8 & 9, Hadapsar IndustrialHadapsar, Pune -411 013, India


Contact: Honeywell Global TAC - Korea

Phone: +82-2-799-6317+82-11-743-6016

Facsimile: +82-2-792-9015

Mail: Honeywell IAC SBE, CRC17F, Kikje Center B/D,191, Hangangro-2GaYongsan-gu, Seoul, 140-702, Korea


Contact: Honeywell Global TAC - China

Phone: +86-10-8458-3280 ext. 361

Mail: Honeywell Tianjin Limited17 B/F Eagle Plaza26 Xiaoyhun RoadChaoyang DistrictBeijing 100016, People's Republic of China


v

Singapore

Taiwan

Japan

ElsewhereCall your nearest Honeywell office.

Contact: Honeywell Global TAC - South East Asia

Phone: +65-580-3500

Facsimile: +65-580-3501+65-445-3033

Mail: Honeywell Private LimitedHoneywell Building17, Changi Business Park Central 1Singapore 486073


Contact: Honeywell Global TAC - Taiwan

Phone: +886-7-323-5900

Facsimile: +886-7-323-5895+886-7-322-6915

Mail: Honeywell Taiwan Ltd.10F-2/366, Po Ai First Rd.Kaohsiung, Taiwan, ROC


Contact: Honeywell Global TAC - Japan

Phone: +81-3-5440-1303

Facsimile: +81-3-5440-1430

Mail: Honeywell K.K1-14-6 Shibaura Minato-KuTokyo 105-0023Japan


vi

World Wide WebTo access Honeywell Solution Support Online, do the following:

• In your web browser, type the address http://www.honeywell.com/ps.

• Click Login to My Account and then log on.

• Move the pointer over Contacts & Support in the top menu bar and then choose Support from the popup menu.

Training classesHoneywell holds technical training classes on Safety Manager. These classes are taught by experts in the field of process control systems. For more information about these classes, contact your Honeywell representative, or see http://www.automationcollege.com.

Related DocumentationThe following guides are available for Safety Manager.

The guide in front of you is Safety Manual.

Guide DescriptionThe Overview Guide This guide describes the general knowledge required, the

basic functions of, and the tasks related to Safety Manager.

The Safety Manual This guide describes the specifications, design guidelines, and safety aspects related to Safety Manager.

The Planning and Design Guide

This guide describes the tasks related to planning and designing a Safety Manager project.

The Installation and Upgrade Guide

This guide describes the tasks related to installing, replacing and upgrading hardware and software as part of a Safety Manager project.

The Troubleshooting and Maintenance Guide

This guide describes the tasks related to troubleshooting and maintaining Safety Manager.

The System Administration Guide

This guide describes the task related to administrating the computer systems used in a Safety Manager project.

The Hardware Reference This guide specifies the hardware components that build a Safety Manager project.

vii

Task-oriented guidesA task-oriented guide provides both procedural and basic knowledge. A task can inform the reader on how to perform the task in terms of steps to follow. Additionally a task can describe what important considerations to make or what options to choose from when performing a task.

A task-oriented guide lists the required skills and knowledge that people must master to qualify for the described tasks.

It is common for task oriented guides to refer to reference guides for details.

Reference guidesA reference guide provides detailed information or solutions regarding its scope. A reference guide is a Safety Manager related guide and provides background information to support tasks as described in task-oriented guides.

A reference guide does not describe tasks in terms of how to perform the task in terms of steps to follow.

Available electronic formatAll guides are accessible via the Safety Manager Knowledge Builder; an Internet Explorer based viewer with extensive search and indexing options.

The Knowledge Builder contains guides stored as:

• web pages

• Adobe PDF guides

The information stored on the Safety Manager Knowledge Builder CD-ROM can be installed as stand-alone or merged with other Knowledge Builder booksets on a server.

The Software Reference This guide specifies the software functions that build a Safety Manager project and contains guidelines on how to operate them.

The On-line Modification Guide

This guide describes the theory, steps and tasks related to upgrading Safety Builder and embedded software and modifying an application online in a redundant Safety Manager.

Guide Description (continued)

viii

Conventions

SymbolsThe following symbols are used in Safety Manager documentation:

AttentionThis symbol is used for information that emphasizes or supplements important points of the main text.

TipThis symbol is used for useful, but not essential, suggestions.

NoteThis symbol is used to emphasize or supplement important points of the main text

CautionThis symbol warns of potential damage, such as corruption of the database.

WarningThis symbol warns of potentially hazardous situation, which, if not avoided, could result in serious injury or death.

ESDThis symbol warns for danger of an electro-static discharge to which equipment may be sensitive

ix

FontsThe following fonts are used in Safety Manager documentation:

Emphasis• “... inform the reader on how to perform

the task in terms of...”• “...see the Overview Guide”

Emphasised text is used to:• emphasise important words in the text,• identify document titles.

Label“The Advanced tab of the Properties window has..”

This font is used to identify labels. Labels are used for Dialog box labels, menu items, names of properties, and so on.

StepsTake the following steps:1. Create a plant and set its properties.2. ....

This font is used to identify steps. Steps indicate the course of action that must be adhered to, to achieve a certain goal.

User Variable

..create the My SM Projects folder and store the SM Controller here...press the Tab key.. Next press Enter to..

This font is used to:1. identify a user variable, a filename, an

object or view.2. highlight the keys the user should press on

the keyboard.User variable is a variable, an object or a view that the reader can call-up to view or to manipulate.

Value

“Low is the fault reaction state for digital inputs and digital outputs.”

This font is used to indicate a value. Value is a variable that the reader must resolve by choosing a pre-defined state.

Variable

“The syntax is: filename [-s] [-p]“This font is used to identify a variable.Variables are used in syntax and code examples.

http://www.honeywellsms.com This font is used to identify a URL, directing a reader to a website that can be referred to.

Safety Manager Safety Manual xi

Contents

1 The Safety Manual 1Content of Safety Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Basic skills and knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Prerequisite skills. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Safety standards for Process & Equipment Under Control (PUC, EUC) . . . . . . . . . . . . . . . . . . . 4Safety Integrity Level (SIL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Safety layers of protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Equipment Under Control (EUC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Process Under Control (PUC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Application design conform IEC 61131-3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7The IEC 61508 and IEC 61511 standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Introduction 11System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Certification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Standards compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15EU Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

CE marking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18EMC directive (89/336/EEC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Low voltage directive (73/23/EEC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Machine safety directive (89/392/EEC)). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Safety Manager architectures 31Safety Manager basic architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Dual Modular Redundant (DMR) architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Quadruple Modular Redundant (QMR) architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 33System architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Overall safety life cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4 Design phases for an E/E/PE safety-related system 47Specifying the safety integrity level of the process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Specifying the field instrumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Specifying the safety-related system functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Approval of the specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Contents

xii Release 101, Issue 5

5 Design and implementation phases of Safety Manager 55Safety Manager project configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Safety Manager configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Specification of input and output signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Implementation of the application software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Application verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6 Safety Manager special functions 65Forcing of IO signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Communication with third party Control systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69On-line modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7 Safety Manager fault detection and response 71Principle of fault detection and response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Principle of fault detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Principle of fault response. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Watchdog and redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Safety Manager alarm markers, registers and diagnostic inputs . . . . . . . . . . . . . . . . . . . . . . . . . 82System markers and registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Alarm markers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Diagnostic inputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

SM IO faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Digital input faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Analog input faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Digital output faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Analog output faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91IO compare errors and system response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Compare error detection and synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

SM Controller faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97QPP faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98USI faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100BKM faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101PSU faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Communication faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Calculation errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Rules of thumb with respect to safety and availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

IO settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107System settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

8 Using Safety Manager alarm markers and diagnostic inputs 111Shutdown at assertion of Safety Manager alarm markers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112Unit shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113Diagnostic status exchange with DCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117

Contents

Safety Manager Safety Manual xiii

9 Fire and gas application example 119Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120General system and Fire and Gas alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Input loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Loop status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Output loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Monitoring for alarm status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Monitoring for failure status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Inhibit function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

10 Special requirements for TUV-approved applications 143

List of abbreviations 149

Safety Manager Glossary 151

Contents

xiv Release 101, Issue 5

Safety Manager Safety Manual xv

Figures

Figure 1 The concept of layers of protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 2 Example FLD layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Figure 3 Safety Manager is the Logic Solver inside a Safety Instrumented System. . . . . . . . . . . . . . 12Figure 4 CE mark. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Figure 5 Failure model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figure 6 Programmable electronic system (PES): structure and terminology. . . . . . . . . . . . . . . . . . . 26Figure 7 Functional diagram: DMR architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figure 8 Functional diagram: QMR architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Figure 9 Functional diagram: non-redundant Controller, non-redundant IO. . . . . . . . . . . . . . . . . . . . 35Figure 10 Non-redundant Controller, non-redundant IO configuration . . . . . . . . . . . . . . . . . . . . . . . . 35Figure 11 Functional diagram: redundant Controller, non-redundant IO . . . . . . . . . . . . . . . . . . . . . . . 36Figure 12 Redundant Controller, non-redundant IO configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figure 13 Functional diagram: redundant Controller, redundant IO . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figure 14 Redundant Controller, redundant IO configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figure 15 Redundant Controller with redundant and non-redundant IO configuration . . . . . . . . . . . . 39Figure 16 Functional diagram: redundant Controller with redundant and non-redundant IO. . . . . . . . 40Figure 17 Overall safety life cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Figure 18 E/E/PES safety life cycle (in realization phase) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Figure 19 Software safety life cycle (in realization phase) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Figure 20 Relationship of overall safety life cycle to E/E/PES and software safety life cycles . . . . . . 43Figure 21 Example of Functional Logic Diagram (FLD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Figure 22 Example of a Safety Builder configurator screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Figure 23 Safety Builder Point Configurator main screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Figure 24 Example of Functional Logic Diagram (FLD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Figure 25 The forcing sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Figure 26 Schematic diagram of a SMOD with 4 channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Figure 27 Each watchdog has 2 outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Figure 28 Input failure alarm marker function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Figure 29 Intended square-root function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Figure 30 Square-root function with validated input value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Figure 31 Square-root function with validity check in function block . . . . . . . . . . . . . . . . . . . . . . . . 106Figure 32 Properties of an analog output module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Figure 33 Point detail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Figure 34 Diagram to shut down system in case of output compare error . . . . . . . . . . . . . . . . . . . . . 112Figure 35 Wiring diagram for unit shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Figure 36 Functional logic diagram of unit shutdown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Figures

xvi Release 101, Issue 5

Figure 37 Safety Manager system information to DCS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117Figure 38 FLD2000 system alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Figure 39 FLD2002 general fault alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Figure 40 FLD2004 general fire/gas alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Figure 41 FLD530 smoke detector input loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Figure 42 FLD120 gas detector input loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Figure 43 FLD230 common low level alarm Area 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Figure 44 FLD232 common F&G detector fault Area 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Figure 45 FLD240 sounders and beacons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Figure 46 FLD290 deluge valve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Figure 47 FLD162 status signals deluge valve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Figure 48 FLD160 status signals fire suppression system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Figure 49 FLD260 start firewater pump(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Figure 50 FLD262 discrepancy alarm firewater pump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Figure 51 FLD250 alarm signal to PA/GA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Figure 52 FLD680 HVAC trip signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Figure 53 FLD690 close fire damper signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Figure 54 FLD250 grouping of alarm signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Figure 55 FLD2004 Fire and Gas alarm lamp and buzzer on mimic panel. . . . . . . . . . . . . . . . . . . . . 136Figure 56 FLD240 audible and visual alarm signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Figure 57 FLD232 grouping of detector fault signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Figure 58 FLD2002 general fault alarm lamp and buzzer on mimic panel . . . . . . . . . . . . . . . . . . . . . 139Figure 59 FLD101 inhibit M-out-of-N function F&G detector devices . . . . . . . . . . . . . . . . . . . . . . . 140Figure 60 FLD234 common F&G detector inhibited Area 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Figure 61 FLD236 common F&G outputs inhibited Area 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Figure 62 Power supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Figure 63 Multidrop link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Safety Manager Safety Manual xvii

Tables

Table 1 IEC 61508 versus IEC 61511 terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Table 2 Safety Manager compliance to standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Table 3 Safety integrity levels: target failure measures for a safety function, allocated to the Safety

Instrumented System operating in low demand mode of operation . . . . . . . . . . . . . . . . . . . 27Table 4 Safety integrity levels: target failure measures for a safety function, allocated to the Safety

Instrumented System operating in high demand or continuous mode of operation . . . . . . . 27Table 5 Safety Manager architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Table 6 Overall safety life cycle overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Table 7 Example specification of IO signals of Safety Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Table 8 Relation between SIL and AK Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Table 9 Example of safety relation of IO signals with location COM . . . . . . . . . . . . . . . . . . . . . . . . 69Table 10 Fault Reaction settings for hardware IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Table 11 Fault Reaction settings for communication IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Table 12 Safety Manager™ system markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Table 13 Safety Manager system registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Table 14 Safety Manager alarm markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Table 15 Safety Manager alarm registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Table 16 Diagnostic inputs (channel status). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Table 17 Diagnostic inputs (loop status) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Table 18 Explanation of a “Controller response to faults” table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Table 19 Controller response to digital input faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Table 20 Controller response to analog input faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Table 21 Controller response to digital output fault. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Table 22 Controller response to Analog output faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Table 23 Explanation of a “Controller response to compare error” table . . . . . . . . . . . . . . . . . . . . . . 93Table 24 Controller response to IO compare faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Table 25 Explanation of a “response to Controller faults” table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Table 26 Controller response to QPP faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Table 27 Controller response to USI faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Table 28 Controller response to BKM faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Table 29 Controller response to PSU faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Table 30 Controller response to communication faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Tables

xviii Release 101, Issue 5

Safety Manager Safety Manual 1

1The Safety Manual

The Safety Manual is intended primarily for the people responsible for and performing tasks related to Safety Manager™.

This guide provides directions as how to configure and use Safety Manager the way it is intended. It provides design guidelines, lists the boundaries of Safety Manager, and advises the best hardware for certain functions.

Typical readers are all people involved in planning and design, engineering, troubleshooting and maintenance as well as operating Safety Manager.

It is assumed that the reader masters the required skills and knowledge as described herein.

This section contains the following information about this guide:

Topic SeeContent of Safety Manual page 2

Basic skills and knowledge page 3

Safety standards for Process & Equipment Under Control (PUC, EUC)

page 4

Application design conform IEC 61131-3 page 7

The IEC 61508 and IEC 61511 standards page 8

NoteThis guide does not contain information related to other Honeywell Experion™ PKS systems and third-party controllers such as Allen-Bradley, Series 9000, TDC 3000, Data Hiway, UDC, and so on.For information about these systems, see the manufacturers bookset.

1 – The Safety Manual

2 Release 101, Issue 5

Content of Safety ManualThe Safety Manual guide is a reference guide providing detailed information regarding how safety aspects are met in Safety Manager™. A reference guide is a Safety Manager related guide and does not describe tasks in terms of how to perform the task in terms of steps to follow. A reference guide can provide input to support decisions required to achieve a certain objective.

ReferencesThe following guides may be required as reference materials:

Guide subjectsSafety Manual • “Introduction” on page 11

• “Safety Manager architectures” on page 31• “Design phases for an E/E/PE safety-related system” on page 47• “Design and implementation phases of Safety Manager” on

page 55• “Safety Manager special functions” on page 65• “Safety Manager fault detection and response” on page 71• “Using Safety Manager alarm markers and diagnostic inputs” on

page 111• “Fire and gas application example” on page 119• “Special requirements for TUV-approved applications” on

page 143

Guide DescriptionThe Overview Guide This guide describes the general knowledge required, the

basic functions of, and the tasks related to Safety Manager.

The Planning and Design Guide

This guide describes the tasks related to planning and designing a Safety Manager project.

The Troubleshooting and Maintenance Guide

This guide describes the tasks related to troubleshooting and maintaining Safety Manager.

The System Administration Guide

This guide describes the task related to administrating the computer systems used in a Safety Manager project.

The Hardware Reference This guide specifies the hardware components that build a Safety Manager project.

The Software Reference This guide specifies the software functions that build a Safety Manager project and contains guidelines on how to operate them.

Basic skills and knowledge


Basic skills and knowledgeBefore performing tasks related to Safety Manager™ you need to:

• Understand basic Safety Manager concepts as explained in the Overview Guide and the Glossary.

• Have a thorough understanding of the Safety Manual.

• Have had appropriate training related to Safety Manager that certifies you for your tasks (see the Planning and Design Guide).

Prerequisite skillsWhen you perform tasks related to Safety Manager™, it is assumed that you have appropriate knowledge of:

• Site procedures

• The hardware and software you are working with. These may i.e be: computers, printers, network components, Controller and Station software.

• Microsoft Windows operating systems.

• Programmable logic controllers (PLCs).

• Applicable safety standards for Process & Equipment Under Control.

• Application design conform IEC 61131-3.

• The IEC 61508 and IEC 61511 standards.

This guide assumes that you have a basic familiarity with the process(es) connected to the equipment under control and that you have a complete understanding of the hazard and risk analysis.

TrainingMost of the skills mentioned above can be achieved by appropriate training. For more information, contact your Honeywell SMS representative or see:

• http://www.honeywellsms.com or

• http://www.automationcollege.com.




Safety Manager™ is the logic solver of a Safety Instrumented System (SIS) performing specific Safety Instrumented Functions (SIF) to ensure that risks are kept at predefined levels.

A SIS measures, independently from the Basic Process Control System (BPCS), a couple of relevant process signals like temperature, pressure, level in a tank or the flow through a pipe. The values of these signals are compared with the predefined safe values and, if needed, the SIS gives an alarm or takes action. In such cases the SIS controls the safety of the process and lowers the chance of an unsafe situation.

The logic in Safety Manager defines the response to process parameters.

In this context the following terms are explained in this section:

• Safety Integrity Level (SIL)

• Safety layers of protection

• Equipment Under Control (EUC)

• Process Under Control (PUC)

Safety Integrity Level (SIL)The IEC 61508 standard specifies 4 levels of safety performance for safety functions. These are called safety integrity levels. Safety integrity level 1 (SIL1) is the lowest level of safety integrity, and safety integrity level 4 (SIL4) the highest level. If the level is below SIL1, the IEC 61508 and IEC 61511 do not apply.

Safety Manager™ can be used for processing multiple SIFs simultaneously demanding a SIL1 upto and including SIL3.

To achieve the required safety integrity level for the E/E/PE safety-related systems, an overall safety life cycle is adopted as the technical framework (as defined in IEC 61508). For more information see inside the Safety Manual.



Safety layers of protectionFigure 1 on page 5 shows the typical risk reduction methods or safety protection layers used in modern process plants.

Safety Instrumented Systems (SIS) are designed to operate in the prevention and mitigation layers to:

• Prevent a process from entering a dangerous state.

• Mitigate the consequences of entering a dangerous state.

Equipment Under Control (EUC)Safety-related systems, such as Safety Manager™, are designed to prevent the EUC from entering a dangerous state and to mitigate any EUC that has gone into a dangerous state.

For these functions safety related system can be split in:

• Emergency shutdown systems, operating in the prevention layer of Figure 1 on page 5.

• Fire and gas detection and control systems, operating in the mitigation layer of Figure 1 on page 5.

Figure 1 The concept of layers of protection



Process Under Control (PUC)PUC is EUC expanded with regulations to prevent the process from running out of control or to mitigate the consequences when it does run out of control.

Where PUC is concerned, Safety Manager™ monitors the process for abnormal situations. Safety Manager is able to initiate safety actions and process alarms.

Such actions and alarms can be caused by abnormal situations in the:

• Process

• Safety loops

• Safety system itself

Application design conform IEC 61131-3


Application design conform IEC 61131-3The IEC 61131 standard defines, as a minimum set, the basic programming elements, syntactic and semantic rules for the most commonly used programming languages, including graphical languages of:

• Ladder Diagram,

• Functional Block Diagram and,

• Textual languages of Instruction List and structured Text;

For more information see the IEC web site.

Figure 2 on page 7 shows how Safety Manager™ uses the graphical programming method, based on Functional Block Diagram as defined by the IEC 61131-3.

Figure 2 Example FLD layout



The IEC 61508 and IEC 61511 standardsSISs have been used for many years to perform safety instrumented functions e.g. in chemical, petro-chemical and gas plants. In order for instrumentation to be effectively used for safety instrumented functions, it is essential that the instrumentation meets certain minimum standards and performance levels.

To define the characteristics, main concepts and required performance levels, standards IEC 61508 and IEC 61511 have been developed. The introduction of Safety Integrity level (SIL) is one of the results of these standards.

This brief provides a short explanation of each standard. Detailed information regarding IEC 61508 and 61511 can be found on the IEC website http://www.iec.org.

What standard to use?

• If you are in the process sector and you are an owner/user, it is strongly recommended that you pay attention to the IEC 61511 (ANSI/ISA 84.00.01). For details see “IEC 61511, the standard for the process industry” on page 9.

• If you are in the process sector and you are a manufacturer, it is strongly recommended that you pay attention to the IEC 61508. For details see “IEC 61508, the standard for all E/E/PE safety-related systems” on page 9.

• If you are in another sector, it is strongly recommended that you look for, and use, your sector specific IEC standard for functional safety (if there is one). If none exists, you can use the IEC 61508 instead. For details see “IEC 61508, the standard for all E/E/PE safety-related systems” on page 9

IEC 61508 and IEC 61511 terminologyThis guide contains both IEC 61508 and IEC 61511 related terminology.

As the IEC 61511 sits within the framework of IEC 61508 most of the terminology used may be interchanged. Table 1 on page 9 provides an overview of the most common interchangeable terminology.

Tip:You can use the IEC 61508 as stand-alone standard for those sectors where a sector specific standard does not exist.

The IEC 61508 and IEC 61511 standards


IEC 61508, the standard for all E/E/PE safety-related systemsThe IEC 61508 is called “Functional safety of electrical/electronic/programmable electronic safety-related systems”

IEC 61508 covers all safety-related systems that are electrotechnical in nature (i.e. electromechanical systems, solid-state electronic systems and computer-based systems).

Generic standardThe standard is generic and is intended to provide guidance on how to develop E/E/PE safety related devices as used in Safety Instrumented Systems (SIS).

The IEC 61508:

• serves as a basis for the development of sector standards (e.g. for the machinery sector, the process sector, the nuclear sector, etc.).

• can serve as stand-alone standard for those sectors where a sector specific standard does not exist.

SIL IEC 61508 details the design requirements for achieving the required Safety Integrity Level (SIL).

The safety integrity requirements for each individual safety function may differ. The safety function and SIL requirements are derived from the hazard analysis and the risk assessment.

The higher the level of adapted safety integrity, the lower the likelihood of dangerous failure of the SIS.

This standard also addresses the safety-related sensors and final elements regardless of the technology used.

IEC 61511, the standard for the process industryThe IEC 61511 is called “Functional safety - Safety instrumented systems for the process industry sector”. It is also referred to as the ANSI/ISA 84.00.01.

Table 1 IEC 61508 versus IEC 61511 terminology

IEC 61508 terminology IEC 61511 terminologysafety function safety instrumented function

electrical/electronic/programmable electronic (E/E/PE) safety-related system

safety instrumented system (SIS)



This standard addresses the application of SISs for the process industries. It requires a process hazard and risk assessment to be carried out, to enable the specification for SISs to be derived. In this standard a SIS includes all components and subsystems necessary to carry out the safety instrumented function from sensor(s) to final element(s).

The standard is intended to lead to a high level of consistency in underlying principles, terminology and information within the process industries. This should have both safety and economic benefits.

The IEC 61511 sits within the framework of IEC 61508.

Need to know more?For more information regarding, or help on, implementing or determining, the applied safety standards for your plant/process please contact your Honeywell affiliate. Our Safety Consultants can help you to e.g.:

• perform a hazard risk analysis

• determine the SIL requirements

• design the Safety Instrumented System

• validate and verify the design

• train your local safety staff


2Introduction

The Safety Manual describes the specifications, design guidelines, and safety aspects related to Safety Manager™.

It is created to ensure that the required safety knowledge for designing, engineering and constructing Safety Manager is transferred to the user.

This section describes the following topics:

Topic SeeSystem overview page 12

Certification page 13

Standards compliance page 15

Definitions page 22

2 – Introduction


System overviewFigure 3 on page 12 shows that Safety Manager™ is the Logic Solver, or the heart, of a Safety Instrumented System (SIS).

Safety Manager can be used in a number of different basic architectures (DMR, QMR) depending on the required availability level.

The safety of Safety Manager is obtained through its specific design for these applications. This design includes facilities for self-testing of all Safety Manager modules through software and specialized hardware based on a failure mode effect analysis (FMEA) for each module. Additional software diagnostic routines are included to guarantee proper execution of the hardware. This approach can be classified as software diversity. These features maintain the highest level of safety operation of Safety Manager even in the single-channel configurations. By placing these single-channel versions in parallel, one not only gets safety but also availability: proven availability.

Safety Manager™ and Safety Station from Honeywell SMS provide the means to guarantee optimal safety and availability. To achieve these goals, it is essential that the system is operated and maintained by authorized and qualified staff. If it is operated by unauthorized or unqualified persons, severe injuries or loss of production could be the result. This Safety Manual covers the applications of Safety Manager for Safety Integrity Levels (SIL) 1 to 3 in compliance with the international standards like IEC 61508 and IEC 61511.

Figure 3 Safety Manager is the Logic Solver inside a Safety Instrumented System

(valves, pumps, ...)Actuators

(sensing elements)Initiators

(PLC, relays)Logic Solver

TipMore overview information regarding Safety Manager can be found in the Overview Guide.

Certification


CertificationThe advantage of applying and complying to standards is obvious:

• International standards force companies to evaluate and develop their products and processes according a consistent and uniform way.

• Products certified conform these international standards guarantee a certain degree of quality and product reliability that other products lack.

Since functional safety is the core of the Safety Manager™ design, the system has been certified for use in safety applications all around the world. Safety Manager has been developed specifically to comply with the IEC61508 functional safety standards, and has been certified by TUV for use in SIL1 to SIL3 applications.

Safety Manager has also obtained certification in the United States for the UL 1998 and ANSI/ISA S84.01 standards.

For a full list of all these and other certifications see “Certification” on page 13.

CertificationSafety Manager has been certified to comply with the following standards:

International Electronical Commission (IEC) — The design and development of Safety Manager are compliant with IEC 61508 (as certified by TUV).

Instrument Society of America (ISA) — Certified to fulfill the requirements laid down in ANSI/ISA S84.01.

CE compliance — Complies with CE directives 89/336/EEC (EMC) and 73/23/EEC (Low Voltage), 89/392/EEC (Machine Safety)

European Committee for Standardization — CEN, CENELEC

2 – Introduction


Lloyds Register of Shipping — Test specification nr 1 (LRS), 96/98/EEC (EEC Marine directive)

TUV (Germany) — Certified to fulfill the requirements of SIL3 safety equipment as defined in the following documents: IEC61508, IEC60664-3, EN50156, EN 54-2, EN50178, IEC 60068, IEC 61131-2, IEC 61131-3, IEC60204.

Canadian Standards Association (CSA) — Complies with the requirements of the following standards:

• CSA Standard C22.2 No. 0-M982 General Requirements – Canadian Electrical Code, Part II;

• CSA Standard C22.2 No. 142-M1987 for Process Control Equipment.

Underwriters Laboratories (UL) — Certified to fulfill the requirements of UL 508, UL 991, UL 1998, and ANSI/ISA S84.01.

Factory Mutual (FM) — Certified to fulfill the requirements of FM 3611 and FM3600 (non-incentive field wiring circuits for selected modules and installation in Class 1 Div 2 environments).

Standards compliance


Standards complianceThis subsection lists the standards Safety Manager™ complies with, and gives some background information on the relevant CE marking (EMC directive and Low Voltage directive).

Table 2 Safety Manager compliance to standards

Standard Title RemarksIEC61508(S84.01)

Functional safety of electrical/electronic/ programmable electronic (E/E/PE) safety-related systems.

DIN V 0801 (1/90) and Amendment A (10/94)

Principles for computers in safety-related systems.(German title: Grundsätze für Rechner in Systemen mit Sicherheitsaufgaben)

Microprocessor-based safety systems.

VDE 0116 (10/89) Electrical equipment of furnaces.(German title: Elektrische Ausrüstung von Feuerungsanlagen)

EN 54 part 2 (01/90)

Components of automatic fire detection systems, Introduction.(German title: Bestandteile automatischer Brandmeldeanlagen)

EN 50081-2-1994 Electromagnetic compatibility – Generic emission standard, Part 2: Industrial environment.

EN 50082-2-1995 Electromagnetic compatibility – Generic immunity standard, Part 2: Industrial environment.

IEC 61010-1-1993 Safety Requirements for Electrical Equipment for Measurement, Control and Laboratory Use, Part 1: General Requirements.

IEC 61131-2-1994 Programmable controllers. Part 2: Equipment requirements and tests.

UL 1998 Safety-related software, first edition.

Underwriters Laboratories.

UL 508 Industrial control equipment, sixteenth edition.


2 – Introduction


UL 991 Test for safety-related controls employing solid-state devices, second edition.


FM3600, FM 3611Class I, Division 2, Groups A, B, C & DClass II, Division 2, Groups F & G

Electrical equipment for use in• Class I, Division 2,• Class II, Division 2, and• Class III, Division 1 and 2,

hazardous locations.

Factory Mutual Research.Applies to the field wiring circuits of the following modules:SDI-1624, SAI-0410, SAI-1620m, SDIL-1608 and SAO-0220m, and installation of the Controller in these environments.

CSA C22.2 Process control equipment. Industrial products.

Canadian Standards Association No. 142 (R1993).

IEC 60068-1 Basic environmental testing procedures.

IEC 60068-2-1 Cold test. 0°C (32°F); 16 hours; system in operation; reduced power supply voltage:(–15%): U=20.4 Vdc or (–10%): U=198 Vac.

IEC 60068-2-1 Cold test. –10°C (14°F); 16 hours; system in operation.

IEC 60068-2-2 Dry heat test. up to 65°C (149°F); 16 hours; system in operation; increased power supply voltage:(+15%): U=27.6 Vdc or(+10%): U=242 Vac.

IEC 60068-2-3 Test Ca: damp heat, steady state. 21 days at +40°C (104°F), 93% relative humidity; function test after cooling.

IEC 60068-2-3 Test Ca: damp heat, steady state. 96 hours at +40°C (104°F), 93% relative humidity; system in operation.

IEC 60068-2-14 Test Na: change of temperature – withstand test.

–25°C—+55°C (–13°F—+131°F), 12 hours, 95% relative humidity, recovery time: max. 2 hours.


Standard Title Remarks

Standards compliance


IEC 60068-2-30 Test Db variant 2: cyclic damp heat test.

+25°C—+55°C (+77°F—+131°F), 48 hours, 80-100% relative humidity, recovery time: 1—2 hours.

IEC 60068-2-6 Environmental testing – Part 2:Tests – Test.Fc: vibration (sinusoidal).

Excitation: sine-shaped with sliding frequency;Frequency range: 10—150 Hz.Loads:• 10—57 Hz; 0.075 mm.• 57—150 Hz; 1 G.Duration: 10 cycles (20 sweeps) per axis.No. of axes: 3 (x, y, z).Traverse rate: 1 oct/min in operation.

IEC 60068-2-27 Environmental testing – Part 2:Tests – Test.Ea: shock.

Half sine shock.2 shocks per 3 axes (6 in total).Maximum acceleration: 15 G.Shock duration: 11 ms.Safety Manager in operation.


Standard Title Remarks

2 – Introduction


EU StandardsThis section explains the major EU standards that apply to Safety Manager™.

These standards are:

CE markingThe CE mark (see Figure 4 on page 18) is a compliance symbol, which indicates that a product meets the requirements of the EU directives that apply to that product. CE (Conformité Européenne) marking is a legal requirement for selling products in the European Union.

EU directives documentation is issued on the authority of the Council of the European Union. It contains requirements and regulations for certain categories of products or problem areas. The directives apply not only to member countries of the European Union but also to the whole European Economic Area (EEA).

The European directives have the following key objectives:

• Free movement of goods within the EU/EEA geographical regions through harmonization of standards and elimination of trade barriers.

• Safety of persons, their property and of animals.

• Protection of the environment.

For control products like Safety Manager™, a number of EU directives apply. Safety Manager is compliant with: the Electromagnetic Compatibility (EMC) Directive (89/336/EEC), the Low Voltage Directive (73/23/EEC), Marine Directive (96/98/EEC) and Machine Safety Directive (89/392/EEC). Some are

Topic SeeCE marking page 18

EMC directive (89/336/EEC) page 19

Low voltage directive (73/23/EEC) page 20

Machine safety directive (89/392/EEC)) page 20

Figure 4 CE mark

EU Standards


discussed in more detail below. An item of equipment may only display the CE mark when the equipment satisfies all relevant directives.

EMC directive (89/336/EEC)One of the EU directives Safety Manager™ complies with is the EMC directive, or Council Directive 89/336/EEC of 3 May 1989 on the approximation of the laws of the Member States relating to electromagnetic compatibility as it is officially called. It “applies to apparatus liable to cause electromagnetic disturbance or the performance of which is liable to be affected by such disturbance” (Article 2).

The EMC directive defines protection requirements and inspection procedures relating to electromagnetic compatibility for a wide range of electric and electronic items.

Within the context of the EMC directive, ‘apparatus’ means all electrical and electronic appliances together with equipment and installations containing electrical and/or electronic components. ‘Electromagnetic disturbance’ means any electromagnetic phenomenon which may degrade the performance of a device, unit of equipment or system. An electromagnetic disturbance may be electromagnetic noise, an unwanted signal or a change in the propagation medium itself.

‘Electromagnetic compatibility’ is the ability of a device, unit of equipment or system to function satisfactorily in its electromagnetic environment without introducing intolerable electromagnetic disturbances to anything in that environment.

There are two sides to electromagnetic compatibility: emission and immunity. These two essential requirements are set forth in Article 4, which states that an apparatus must be constructed so that:

1. The generated electromagnetic disturbance does not exceed a level allowing radio and telecommunications equipment and other apparatus to operate as intended.

2. The apparatus has an adequate level of intrinsic immunity of electromagnetic disturbance to enable it to operate as intended.

The EMC directive was originally published in the Official Journal of the European Communities on May 23, 1989. As of January 1, 1996 compliance with the EMC directive is mandatory (a legal requirement). All electronic products may now only be marketed in the European Union if they meet the requirements laid down in the EMC directive. This also applies to Safety Manager cabinets.

2 – Introduction


Low voltage directive (73/23/EEC)Safety Manager™ also complies with the low voltage directive, or Council Directive 73/23/EEC of 19 February 1973 on the harmonization of the laws of the Member States relating to electrical equipment designed for use within certain voltage limits as it is officially called. It states that “electrical equipment may be placed on the market only if, having been constructed in accordance with good engineering practice in safety matters in force in the Community, it does not endanger the safety of persons, domestic animals or property when properly installed and maintained and used in applications for which it was made” (Article 2).

The low voltage directive defines a number of principal safety objectives that electrical equipment must meet in order to be considered “safe”.

Within the context of the low voltage directive, ‘electrical equipment’ means any equipment designed for use with a voltage rating of between 50 and 1,000 V for alternating current (AC) and between 75 and 1,500 V for direct current (DC).

The low voltage directive was originally published in the Official Journal of the European Communities on March 26, 1973. It was amended by Council Directive 93/68/EEC. As of January 1, 1997 compliance with the low voltage directive is mandatory (a legal requirement). All electronic products may now only be marketed in the European Union if they meet the requirements laid down in the low voltage directive. This also applies to Safety Manager cabinets.

Machine safety directive (89/392/EEC))The directive holds the requirements for machinery safety in every country within the European Economic Area (EEA). The Directive applies to all machinery and to safety components. A machine is defined as “an assembly of linked parts or components, at least one of which moves…”

Machinery meeting the requirements of the Directive is required to have the CE symbol clearly affixed to indicate compliance. An item of equipment may only display the CE mark when the equipment satisfies all relevant directives.

The Directive requires the machines manufacturer to produce a Technical File containing documentary evidence that the machinery complies with the directive. The Directive also effectively allows a period of grace in which the file can be assembled after it has been requested by the authorities.

The Directive gives a comprehensive list of the potential hazards (annex I) which may arise from the design and operation of machinery, and gives general instructions on what hazards must be avoided. Detailed requirements are laid out in a series of safety standards.

EU Standards


Because so many standards are required to cover the full range of machines within the scope of the Directive, the European standards bodies devised a hierarchy which can be applied in every situation:

• ‘Type A’ are the most basic standards set out the requirements for the safety of machines only in the most general terms: part 2 of EN292 is essentially a reproduction of annex 1 of the Machinery Directive.

• ‘Type B’ standards deal with more specific issues: design of emergency stops (EN418); prevention of unexpected start-up (EN1037); pneumatic systems (EN983); temperature of touchable surfaces (EN563) and many others.

• ‘Type C’ standards deal with specific classes of machinery: for example, EN1012 deals with safety of compressors and vacuum pumps; EN 792 deals with pneumatic hand tools.

2 – Introduction


DefinitionsThis section provides a list of essential safety terms that apply to Safety Manager™. All definitions have been taken from IEC 61508-4, published in 2000.

Dangerous failureFailure which has the potential to put the safety-related system in a hazardous or fail-to-function state.

ErrorDiscrepancy between a computed, observed or measured value or condition and the true, specified or theoretically correct value or condition.

EUC riskRisk arising from the EUC or its interaction with the EUC control system.

FailureThe termination of the ability of a functional unit to perform a required function.

NoteWhether or not the potential is realized may depend on the channel architecture of the system; in systems with multiple channels to improve safety, a dangerous hardware failure is less likely to lead to the overall dangerous or fail-to-function state.

Note• The definition in IEV 191-04-01 is the same, with additional notes.• See Figure 5 on page 23 for the relationship between faults and failures, both in

IEC 61508 and IEV 191.• Performance of required functions necessarily excludes certain behavior, and some

functions may be specified in terms of behavior to be avoided. The occurrence of such behavior is a failure.

• Failures are either random (in hardware) or systematic (in hardware or software).

Definitions


FaultAbnormal condition that may cause a reduction in, or loss of, the capability of a functional unit to perform a required function.

Functional safetyPart of the overall safety relating to the EUC and the EUC control system which depends on the correct functioning of the E/E/PE safety-related systems, other technology safety-related systems and external risk reduction facilities.

NoteIEV 191-05-01 defines “fault” as a state characterized by the inability to perform a required function, excluding the inability during preventative maintenance or other planned actions, or due to lack of external resources.

Figure 5 Failure model

A) Configuration of a Functional Unit

L (i-1) FU

L= level, i=1,2,3, etc.; FU=Functional Unit

L (i+1) FU L (i+1) FU

L (i+1) FUL (i+1) FU

L (i FUL (i+1) FU L (i+1) FU

L (i+1) FUL (i+1) FU

L (i FU

B) Generalized view

"Entity X"

Level(i) Level(i-1)

cause

failure"F" state

cause

failure"F" state

C) IEC 61508's and ISO/IEC 2382-14's view

"Entity X"

Level(i) Level(i-1)

fault

failure fault

failure

D) IEC 50(191)'s view

"Entity X"

Level(i) Level(i-1)

failure cause

failure failure cause

failure

fault

fault

2 – Introduction


Functional safety assessmentInvestigation, based on evidence, to judge the functional safety achieved by one or more E/E/PE safety-related systems, other technology safety-related systems or external risk reduction facilities.

Human errorMistake.

Human action or inaction that produces an unintended result.

Hardware safety integrityPart of the safety integrity of the Safety Instrumented Systems (SIS) relating to random hardware failures in a dangerous mode of failure.

Notes for Figure 5 on page 23• As shown in A), a functional unit can be viewed as a hierarchical composition of

multiple levels, each of which can in turn be called a functional unit. In level (i), a “cause” may manifest itself as an error (a deviation from the correct value or state) within this level (i) functional unit, and, if not corrected or circumvented, may cause a failure of this functional unit, as a result of which it falls into an “F” state where it is no longer able to perform a required function (see B)). This “F” state of the level (i) functional unit may in turn manifest itself as an error in the level (i-1) functional unit and, if not corrected or circumvented, may cause a failure of this level (i-1) functional unit.

• In this cause and effect chain the same thing (“Entity X”) can be viewed as a state (“F” state) of the level (i) functional unit into which it has fallen as a result of its failure, and also as the cause of the level (i-1) functional unit. This “Entity X” combines the concept of “fault” in IEC 61508 and ISO/IEC 2382-14, which emphasizes its cause aspect as illustrated in C), and that of “fault” in IEC 50(191), which emphasizes its state aspect as illustrated in D). The “F” state is called fault in IEC 50(191), whereas it is not defined in IEC 61508 and ISO/IEC 2382-14.

• In some cases, a failure may be caused by an external event such as lightning or electrostatic noise, rather than by an internal fault. Likewise, a fault (in both vocabularies) may exist without a prior failure. An example of such a fault is a design fault.

NoteThe term relates to failures in a dangerous mode. That is, those failures of a safety-related system that would impair its safety integrity. The two parameters that are relevant in this context are the overall dangerous failure rate and the probability of failure to operate on demand. The former reliability parameter is used when it is necessary to maintain continuous control in order to maintain safety, the latter reliability parameter is used in the context of safety-related protection systems.

Definitions


Mode of operationWay in which a safety-related system is intended to be used, with respect to the frequency of demands made upon it in relation to the proof check frequency, which may be either:

• Low demand mode - where the frequency of demands for operation made on a safety-related system is not significantly greater than the proof check frequency; or

• High demand or continuous mode - where the frequency of demands for operation made on a safety-related system is significantly greater than the proof check frequency.

Programmable electronic system (PES)System for control, protection or monitoring based on one or more programmable electronic devices, including all elements of the system such as power supplies, sensors and other input devices, data highways and other communication paths, and actuators and other output devices (see Figure 6 on page 26).

NoteTypically for low demand mode, the frequency of demands on the safety-related system is the same order of magnitude as the proof test frequency (i.e. months to years where the proof test interval is a year). While typically for high demand or continuous mode, the frequency of demands on the safety-related system is hundreds of times the proof test frequency (i.e. minutes to hours where the proof test interval is a month).

NoteThe structure of a PES is shown in Programmable electronic system (PES): structure and terminology A). Programmable electronic system (PES): structure and terminology B) illustrates the way in which a PES is represented in IEC 61508, with the programmable electronics shown as a unit distinct from sensors and actuators on the EUC and their interfaces, but the programmable electronics could exist at several places in the PES. Programmable electronic system (PES): structure and terminology C) illustrates a PES with two discrete units of programmable electronics. Programmable electronic system (PES): structure and terminology D) illustrates a PES with dual programmable electronics (i.e. two channel), but with a single sensor and a single actuator.

2 – Introduction


RiskCombination of the probability of occurrence of harm and the severity of that harm.

Safe failureFailure which does not have the potential to put the safety-related system in a hazardous or fail-to-function state.

SafetyFreedom from unacceptable risk.

Safety integrity level (SIL)Discrete level (one out of a possible four) for specifying the safety integrity requirements of the safety functions to be allocated to the E/E/PE safety-related

Figure 6 Programmable electronic system (PES): structure and terminology

Extend of PES

Input interfacesA-D converters Communications

Output interfacesD-A converters

Output devices/final elements(eg actuators)

Input devices(eg sensors)

A) Basic PES structure

Programmable electronics(see note)

PE PE1 2PE1PE

PE2

B) Single PES with single program-mable electronic device (ie one PES

comprised of a single channel ofprogrammable electronics)

C) Single PES with dual program-mable electronic devices linked in aserial manner (eg intelligent sensor

and programmable controller)

D) Single PES with dual program-mable electronic devices but with

shared sensors and final elements (ieone PES comprised of two channels

of programmable electronics)

NoteWhether or not the potential is realized may depend on the channel architecture of the system; in systems with multiple channels to improve safety, a safe hardware failure is less likely to result in an erroneous shutdown.

Definitions


systems, where safety integrity level 4 has the highest level of safety integrity and safety integrity level 1 has the lowest.

Note• The target failure measures for the safety integrity levels are specified in Safety

integrity levels: target failure measures for a safety function, allocated to the Safety Instrumented System operating in low demand mode of operation and Safety integrity levels: target failure measures for a safety function, allocated to the Safety Instrumented System operating in high demand or continuous mode of operation.

Table 3 Safety integrity levels: target failure measures for a safety function, allocated to the Safety Instrumented System operating in low demand mode of operation

Safety integrity level Low demand mode of operation(average probability of failure to perform its design function on demand)

4 ≥ 10-5 to < 10-4

3 ≥ 10-4 to < 10-3

2 ≥ 10-3 to < 10-2

1 ≥ 10-2 to < 10-1

NOTE: see notes below for details on interpreting this table.

Table 4 Safety integrity levels: target failure measures for a safety function, allocated to the Safety Instrumented System operating in high demand or continuous mode of operation

Safety integrity level High demand or continuous mode of operation (probability of a dangerous failure per hour)

4 ≥ 10-9 to < 10-8

3 ≥ 10-8 to < 10-7

2 ≥ 10-7 to < 10-6

1 ≥ 10-6 to < 10-5

NOTE: see notes below for details on interpreting this table.

2 – Introduction


Safety life cycleNecessary activities involved in the implementation of safety-related systems, occurring during a period of time that starts at the concept phase of a project and finishes when all of the E/E/PE safety-related systems, other technology safety-related systems and external risk reduction facilities are no longer available for use.

Safety-related systemDesignated system that both:

• implements the required safety functions necessary to achieve or maintain a safe state for the EUC, and

Note1. The parameter in Safety integrity levels: target failure measures for a safety function,

allocated to the Safety Instrumented System operating in high demand or continuous mode of operation, probability of a dangerous failure per hour, is sometimes referred to as the frequency of dangerous failures, or dangerous failure rate, in units of dangerous failures per hour.

2. This document sets a lower limit on the target failure measures, in a dangerous mode of failure, than can be claimed. These are specified as the lower limits for safety integrity level 4 (that is an average probability of failure of 10-5 to perform its design function on demand, or a probability of a dangerous failure of 10-9 per hour). It may be possible to achieve designs of safety-related systems with lower values for the target failure measures for non-complex systems, but it is considered that the figures in the table represent the limit of what can be achieved for relatively complex systems (for example programmable electronic safety-related systems) at the present time.

3. The target failure measures that can be claimed when two or more E/E/PE safety-related systems are used may be better than those indicated in Safety integrity levels: target failure measures for a safety function, allocated to the Safety Instrumented System operating in low demand mode of operation and Safety integrity levels: target failure measures for a safety function, allocated to the Safety Instrumented System operating in high demand or continuous mode of operation providing that adequate levels of independence are achieved.

4. It is important to note that the failure measures for safety integrity levels 1, 2, 3 and 4 are target failure measures. It is accepted that only with respect to the hardware safety integrity will it be possible to quantify and apply reliability prediction techniques in assessing whether the target failure measures have been met. Qualitative techniques and judgements have to be made with respect to the precautions necessary to meet the target failure measures with respect to the systematic safety integrity.

5. The safety integrity requirements for each safety function shall be qualified to indicate whether each target safety integrity parameter is either:

• the average probability of failure to perform its design function on demand (for a low demand mode of operation); or

• the probability of a dangerous failure per hour (for a high demand or continuous mode of operation).

Definitions


• is intended to achieve, on its own or with other E/E/PE safety-related systems, other technology safety-related systems or external risk reduction facilities, the necessary safety integrity for the required safety functions.

Note1. The term refers to those systems, designated as safety-related systems, that are

intended to achieve, together with the external risk reduction facilities, the necessary risk reduction in order to meet the required tolerable risk.

2. The safety-related systems are designed to prevent the EUC from going into a dangerous state by taking appropriate action on receipt of commands. The failure of a safety-related system would be included in the events leading to the identified hazard or hazards. Although there may be other systems having safety functions, it is the safety-related systems that have been designated to achieve, in their own right, the required tolerable risk. Safety-related systems can broadly be divided into safety-related control systems and safety-related protection systems, and have two modes of operation.

3. Safety-related systems may be an integral part of the EUC control system or may interface with the EUC by sensors and/or actuators. That is, the required safety integrity level may be achieved by implementing the safety functions in the EUC control system (and possibly by additional separate and independent systems as well) or the safety functions may be implemented by separate and independent systems dedicated to safety.

4. A safety-related system may:• be designed to prevent the hazardous event (that is if the safety-related systems

perform their safety functions then no hazard arises). The key factor here is the ensuring that the safety-related systems perform their functions with the degree of certainty required (for example, for the specified functions, that the average probability of failure should not be greater than 10-4 to perform its design function on demand).

• be designed to mitigate the effects of the hazardous event, thereby reducing the risk by reducing the consequences. As for the first item in this list, the probability of failure on demand for the specified functions (or other appropriate statistical measure) should be met.

• be designed to achieve a combination of both kinds of systems.5. A person can be part of a safety-related system. For example, a person could receive

information from a programmable electronic device and perform a safety task based on this information, or perform a safety task through a programmable electronic device.

6. The term includes all the hardware, software and supporting services (for example power supplies) necessary to carry out the specified safety function (sensors, other input devices, final elements (actuators) and other output devices are therefore included in the safety-related system).

7. A safety-related system may be based on a wide range of technologies including electrical, electronic, programmable electronic, hydraulic and pneumatic.

2 – Introduction


Systematic safety integrityPart of the safety integrity of safety-related systems relating to systematic failures in a dangerous mode of failure.

ValidationConfirmation by examination and provision of objective evidence that the particular requirements for a specific intended use are fulfilled.

NoteSystematic safety integrity cannot usually be quantified (as distinct from hardware safety integrity which usually can).


3Safety Manager architectures

To optimize Safety Manager™ for different types of processes (such as batch processing and continues processing), the system can be supplied in a number of architectures, each with its own characteristics and typical applications.

This section provides information on the Safety Manager architectures. It covers the following topics:

To optimize the choice for a certain system architecture, the availability level is stated next to the type of architecture.

Topic SeeSafety Manager basic architectures page 32

Dual Modular Redundant (DMR) architecture page 32

Quadruple Modular Redundant (QMR) architecture page 33

Topic Availability level SeeSystem architectures: page 34

• Non-redundant Controller and non-redundant IO normal page 34

• Redundant Controller and non-redundant IO increased page 35

• Redundant Controller and redundant IO optimal page 37

• Redundant Controller with redundant and non-redundant IO

optimal page 39

3 – Safety Manager architectures


Safety Manager basic architecturesSafety Manager™ can be configured for a number of architectures, each with its own characteristics and typical Safety Instrumented Functions. Table 5 on page 32 provides an overview of the available architectures.

All Safety Manager architectures can support Safety Instrumented Functions upto SIL3. The preferred architecture depends on the availability requirements.

Dual Modular Redundant (DMR) architectureTypical applications of a DMR architecture are:

• Burner Management System

• Batch processing

• Machine protection

The Dual Modular Redundant (DMR) architecture provides 1oo2 voting in a non-redundant system. The DMR architecture with 1oo2 voting is based on dual-processor technology, and is characterized by a high level of self tests, diagnostics and fault tolerance.

The DMR architecture is realized with a non-redundant Controller. A non-redundant architecture contains only one QPP (see Figure 7 on page 33), which contains a redundant processor with 1oo2 voting between the processors and memory.

Table 5 Safety Manager architectures

Controllerconfiguration

IO configuration Remarks

Non-redundant(DMR, see page 32)

Non-redundant, see page 34 DMR architecture; Supports SIF up to SIL3

Redundant(QMR, see page 33)

• Non-redundant, see page 35• Redundant, see page 37• Redundant and non-redundant,

see page 39

QMR architecture; Supports SIF up to SIL3

DMR = Dual Modular Redundant

QMR = Quadruple Modular Redundant

SIF = Safety Instrumented Function

Safety Manager basic architectures


In IO configurations, each path is primarily controlled by the Control Processor and an independent switch (Secondary Means of De-energization, SMOD) which is controlled by an independent watchdog.

Quadruple Modular Redundant (QMR) architectureTypical applications of a QMR architecture are:

• process safeguarding applications for which continues operation is essential.

The Quadruple Modular Redundant (QMR) architecture is based on 2oo4D voting, dual-processor technology in each QPP. This means that it is characterized by a ultimate level of self diagnostics and fault tolerance.

The QMR architecture is realized with a redundant Controller. This redundant architecture contains two QPPs (see Figure 8 on page 34), which results in quadruple redundancy making it dual fault tolerant for safety.

The 2oo4D voting is realized by combining 1oo2 voting of both CPUs and memory in each QPP, and 1oo2D voting between the two QPPs. Voting takes place on two levels: on a module level and between the QPPs.

Figure 7 Functional diagram: DMR architecture

Processor

Processor

Watchdog

QPP Control ProcessorSD

Input Interfaces Output Interfaces

InputModule

Sensor

xxyyy

Final Element

SMOD

OutputModule



In redundant IO configurations, each path is controlled by one of the Control Processors and an independent switch (Secondary Means of De-energization, SMOD), which is controlled by the diagnostic software and an independent watchdog.

Furthermore, each Control Processor is able to switch off the output channels of the other Control Processor.

System architectures

Non-redundant Controller and non-redundant IOThis Safety Manager™ architecture has a non-redundant Controller and non-redundant input and output (IO) modules (see Figure 10 on page 35 and Figure 9 on page 35).

The IO modules are controlled via the IO bus drivers (located in the QPP) and the IO Bus, which can control up to 8 IO chassis per cabinet. Each IO chassis is controlled via the IO Extender. There is no redundancy except for those modules with built-in redundancy (QPP, memory and watchdog).

This architecture can be used for Safety Instrumented Functions up to SIL3.

Figure 8 Functional diagram: QMR architecture

InputModule

InputModule

Processor

Processor

Watchdog

QPP Control Processor 1


SD

Input Interfaces

SMOD

OutputModule

Final ElementOutput Interfaces

SMOD

OutputModule

QuadVoter

Processor

Processor

Watchdog

Sensor

xxyyy



Redundant Controller and non-redundant IOThis Safety Manager architecture has a redundant Controller and non-redundant input and output (IO) modules (see Figure 12 on page 36 and Figure 11 on page 36).

The IO modules are controlled via the IO bus drivers (located in the QPP) and the IO Bus, which can control up to 8 IO chassis per cabinet. Each IO chassis is controlled via the IO Extender.


Figure 9 Functional diagram: non-redundant Controller, non-redundant IO

Figure 10 Non-redundant Controller, non-redundant IO configuration

Processor

Processor

Watchdog

QPP Control ProcessorSD


InputModule

Sensor

xxyyy

Final Element

SMOD

OutputModule

I/O-B

us

Control Processor

I/O-Bus

QPP

System Bus

I/O Chassis 1 I/O Extender

21 21

COM BKMPSUCOM

SDI SDO SDI SDO



Interaction between Control ProcessorsBoth Control Processors run in parallel, meaning that they simultaneously read input states and write output states. Via the redundant link both Control Processors continuously inform each other about the achieved IO states, application states. The redundant link is used to synchronize actions and compare results. For more information see “Quadruple Modular Redundant (QMR) architecture” on page 33.

A redundant Controller is single fault tolerant with respect to availability.

Figure 11 Functional diagram: redundant Controller, non-redundant IO

Figure 12 Redundant Controller, non-redundant IO configuration

Processor

Processor

Watchdog



SD


Processor

Processor

Watchdog

InputModule

Final Element

SMOD

OutputModule

Sensor

xxyyy

I/O-B

us

Control Processor 1 Control Processor 2

I/O-Bus

QPP

System Bus

I/O Chassis n+1 I/O Extender

21 21

QPPCOM BKMPSUCOM COM PSUCOM

SDI SDO SDI SDO



Redundant Controller and redundant IOThis Safety Manager architecture has a redundant Controller and redundant input and output (IO) modules (OR function outputs) (see Figure 14 on page 38 and Figure 13 on page 38).

The IO modules are controlled via the IO bus drivers (located in the QPP) and the IO Bus, which can control up to 8 IO chassis per cabinet. Each IO chassis is controlled via the IO Extender. The processor and IO are fully redundant, which allows continuous operation and smooth (zero-delay) transfer of the control in case of a Control Processor or IO failure.


Interaction between Control ProcessorsBoth Control Processors run in parallel, meaning that they simultaneously read input states and write output states. Via the redundant link both Control Processors continuously inform each other about the achieved IO states, application states. The redundant link is used to synchronize actions and compare results. For more information see “Quadruple Modular Redundant (QMR) architecture” on page 33.

Interaction between redundant IOBoth IO modules reside next to each other in the same IO chassis. On the backplane they are wired parallel.

• In principle, when a fault is detected in an input channel, this channel is deactivated by its corresponding Control Processor. The correct value is obtained from the IO module connected to the other Control Processor via the redundant internal link before the application cycle is started.

• In principle, when a fault is detected in an output channel, this channel is de-energized by the SMOD (see “Secondary means” on page 25 for details). The correct value is driven into the field by the other Control Processor, but not after both Control Processors have agreed on its value via the redundant internal link.

For more information see “Fault detection and response” on page 23.



Figure 13 Functional diagram: redundant Controller, redundant IO

Figure 14 Redundant Controller, redundant IO configuration

InputModule

InputModule

Processor

Processor

Watchdog



SD

Input Interfaces

SMOD

OutputModule

Final ElementOutput Interfaces

SMOD

OutputModule

QuadVoter

Processor

Processor

Watchdog

Sensor

xxyyy

I/O Chassis n

I/O Chassis 1 I/O- B

usControl Processor 1 Control Processor 2

I/O-Bus

QPP

System Bus

2 21201 17 18

I/OEXTENDER

I/OEXTENDER

I/OEXTENDER

QPPCOM BKMPSU

SDI SDI

COM COM PSUCOM

SDI SDI

SDO SDO

SDO SDO

I/OEXTENDER



Redundant Controller with redundant and non-redundant IOThis Safety Manager architecture has a redundant Controller and redundant input and output (IO) modules (OR function outputs) combined with non-redundant input and output modules (see Figure 15 on page 39 and Figure 16 on page 40).

This architecture can be applied up to SIL3.

This architecture is a mix of the described:

• “Redundant Controller and non-redundant IO” on page 35 and

• “Redundant Controller and redundant IO” on page 37.

Selective watchdogIn a system with combined redundant and non redundant IO 3 watchdog lines are active:

• WD1 This is the Watchdog line dedicated for Control Processor 1.

- De-energizes upon a safety related fault in Control Processor 1 or an output module of Control Processor 1.

- When de-energized, Control Processor 1 and the related outputs are halted.

Figure 15 Redundant Controller with redundant and non-redundant IO configuration

I/O Chassis n

I/O Chassis 1 I/O-B

u s

Control Processor 1 Control Processor 2

I/O-Bus

QPP

System Bus

2 21201 17 18

I/OEXTENDER

I/O Chassis n+1

I/OEXTENDER

I/OEXTENDER

I/O Extender

21 21

QPPCOM BKMPSU

SDI SDI

COM COM PSUCOM

SDI SDI

SDO SDO

SDI SDO

SDO SDO

SDI SDO

I/OEXTENDER



• WD2 This is the Watchdog line dedicated for Control Processor 2.

- De-energizes upon a safety related fault in Control Processor 2 or an output module of Control Processor 2.

- When de-energized, Control Processor 2 and the related outputs are halted.

• WD3This is the combined watchdog line, controlled by both Control Processors.

- De-energizes upon a safety related fault in a non redundant output.

- When de-energized, the non-redundant outputs are de-energized, but the redundant outputs and the Control Processors remain operational.

Figure 16 Functional diagram: redundant Controller with redundant and non-redundant IO

InputModule

InputModule

Processor

Processor

Watchdog



SD

Input Interfaces

SMOD

OutputModule

Final Element

Output Interfaces

SMOD

OutputModule

QuadVoter

Processor

Processor

Watchdog

InputModule

Final Element

SMOD

OutputModule

Sensor

xxyyy

Sensor

xxyyy

Overall safety life cycle


Overall safety life cycleTo deal in a systematic manner with all the activities necessary to achieve the required safety integrity level for the E/E/PE safety-related systems, an overall safety life cycle is adopted as the technical framework (as defined in IEC 61508) (see Figure 17 on page 41).

Figure 17 Overall safety life cycle



The overall safety life cycle encompasses the following risk reduction measures:

• E/E/PE safety-related systems

• Other technology safety-related systems

• External risk reduction facilities

The portion of the overall safety life cycle dealing with E/E/PE safety-related systems is expanded and shown in Figure 18 on page 42. The software safety life cycle is shown in Figure 19 on page 43. The relationship of the overall safety life cycle to the E/E/PES and software safety life cycles for safety-related systems is shown in Figure 20 on page 43.

Note• Activities relating to verification, management of functional safety and functional

safety assessment are not shown for reasons of clarity. These activities are relevant to all overall, E/E/PES and software safety life cycle phases.

• The phases represented by boxes 10 and 11 are outside the scope of this manual.• Parts 2 and 3 deal with box 9 (realization) but they also deal, where relevant, with the

programmable electronic (hardware and software) aspects of boxes 13, 14 and 15.

Figure 18 E/E/PES safety life cycle (in realization phase)



The overall, E/E/PES and software safety life cycle figures (Figure 17 on page 41, Figure 18 on page 42 and Figure 19 on page 43) are simplified views of the reality and as such do not show all the iterations relating to specific phases or between phases. The iterative process, however, is an essential and vital part of development through the overall, E/E/PES and software safety life cycles.

Figure 19 Software safety life cycle (in realization phase)

Figure 20 Relationship of overall safety life cycle to E/E/PES and software safety life cycles



ObjectivesTable 6 on page 44 indicates the objectives to be achieved for all phases of the overall safety life cycle (Figure 18 on page 42).

Table 6 Overall safety life cycle overview

Phase Objective Overall safety life cycle box number

Concept • To develop a level of understanding of the EUC and its environment (physical, legislative etc.) sufficient to enable the other safety life cycle activities to be satisfactorily carried out.

1

Overall scope definition

• To determine the boundary of the EUC and the EUC control system.

• To define the scope of the hazard and risk analysis (for example process hazards, environmental hazards, etc.).

2

Hazard and risk analysis

• To identify the hazards and hazardous events of the EUC and the EUC control system (in all modes of operation), for all reasonably foreseeable circumstances including fault conditions and misuse.

• To identify the event sequences leading to the hazardous events identified.

• To determine the EUC risks associated with the hazardous events identified.

3

Overall safety requirements

• To develop the specification for the overall safety requirements to achieve the required functional safety. These specifications contain the safety functions requirements and safety integrity requirements, for the E/E/PE safety-related systems, other technology safety-related systems and external risk reduction facilities.

4

Safety requirements allocation

• To allocate the safety functions to the designated E/E/PE safety-related systems, other technology safety-related systems and external risk reduction facilities.

• To allocate a risk reduction value to each safety function.

5



Overall operation and maintenance planning

• To develop a plan for operating and maintaining the E/E/PE safety-related systems, to ensure that the required functional safety is maintained during operation and maintenance.

6

Overall safety validation planning

• To develop a plan to facilitate the overall safety validation of the E/E/PE safety-related systems.

7

Overall installation and commissioning planning

• To develop a plan for the installation of the E/E/PE safety-related systems in a controlled manner, to ensure the required functional safety is achieved.

• To develop a plan for the commissioning of the E/E/PE safety-related systems in a controlled manner, to ensure the required functional safety is achieved.

8

E/E/PE safety-related systems: realization

• To create E/E/PE safety-related systems conforming to the specification for the E/E/PES safety requirements.

9

Other technology safety-related systems: realization

• To create other technology safety-related systems to meet the safety functions requirements and safety integrity requirements specified for such systems.

10

External risk reduction facilities: realization

• To create external risk reduction facilities to meet the safety functions requirements and safety integrity requirements specified for such facilities.

11

Overall installation and commissioning

• To install the E/E/PE safety-related systems.• To commission the E/E/PE safety-related systems.

12

Overall safety validation

• To validate that the E/E/PE safety-related systems meet the specification for the overall safety requirements, taking into account the safety requirements allocation for the E/E/PE safety-related systems.

13

Overall operation, maintenance and repair

• To operate, maintain and repair the E/E/PE safety-related systems so that the required functional safety is maintained.

14

Overall modification and retrofit

• To ensure that the functional safety of the E/E/PE safety-related systems is appropriate, during and after modification and retrofit activities.

15

Table 6 Overall safety life cycle overview (continued)




Sequence of phasesThe overall safety life cycle should be used as a basis. The most important item with respect to Safety Manager™ is the sequence of phases for the works to be done and the decisions to be taken.

The E/E/PE safety-related system connects to the process units, the control system and the operator interface. Consequently, the specification of the safety-related system is made late in the project. However, the first system that is required during start-up and commissioning is the safety system to ensure the safe commissioning of the process unit. The result is always a very tight schedule for the detailed design and production of the safety-related system.

Self documentingThis requires a flexible safety system that can be easily and quickly engineered and modified without sacrificing or neglecting the safety aspects; self documenting is therefore a prerequisite.

Safety Manager can be programmed during manufacturing and modified on site through the specification of the safety function (the functional logic diagrams or FLDs). The application program and up-to-date application documentation are generated automatically and almost immediately available.

For details about the design phases with regard to Safety Manager see “Design and implementation phases of Safety Manager” on page 55.

Decommissioning or disposal

• To ensure that the functional safety of the E/E/PE safety-related systems is appropriate in the circumstances during and after the process of decommissioning or disposing of the EUC.

16

Table 6 Overall safety life cycle overview (continued)



4Design phases for an E/E/PE safety-related system

This section describes the design phases for an E/E/PE safety-related system. It covers the following topics:

Topic SeeOverall safety life cycle page 41

Specifying the safety integrity level of the process page 48

Specifying the field instrumentation page 49

Specifying the safety-related system functions page 51

Approval of the specification page 53

4 – Design phases for an E/E/PE safety-related system


Specifying the safety integrity level of the processThe overall safety requirements of the Safety Instrumented System have to be specified according to step 4 of Table 6 on page 44.

Each production process must be classified with regard to safety. Each company shall therefore have competent personnel to conduct SIL classifications. If not available, third party safety consultancy is to be hired.

In Germany for example the government (law) has delegated the approval of both the SIL classification as well as the SIL verification to the TUV.

Specifying the field instrumentation


Specifying the field instrumentationThe field instruments related to the safety-related system consist of valves, limit switches, high-level and low-level pressure switches, temperature switches, flow switches, manual switches, etc. Inputs used for safety applications can be analog or digital. Outputs are mainly digital.

The instrumentation index generally contains:

• Tag number of the instrument

• Description of the process Point

• Make of the instrument

• Supplier

• Setting

Connections to the safety-related systemThe connection to the safety system is specified in the form of a tag number with a description and termination details. The description provides additional information on the tag number and very often includes information on the signal's “health situation” (status).

Following characteristics are to be supported in the IO signal database of a safety system. Table 7 on page 50 shows an extract of the Safety Manager™ database:

• Safety RelatedIndicates whether a signal is to be treated as safety related or not.

• Force enableAllows forcing of signals (only if certain conditions are met). E.g. for simulation, troubleshooting, maintenance and start-up purposes.

• Write enableAllows overwriting of communication signals. E.g. to manually change setpoints and flags that are normally controlled by a DCS.



Table 7 Example specification of IO signals of Safety Manager

Determining the signal parametersThe first phase of a safety-related system safety requirements specification is the inventory of the input and output signals, the process interface.

During the specification stage, certain parameters of the IO signal must be determined by the design engineer. For example parameters like the type of signal (digital or analog), safety settings (safety related, force enable etc.), SER enable, scaling, etc.

The setting of the IO parameters determine how Safety Manager treats the inputs and the outputs. This way the design engineer loads the required signal settings, and access restrictions, of each Point in Safety Manager.

Point type

Tag number

Description

Status

Location

Unit

Subunit

Fld number

Safety related

Force Enable

Write Enable

DI 53HS-101 LAMPTEST TEST MCP 102 Yes Yes No

DI 53_HS_101 LAMPTEST TEST MCP 104 Yes Yes No

DI 91XA-651A Door switch Close AH 5000 91UZ Yes No No

DI CP_Fault System marker SYS 106 Yes No No

DI ExtComFaultCC3 System marker SYS 106 Yes No No

DI ForceEnable FORCE-ENABLE ENABLE SYS Yes No No

DI ExtComFaultCC4 System marker SYS 106 Yes No No

DI Flasher-1Hz System marker SYS 107 No No No

DI InputFault System marker SYS 122 Yes No No

DI InputForced System marker SYS Yes No No

DI 53ES-101 LAMPTEST FLD 5000 104 Yes Yes No

AI Sensor-A1 TEMPERATURE FLD 5000 104 Yes Yes No

AO 53PRA-920 MAIN LINE TEMP FLD 5000 104 No No No

DO 53PT-920.H HIGH ALARM ALARM MCP 5000 104 Yes No No

BI 53PT-920.H MAIN LINE= 110BAR COM 5000 104 No No No

BO Sensor-B3 MAIN LINE TEMP COM 5000 104 No No No

Specifying the safety-related system functions


Specifying the safety-related system functionsThe safety functionality of the safety-related system has to be specified according to steps 4 and 5 of Table 6 on page 44:

• Overall safety requirements

• Safety requirements allocation

The basic function of the safety system is to control the outputs (process) according to the predefined logic sequence based on the current state of the process received via the inputs.

The input and output signals of a safety system are a mixture of digital and analog signals. For digital signals, the relation between input and output can be established with various logical functions such as AND, OR and NOT. This is also possible with analog signals when they have been compared with a defined setpoint. To allow certain process conditions to occur or to continue, the safety system requires timing functions (for example delayed on, delayed off, pulse). In Safety Manager™, these basic functions have been extended with functionality that allows more complex functions such as counters, calculations, communication, etc.

For management purposes a communication link to a supervisory control system may be required. This needs to be specified in this phase of the overall design.

The relations between inputs and outputs have to be chosen so that:

• The process stays in the predefined “operational safe status” during healthy conditions of the input signals.

• The process is directed to a predefined “non-operational safe status” if an unhealthy process or system condition is detected (either automatically or by manual intervention).

The relations between inputs and outputs are determined via functional logic diagrams (FLDs, see Figure 21 on page 52). The functional logic diagrams are created with the Application Editor of the Safety Builder.



Figure 21 Example of Functional Logic Diagram (FLD)

Approval of the specification


Approval of the specificationThe last step is to validate the safety functionality according to steps 4 and 5 of Table 6 on page 44.

This is done by step 7 of Table 6 on page 44:

• Overall safety planning validation

The approved specification is the basis of the design of the safety system. Since the time for the specification preparation is generally too short and since the safety system influences all process units, a large number of revisions (function and termination details) of the specification may be required.

The phases as described in subsections “Specifying the safety integrity level of the process” on page 48 to “Specifying the safety-related system functions” on page 51 are usually performed by the customer or an engineering consultant acting on behalf of the customer. The phases that follow are normally performed by the supplier of the safety system (for example Honeywell SMS for Safety Manager™).


5Design and implementation phases of Safety Manager

This section describes the design and implementation phases when using Safety Manager™ as a safety-related system.

It briefly describes the Safety Builder options, the toolset available for the engineers to create the application for Safety Manager in a structured way.

The following topics are covered:

Topic SeeSafety Manager project configuration page 56

Safety Manager configuration parameters page 59

Specification of input and output signals page 61

Implementation of the application software page 62

Application verification page 63

5 – Design and implementation phases of Safety Manager


Safety Manager project configuration

Safety BuilderTo translate the process related safety aspects into a Safety Manager™ application, the design engineer uses the Safety Builder toolset.

Safety Builder provides a Windows-based user interface to Safety Manager (see Figure 22 on page 56). It is a powerful tool which supports the user in performing a number of design and maintenance tasks. Safety Builder must be used to:

• Configure the network

• Configure Safety Manager

• Design the application program

• Generate application documentation

• Monitor Safety Manager

Figure 22 Example of a Safety Builder configurator screen

Safety Manager project configuration


Point listThe specification of the IO Points with IO parameters, such as description, hardware configuration, etc. is stored in a Point list as shown in Figure 23 on page 57.

The Point list is the basis of the design of the functionality of the safety system by creating functional logic diagrams (FLDs). The use of a Point list containing information on the IO signals has the advantage that basic information only needs to be updated once.

Creating the Point list with aid of the Point Configurator provides:

• A single point of entry for all Point data

• Consistency of throughout the engineering stage

• Automatically updated documentation.

Figure 23 Safety Builder Point Configurator main screen



Functional logic diagrams (FLDs)The functional logic diagrams (FLDs) define the relationship between the inputs and the outputs of a safety system (see Figure 24 on page 58). The information entered in the Point list is added automatically in the functional logic diagrams. The Safety Builder also checks the consistency of the information if the engineer uses Points that have not been allocated to inputs and outputs.

Figure 24 Example of Functional Logic Diagram (FLD)

Safety Manager configuration parameters


Safety Manager configuration parameters

GeneralThe first step in the Safety Manager™ configuration is to determine the Safety Manager properties.

The most important properties are:

• Safety integrity level

• Safety Manager architecture

• Diagnostic Test Interval

• Interval time between faults

These properties are described in more detail below.

Safety integrity levelThis parameter specifies the capable level of safety performance of the overall system. Safety Manager supports safety integrity level 1 (SIL1) which is the lowest level of safety integrity through safety integrity level 3 (SIL3) as the highest level. IEC 61508 details the requirements necessary to achieve each safety integrity level. These requirements are more rigorous at higher levels of safety integrity to achieve the required lower likelihood of dangerous failure.

The system safety level can also be expressed in safety requirement classes. DIN V 19250 defines these requirement classes (Anforderungsklassen, or AK). Safety Manager supports AK1 which is the lowest requirement class (low safety level) through AK6 as the highest requirement class (high safety level). Table 8 on page 59 shows the relation between the safety integrity levels and requirement classes.

Table 8 Relation between SIL and AK Levels

Safety Integrity Level Safety Requirement Class Safety LevelSIL1 AK1 - AK3 Low

SIL2 AK4 Medium

SIL3 AK5 and AK6 High



Diagnostic Test IntervalThe Diagnostic Test Interval (DTI) is the time a fault may be present in a safety system, without possibly endangering an installation or environment. Therefore it specifies the period in which all self-tests are to be executed within Safety Manager.

Maximum repair timeDuring normal operation, each Control Processor of Safety Manager performs self-tests and tests the allocated IO modules. If a fault is detected during the tests, the Control Processor reports the failure and takes action to guarantee a safe operational state.

If possible, the fault will be isolated and Control Processor operation continues. If the continuation of the Safe operation cannot be guaranteed, the Control Processor stops. Certain failure types can be isolated, but safe operation can then only be guaranteed as long as no additional faults occur, which, in correlation with the first failure, may lead to unsafe operation. Therefore, when continuing operation, there is a certain risk of such an additional correlating fault occurring. The longer Safety Manager operates, the larger this risk becomes. To keep the risk within acceptable limits, a time interval must be defined: the maximum repair time, which reflects the maximum period of time the Control Processor is allowed to operate after the first failure occurrence. When the maximum repair time expires, the Control Processor shuts down.

The maximum repair time can be defined between 0 and 2047 hours, or can be completely deactivated. In the latter case, organizational measures must be defined to ensure correct action on Safety Manager failure reports.

Specification of input and output signals


Specification of input and output signals

SafetySafety Builder provides an extensive safety guidance to ensure that correct engineering decisions are taken. Safety Builder assists with allocating IO signals in a safety system. For example, the Point Configurator does not allow multiple allocation or the connection of safety-related signals to modules that do not have self-diagnostic capabilities.

Input/output signalsThe specification of input and output signals is partly done during the specification stage. The data entered in that stage does not contain any information on the physical “chassis/slot/channel” allocation of the IO signal in the safety system.

The Point Configurator of Safety Builder can show Point information of IO signals. To simplify editing and viewing Points, the Point Configurator offers standard and custom views. For detailed information refer to Software Reference.

Physical allocationThe physical allocation of Points in Safety Manager™ should be chosen based on a number of criteria including:

• Subsystems

• Process units

• Location in the plant

• Type of signal

• Engineering preference



Implementation of the application softwareWhen the application is built using Safety Builder, the combination of configuration data, Functional Logic Diagrams and Point information can be translated into machine code, which is to be loaded in the SM Controller.

TranslateTranslation of the application into machine code is consists of the following steps:

1 The Application Compiler of Safety Builder checks for inconsistencies between:

a. System configuration

b. IO Point database and

c. Functional Logic Diagrams (FLD’s)

2 Possible errors and warnings are displayed in a log file, which are available and can be printed for future reference.

3 If the application proves to be consistent the Application Compiler then generates the machine code and stores it on hard disk.

ImplementationAfter the machine code is created, the Controller Management tool is used to load the machine code into the flash memory of the SM Controller (QPP and COM modules). This method does not require any modules to be removed from the chassis.

Application verification


Application verification

IntroductionThroughout the application design, several verification steps must be performed to guarantee the actual application software in Safety Manager™ meets the safety requirements of the process.

IO signal configurationThe Print option of Safety Builder allows the user to create hard copies of the IO signal configuration as stored in the application database.

The hardcopy must be reviewed to verify that the signal configuration represents the originally defined configuration.

This review may be concentrated on the safety-related configuration aspects, such as the Point qualification, the fault reaction, force enable, hardware allocation and power-on values.

This activity covers the following aspects:

• Data entry by the design engineer.

• System response conform settings in the Hardware Configurator and Point Configurator of Safety Builder.

• Operation of the Safety Station.

Depending on local legislation, the IO signal configuration may need to be approved by an independent certification body, for example TUV.

Functional logic diagrams (FLDs)The Print option of Safety Builder also allows the user to create hard copies of the functional logic diagrams as stored in the application database. The hardcopy must be reviewed to verify that the functional logic diagrams represent the intended safeguarding strategy.

This activity covers the following aspects:

• Data entry by the design engineer.

• Operation of the Application Editor of Safety Builder.

Depending on local legislation, the functional logic diagrams may need to be approved by an independent certification body, for example TUV.



Application softwareAfter the application has been successfully translated and the application software has been downloaded to Safety Manager, the correct operation of the application must be verified via a functional test which is carried out during the Factory Acceptance Test (FAT) and/or the start-up and commissioning stages.

The customer then verifies if the original requirements have been correctly implemented in the IO signal configuration, the system configuration and the functional logical diagrams.

Functional testFunctional testing is done via the Application Viewer and a switch box.

Via the switch box, connected to the systems’ inputs, the assessor can control the state of each input.

In the Application Viewer the assessor can verify the inputs and application response.

Verify load diagnosticsThe Safety Manager File is stored in the SM Controller with the Controller Management function of Safety Builder. After storing, Controller Management reads the diagnostics and checks if the file is correctly stored.

Additionally, an Acceptance Test must be performed. During the Acceptance Test the IO allocation, safety application and communication are tested. This is required to comply with the safety requirements.


6Safety Manager special functions

This section describes some special functions of Safety Manager™. It covers the following topics:

Topic SeeForcing of IO signals page 66

Communication with third party Control systems page 69

On-line modification page 70

6 – Safety Manager special functions


Forcing of IO signals

During FAT, on-line testing or calibration of connected devices, it may be required to force an IO Point to a certain fixed state.

For example when testing a defective input sensor forcing allows the sensor to be taken off-line without affecting the continuity of production. While the sensor is being tested, the respective input can be forced to its operational state.

Enable forcingThe procedure to enable forcing of a Point in Safety Manager™ is as follows:

1 Identify the Points that may require forcing during operation and use the Point Configurator to set the force enable flag of thesePoints to ‘Yes’.

2 Translate the application, load it into the system and start the application

Applying forces

The procedure to apply a force is as follows (see also Figure 25 on page 66):

Stop:Forcing Points can be dangerous if not handled properly! Always communicate your actions when applying or removing forces.

WarningApplying forces for a prolonged period of time introduces a potentially dangerous situation as the corresponding process Point could go to the unsafe state while the force is active.

Figure 25 The forcing sequence

Forc

eE

nabl

eK

eyS

witc

h

Force EnableTable

BKMQPPCOM

Forcing of IO signals


1 Set the Force Enable key switch in the on position

2 Open the Application Viewer with a maintenance engineering user level or above (may be password protected)

3 Select the first Point to be forced

4 Right click the Point and select a force option from the pop-up menu.

SettingIO signals can only be forced using the Application Viewer of Safety Builder. Forcing is only allowed if the correct password has been entered when selecting the force option. The status of the force enable flag is also stored in the application in Safety Manager. This has been done in such a way that a change of the force enable flag after compilation of the application does not allow forcing of the corresponding Point without reloading the application software.

Forces may be set high, low or on a specific value as required. The procedure of how to use forcing is as follows:

1 Activate the Force Enable key switch on the BKM after approval by the responsible maintenance manager.

2 Use Application Viewer of Safety Builder to select the Point that needs to be forced. (A password may be required.)

3 Right click the Point and select the value that the Point should be forced to.

4 The force will be applied immediately.

ChecksTo make this operation single fault tolerant, both the Safety Builder and the SM Controller carry out checks before a force is executed:

1. Safety Builder checks if the password is activated.

2. Safety Builder checks if the Force Enable key switch is activated.

3. Safety Builder checks if the force enable flag for the Point is set to Yes.

4. SM Controller checks if the Force Enable key switch is activated.

5. SM Controller checks if the force enable flag in the application is set to Yes.

Safety Manager™ continuously checks the Force Enable key switch and immediately clears all forces when the Force Enable key switch is deactivated.

Notes• All forces are cleared when the Force Enable key switch is deactivated.• All force actions are included in the SER report for review/historical purposes.



Forced PointsIf a force command is accepted for an input or output, the ForceActive system Point becomes active, which can be used as an alarm/indication for operation (see also: “Safety Manager alarm markers, registers and diagnostic inputs” on page 82).

On any subsequent force, the ForceActive marker pulses for one application cycle. When all forces are cleared, ForceActive becomes inactive.

ReferencesSpecific TUV requirements with the regard to forcing are described in a document of TUV Bayern Sachsen e.V. and TUV Rheinland: Maintenance override.

All Safety Manager architectures meet the requirements specified in this document.

Clearing forces

To remove forces set in Safety Manager, select the forced Point as described in “Setting” on page 67, step 2 onwards.

Instead of selecting a force value, select Clear. This will clear the force instead of applying a forced value.

TipThis document is available on request. Please contact your local Honeywell affiliate or e-mail to [email protected].

Attention:To immediately remove all forces:

a. turn the Force Enable key switch or

b. click the Remove All Forces button on the Application Viewer toolbar.Warning:This action is irreversible.

Communication with third party Control systems


Communication with third party Control systems

Exchanging process dataSafety Manager™ can be used to exchange process data with a process control system or PC acting as a man machine interface (e.g. Safety Builder). Such data is represented in functional logic diagrams (FLDs) as Points with location 'COM'.

Points with location 'COM' may only be used for non safety-related functions.

The Point Configurator of Safety Builder sets the safety-relation flag of these signals to 'No' (FALSE) and does not allow this flag to be changed.

The safety-relation flag of the Points can be checked with a list which can be printed with Safety Builder. Table 9 on page 69 shows an example of such an input signal specification.

Table 9 Example of safety relation of IO signals with location COM

ProtocolsFor communication with process control systems and computer equipment running visualization programs the Ethernet communication protocols is used.

For details on communication protocols refer to Planning and Design Guide.

Point type

Tag number

Description

Status

Location

Unit

Subunit

Fld number

Safety related

Force Enable

Write Enable

BI 53PT-920.H MAIN LINE= 110BAR COM 5000 104 No No No

BO Sensor-B3 MAIN LINE TEMP COM 5000 104 No No No



On-line modification

IntroductionOn-line modification (OLM) is a Safety Manager™ option which allows you to modify the application software, embedded system software and the Safety Manager hardware configuration of systems with a redundant Controller while the system remains operational.

During the on-line modification, the changes are implemented in the Control Processors one by one. While one Control Processor is being modified, the other Control Processor continues safeguarding the process.

The engineer executing the OLM is guided through the OLM procedure step by step by the Controller Management tool which is integrated in the Safety Builder.

Compatibility checkDuring the modification, Safety Manager and the Controller Management tool of the Safety Builder perform a compatibility check of the application-related data, to guarantee a safe changeover from the existing configuration to the new configuration. The system reports the FLD numbers of the changed functional logic diagrams. This allows easy verification of the implemented modifications.

With the Controller Management, changes in the functional logic diagrams (FLDs), the Safety Manager architecture and the system software can be implemented in the system, step by step, without shutting down the system.

For details refer to:

• Planning and Design Guide

• On-line Modification Guide.

When modifications are implemented in a application, only a functional logic test of the modified functions is required by, for example, TUV, when the final verification of the implemented changes is obtained via the built-in sheet difference report in Controller Management diagnostics.

Tip:Detailed information about On-line modification can be found in On-line Modification Guide


7Safety Manager fault detection and response

A Safety Instrumented System (SIS) is responsible for maintaining the safety of a process or Equipment Under Control (EUC), regardless the state of the system.

Should a fault arise in the SIS, it must deal with this fault in a safe way within the defined Diagnostic Test Interval (DTI).

A Safety Instrumented System (SIS) operating in “high demand mode of operation” must detect and safely isolate any single fault within one PST.

This section describes:

• Principles of fault detection and response

• Diagnostic inputs and alarm markers,

• Safety Manager™ faults,

• Safety Manager response to faults,

• Rules of thumb.

Below table details the topics described in this section:

Topic SeePrinciple of fault detection and response page 72

Safety Manager alarm markers, registers and diagnostic inputs

page 82

SM IO faults page 87

SM Controller faults page 97

Calculation errors page 104

Rules of thumb with respect to safety and availability page 107

7 – Safety Manager fault detection and response


Principle of fault detection and responseThe goal of fault detection and response is to detect and isolate any single fault that affects the safety of the process under control, within a time frame that is acceptable for the process.

Below topics describe the principle of fault detection and response.

DefinitionsIn order to better understand the concept of fault detection and response a number of related definitions are stated below.

Fault reactionThe response to faults in the Controller, application and/or IO.

• The fault reaction towards Controller and/or application faults is fixed.

• The fault reaction towards IO faults can be configured on a module level and should be customized to the application for which Safety Manager™ is used.

Process safety time (PST)The time a process can be left running uncontrolled without loosing the ability to regain control.

Diagnostic Test Interval (DTI)The time period used by Safety Manager to cyclically locate and isolate safety related faults within on-line system components that could otherwise cause a hazardous situation.

With Safety Manager, the default DTI is set at 3 seconds. This setting needs to be verified for each process.

Topic SeeDefinitions page 72

Principle of fault detection page 75

Principle of fault response page 76

Watchdog and redundancy page 80

Principle of fault detection and response


Repair timeThe time allowed to keep a Safety Instrumented System (SIS) running with a fault present that “may affect safety upon accumulation of multiple faults”. Repair time is introduced to extend the SIS up-time for a limited time frame, allowing system repair.

Repair timerA configurable count-down timer triggered upon detection of a fault that minimizes the safety availability of the system.

The timer is a configurable count-down timer, which can be deactivated. The default repair window is 200 hours, which is more than sufficient if spare parts are available.

Each Control Processor has its own repair timer. Once running, a repair timer shows the remaining time to repair the fault that triggered the repair timer in the Control Processor (200 hours default). If the fault is not repaired within the repair time the Control Processor containing the fault halts.

A repair timer protects the system from certain fault accumulations that may affect the safety of Safety Manager. The timer therefore only starts on detection of faults on output modules and the Force Enable key switch.

SafeA design property of an item in which the specified failure mode is predominantly in a safe direction.

Safety relatedA flag to indicate that a signal is used for a safety related function.

Secondary MeansA means designed to drive towards a safe state in case the primary means is unable or unreliable to do so.

An example of a secondary means is the watchdog: The watchdog is designed to drive the Control Processor and related outputs to a safe state if the Control Processor itself is unable or unreliable to do so.

Secondary Means Of De-energization (SMOD)A SMOD is a Secondary Means designed to de-energize the output in case the primary means is unable or unreliable to do so.

Figure 26 on page 74 shows an example of a SMOD protecting 4 output channels.



Single fault tolerantBuilt-in ability of a system to correctly continue its assigned function in the presence of a single fault in the hardware or software.

Single fault tolerant for safetyBuilt-in ability of each Safety Manager configuration to continue to maintain safety in the presence of a single fault in the hardware or software.

Control Processor statesA Control Processor (CP) can have many states. For fault detection and response only the following states are relevant.

• running without detected faults; CP is fully functional and runs the application

• running with detected faults; CP runs the application but lacks certain functions

• halted

Figure 26 Schematic diagram of a SMOD with 4 channels

d8

d32,z32

Vdc int.

Vdc ext.

OUT4+

OUT-

z8,d30,z30 0 Vdc

&

OUT3+

OUT1+

OUT2+

WDGd2

CH1

CH2

CH3

CH4

SMODGroup On/Off

On/Off

On/Off

On/Off

On/Off

Group

CH4

CH3

CH1 readback

CH2 readback

readback

readback

readback



The applicable CP state can be read from the User Interface Display located on each Control Processor and from the diagnostic screens available on Experion™ and Safety Stations.

IO statesFrom a SIS point of view, IO can have either the healthy state, the de-energized state or the fault reaction state.

• When healthy, the IO is active and has the application value or a forced value applied.

• When de-energized, the IO is de-activated (as if no power was supplied).

• When the fault reaction state is applied, the IO responds conform a predefined fault condition (fault reaction).

Process statesA process can have many states. Related to fault detection and response in the safety loop of a process, the following process states are described:

• running without detected faults

• running with detected faults

• halted

Principle of fault detectionA Safety Instrumented System (SIS) operating in “high demand mode of operation” must detect and safely isolate any single fault within one PST.

Fault detectionFault detection is the first step towards fault response.

Faults in Safety Manager™ are detected conform the Failure Mode and Effect Analysis (FMEA) model, which provides adequate diagnostics on any detected fault. Test algorithms and / or test circuits are embedded in the safety related software and hardware components, such to allow the detection of these faults.

A running SM Controller continuously performs a series of extensive diagnostic checks on all safety related software and hardware components. This way it will

NoteFault detection and response is aimed at detecting and responding to faults that affect or endanger the safety of the system and the process under control.



find faults before they can jeopardize the safety of the process and equipment under control.

Fault detection cycleThe fault detection and diagnostic checks are executed during a fault detection cycle, which is usually split-up over a number of application cycles.

A fault detection cycle always lasts less than one DTI.

Fault databaseUpon detection, a fault is stored in a fault database, where it is further processed by the Controller.

Upon the severity of the fault, the configuration settings, the redundancy in the Controller and other user settings, the Controller will decide what action is appropriate.

To clear a fault from the fault database, the fault must be resolved and a fault reset must be initiated (e.g. turn and release the Reset key switch on the BKM).

Principle of fault response

Each detected fault is reported by means of a diagnostic message, alarm markers and/or diagnostic markers.

If the nature of the fault requires the system to respond, Safety Manager™ will isolate the faulty component from the rest of the system.

At the same time the system acts on the effect of loosing the function of that component.

AttentionMake sure that the diagnostic message is understood and the fault is resolved before initiating a fault reset! Attempting a reset without checking the nature of the fault may lead to a recurring event.

AttentionIt is strongly recommended to repair faults even though a fault seems to have no effect on the system. If not repaired immediately, faults may accumulate and -combined- create an unforeseen but expectable system response.



That action may be:

• none, a redundant component can cover for the lost function.

• none, loosing the function has no impact on safety.

• apply the fault reaction state to the affected IO.

• start the repair timer.

• halt the affected Control Processor.

• de-energize all non-redundant outputs via the watchdog

• de-energize all outputs via the watchdog.

Below explains these items in more detail.

RedundancyWhen available, the redundant component in the system will continue to perform that function. This means that, when redundancy is provided, the system remains available for the process.

No impact on safety

The following examples show a number of faults that have no impact on safety:

• External power down.

• Loss of communication with a process control system.

• Failure of the Controller back-up battery.

Fault reaction stateIf Safety Manager detects a fault related to the IO, this may result in the IO to go to the fault reaction state.

The fault reaction state is a state used as response to faults arising related to IO.

The fault reaction state is user configurable on module level for hardware IO and on point level for communication IO. The following fault reaction states exist:

• High is a fault reaction state for digital inputs:Upon a detected fault the input is energized, or -in other words, the input goes high or becomes ‘1’.

Attention:When below faults occur, the system will report the anomaly but take no action by itself. However the system can be programmed to initiate action if needed.



• Low is a fault reaction state for digital inputs and digital outputs:Upon a detected fault the digital input or output is de-energized, or -in other words, the digital input or output goes low or becomes ‘0’.

• Top Scale is a fault reaction state for analog inputs:Upon a detected fault the input is set to the top scale of the range.

• Bottom Scale is a fault reaction state for analog inputs:Upon a detected fault the analog input is set to the bottom scale of the range.

• Scan is a fault reaction state for tested (analog or digital) inputs:Upon a detected fault the input or output continues to carry the processing value, even if this value may be incorrect.

• Hold is a fault reaction state for analog and digital inputs:Upon a detected fault the input freezes to the last known good value.

• 0 mA is a fault reaction state for analog outputs:Upon a detected fault the analog output is de-energized.

• Appl is a fault reaction state for all outputs:Upon a detected fault the output remains active, the output value may be incorrect.

• Preset is a fault reaction state for numeric inputs located on a communication channel: Upon detected fault the numeric input is preset to a predefined value (not necessary being the startup value).

• Freeze is a fault reaction state for numeric inputs located on a communication channel: Upon a detected fault the input freezes to the last known good value.

Table 10 on page 78 shows the settings applicable to fault reaction for hardware IO.

Table 10 Fault Reaction settings for hardware IO

Signal type Fault Reaction settings

Digital InputsTested High/Low/Scan/Hold

Not Tested High/Low/Hold

Safe Digital Inputs with Line Monitoring High/Low/Scan/Hold

Digital OutputsTested Low/Appl

Not Tested Low/Appl

Tested Digital Outputs with Line Monitoring Low/Appl

Tested Analog Inputs Top Scale/Bottom Scale/Scan/Hold



Table 11 on page 79 shows the settings applicable to fault reaction for communication IO.

Repair timerAll configurations of Safety Manager are single fault tolerant towards faults that affect safety: By using a secondary means Safety Manager is always able to bring a process to safe state, regardless of the fault.

However, given some time, a second fault may occur. This second fault may then disable the secondary means that keeps the process in a safe state.

To prevent such a scenario to develop, the system starts a repair timer if a secondary means becomes vulnerable to faults. Once started, this configurable timer counts down until the fault is repaired. If the timer is allowed to reach zero, the Control Processor halts.

Halt Control ProcessorA Control Processor halts if:

• A fault is detected in one of its safety instrumented functions.For example: corrupted software, safety processors out of sync, watchdog fault

• The repair timer runs out.

• The Control Processor is disabled by its own watchdog,

• The Control Processor is disabled by the watchdog of the other Control Processor.

Analog Outputs* Tested 0 mA/Appl

Not Tested 0 mA/Appl

* The setting Tested or Not Tested is determined by the properties of the analog output module.

Table 11 Fault Reaction settings for communication IO

Signal type Fault Reaction settingsDigital Points (DI) High/Low/Freeze

Numeric Points (BI)*

* the default preset value for numeric points is 0

Preset/Freeze

Table 10 Fault Reaction settings for hardware IO

Signal type Fault Reaction settings



Watchdog and redundancyThe availability of the system after responding to a fault depends on the available redundancy in the system and if -and how- the watchdog interfered.

As shown in Figure 27 on page 81 each Control Processor has a watchdog with two watchdog lines to independently enable/disable the (non-) redundant outputs.

If the watchdog interferes, this can be caused by:

• A fault in the Control Processor:This will halt the related CP and disable all output controls of that CP.

• A fault in the non-redundant outputs:This will cause the watchdogs of both Control Processors to disable the non-redundant outputs.

• A fault in one of the redundant outputs:This will cause the related watchdog to halt its CP and disable all outputs controlled by that CP.



Figure 27 Each watchdog has 2 outputs

InputModule

InputModule

InputModule


Input Interfaces

Processor

Processor

Processor

Processor

OutputModule

Output Interfaces


Output

Output

Module

Module

WatchdogSD

SMOD

Final Element

SMOD

QuadVoter

Watchdog

Final Element

SMOD

Sensor

xxyyy

Sensor

xxyyy

AttentionIt is strongly recommended to repair faults even though a fault seems to have no effect on the system. If not repaired immediately, faults may accumulate and -combined- create an unforeseen but expectable system response.




Safety Manager™ has a number of inputs, generated by the system, that can be used in the application to indicate an alarm or a state:

• System markers and registers indicate the state of the system,

• Alarm markers indicate the occurrence of an abnormal system state,

• Diagnostic inputs indicate the health of the related IO channel or IO loop.

All three are discussed in this section.

System markers and registersSystem markers and system registers reflect the system state in the application.

System markersThe following system markers are available:

Topic SeeSystem markers and registers page 82

Alarm markers page 83

Diagnostic inputs page 85

Table 12 Safety Manager™ system markers

System marker DescriptionFaultReset Fault reset input

ForceEnable Force enable

ClockSync Clock synchronization input

CP1_Running Control Processor 1 running

CP2_Running Control Processor 2 running

ForceActive IO forced

Flasher-0.5Hz 0.5 Hz flasher

Flasher-1Hz 1 Hz flasher





System registersThe following system registers are available:

Alarm markersSafety Manager™ uses a number of alarm markers and alarm registers to indicate the occurrence of abnormal system state. Some markers are general markers, others are specific.

Alarm markersThe following alarm markers are available:

Table 13 Safety Manager system registers

System register DescriptionTempCP1 Temperature Control Processor 1

TempCP2 Temperature Control Processor 2

Second Second

Minute Minute

Hour Hour

Day Day

DayOfTheWeek Day of the week

Month Month

Year Year

Table 14 Safety Manager alarm markers

Alarm marker DescriptionTempHH_Alarm Temperature high-high alarm

TempH_Alarm Temperature high alarm

TempL_Alarm Temperature low alarm

TempLL_Alarm Temperature low-low alarm

ExtComFaultCC1 External communication fault in communication channel 1








Remaining repair timeThe following registers are available to indicate the remaining repair time:

Alarm marker stateThe normal state of a marker (no fault detected) is 1. When the first fault is detected, the associated alarm marker changes to 0. Any subsequent fault of the same type causes the alarm marker to pulse for one application program cycle (see Figure 28 on page 85).



ClockSrcFault1 Clock source 1 fault



SecSwitchOff Secondary switch-off activated

CP_Fault Control Processor fault

ControllerFault* Safety Manager Controller fault

InputFault** Input channel fault

InputLoopFault Input loop fault

InputCompare Input compare fault

OutputFault*** Output channel fault

OutputLoopFault Output loop fault

OutputCompare Output compare fault

RepairTimerStart_CP1 Repair timer started in CP1

RepairTimerStart_CP2 Repair timer started in CP2

* Turns 0 (fault state) at any type of fault detected** Turns 0 (fault state) at any type of input fault detected

*** Turns 0 (fault state) at any type of output fault detected

Table 14 Safety Manager alarm markers (continued)

Alarm marker Description

Table 15 Safety Manager alarm registers

Repair timer registers DescriptionRepair_CP1 Remaining repair time Control Processor 1

Repair_CP2 Remaining repair time Control Processor 2



Diagnostic inputsDiagnostic inputs are available for every Point allocated on a testable IO module.

There are basically two types of diagnostic inputs.

All diagnostic inputs can be used as a digital input in the functional logic diagrams to indicate the status of the IO.

Diagnostic inputs related to channel status.These indicate the diagnostic status of a specific IO channel allocated to a Safety Manager™ Safety Related IO module (see Table 16 on page 85).

Figure 28 Input failure alarm marker function

1 No fault present in Safety Manager2 First input fault3 Second input fault4 Faults corrected and acknowledged via fault reset

Input fault

Controller fault

1 2 3 4

Table 16 Diagnostic inputs (channel status)

Type IO ModuleIO type I SDI-1648, SDIL-1608

IO type O SDO-0824, SDO-04110, SDO-0448, SDO-0424, SDOL-0424

IO type AI SAI-0410, SAI-1620m

IO type AO SAO-0220m

VM cab.c/s/17* (Voltage Monitoring)

* cab.c/s identifies the cabinet, chassis and slot number of the module. 17 is a dedicated channel for Voltage monitoring

SAI-1620m

EFM cab.c/s/ch** (Earth Fault Monitoring)

** cab.c/s/ch stands for cabinet, chassis, slot number and channel of the earth fault.

SDIL-1608



If the channel status is healthy, its diagnostic input is high. If a fault is detected in the channel, the diagnostic input goes low. The status of the diagnostic inputs does not depend on the safety relation of the channel.

Diagnostic inputs related to loop status.These indicate the diagnostic status of a process loop in the field (see Table 17 on page 86).

When a Control Processor detects a loop fault, the system response sets the corresponding marker (SensAI, LoopI, LoopO) to faulty (value “low” or “0”).

Table 17 Diagnostic inputs (loop status)

Type IO ModuleSensAI SAI-0410, SAI-1620m transmitter status

LoopI SDIL-1608 loop status

LoopO SDOL-0424 loop status

SM IO faults


SM IO faultsBelow topics provide an overview of detected IO faults and the Controller response to these faults.

Each topic is accompanied by a fault response table. The principle of these tables is explained in “Fault response tables” on page 87.

The following IO fault related topics can be distinguished:

Fault response tablesTable 18 on page 87 explains the meaning of each column of the IO fault response tables.

FR StateSome cells in the fault response tables state “Apply FR state”.

For an explanation of what this means see “Fault reaction state” on page 77.

Topic SeeDigital input faults page 88

Analog input faults page 89

Digital output faults page 89

Analog output faults page 91

IO compare errors and system response page 92

Compare error detection and synchronization page 94

Table 18 Explanation of a “Controller response to faults” table

This row identifies the fault topicRelated to Diagnostic message

reportsController fault responseCPX (non-red) CPY (red)

This column identifies the type of fault.Examples of a fault category are “loop faults” and “power”.

This column identifies the core message of related diagnostic messages

Shows response of the CP with the faulty IO. It indicates the field response for non-redundant IO

Shows response of the CP without the faulty IO.It indicates the field response for redundant IO

When both columns are merged the response of both CP’s is identical.



Alarm markersAll detected faults cause alarm markers to be set low or 0.

Depending on the fault, a single marker, or several markers are set. Some markers are general and are always set upon an IO fault.

For more information about alarm markers, see “Safety Manager alarm markers, registers and diagnostic inputs” on page 82.

Digital input faultsTable 19 on page 88 provides an overview of faults that can be detected in relation to digital inputs and the response to these faults.

Tip• To see the Controller response towards non-redundant IO, check the “CPX (non-red)”

column.• To see the Controller response towards redundant IO, check the “CPY (red)” column.

Table 19 Controller response to digital input faults

Digital input faultsRelated to Diagnostic message


digital input loop (line monitored)

lead breakage apply FR state apply FR state

short circuit

earth fault

loop power(default)

power output to sensors shorted

apply FR state apply FR state

loop power(line monitored)

power output to sensors shorted


channel channel faulty apply FR state none

module module faulty apply FR state none

compare*

* See also “IO compare errors and system response” on page 92.

input compare error apply FR state apply FR state

SM IO faults


Analog input faultsTable 20 on page 89 provides an overview of faults that can be detected in relation to analog inputs and the response to these faults.

Digital output faultsTable 21 on page 89 provides an overview of faults that can be detected in relation to digital outputs and the response to these faults.

Table 20 Controller response to analog input faults

Analog input faultsRelated to Diagnostic message


analog input value below low transmitter alarm level


above high transmitter alarm level

loop power External voltage monitoring fault(SAI-1620m)

none none

channel channel faulty apply FR state none

module module faulty apply FR state none

Internal power down(SAI-1620m)

compare*


input compare error apply FR state apply FR state

Table 21 Controller response to digital output fault

Digital output faultsRelated to Diagnostic message


digital output loop (default)

Short circuit detected (single message)

De-energize shorted output(s).

Short circuit detected (multiple messages)



digital output loop (line monitored)

current detected Apply FR state

open loop

Short circuit detected (single message)

IF FR state is low AND testing is 1oo2D de-energize group & start repair timer.ELSE de-energize shorted output(s).Short circuit detected

(multiple messages)

loop power external power down none

channel (default)

channel faulty Apply FR state.• When FR state is

low de-energize group & start repair timer

IF channel is non-redundant, CPY responds like CPX.ELSE no response from CPY.

mismatch between expected and actual value

Apply FR state.• When FR state is

low also de-energize group & start repair timer


channel cannot be switched off

Apply FR state.• When FR state is



channel (line monitored)

channel cannot be switched on

De-energize channel(s) that cannot be switched on.

Table 21 Controller response to digital output fault (continued)



SM IO faults


Analog output faultsTable 22 on page 91 provides an overview of faults that can be detected in relation to analog outputs and the response to these faults.

module line monitoring circuit Apply FR state.• When FR state is


none

none

module faulty or all groups de-energized(non-redundant)

When FR state is appl:• Apply FR state to CPx, • “none” response from CPy

When FR state is low:• Both CPs de-energize non-redundant IO

watchdog line

module faulty or all groups de-energized(redundant)

When FR state is appl:• Apply FR state to CPx, • “none” response from CPy

When FR state is low:• halt CPx • “none” response from CPy

compare* output compare error apply FR state


Table 21 Controller response to digital output fault (continued)



Table 22 Controller response to Analog output faults

Analog output faultsRelated to Diagnostic message


power external power down none



IO compare errors and system response

For proper operation both Control Processors of a redundant system must have identical IO values at the beginning and at the end of each application cycle.

An IO compare error is generated as soon as the Controller detects a difference between the IO values of CP1 and CP2.

Fault response tableThis section uses fault response tables to explain the response towards faults.

Table 23 on page 93 explains the meaning of each column in the IO Compare error fault response table.



channel mismatch between expected and actual value

Apply FR state on both CPs• When FR state is 0 mA also de-energize

group & start repair timer on both CPschannel faulty

module module faulty or all groups de-energized

Apply FR state on both CPs• When FR state is 0 mA also de-energize

non-redundant IO watchdog line on both CPs

compare* output compare error Apply FR state.


Table 22 Controller response to Analog output faults (continued)

Analog output faultsRelated to Diagnostic message


NoteBecause of the high level of self-testing and fault-handling by Safety Manager™, the actual occurrence of a compare error is very unlikely.

SM IO faults


Different process valuesDifferences in process values may be caused by IO or synchronization faults. Such differences are usually solved before the application cycle starts.

• For more information regarding differences caused by IO faults see “Input compare errors” on page 94 and “SM IO faults” on page 87.

• For more information regarding differences caused by synchronization faults see “Input synchronization algorithm” on page 95.

Controller responseThe Controller responds towards IO compare errors by applying the fault reaction state to the faulty IO.

Table 24 on page 94 shows the relation between Input and output compare faults, alarm markers and Controller response.

Table 23 Explanation of a “Controller response to compare error” table

IO compare errorRelated to redun

dancyOccurs when detecting Controller

responselist type of IO *

* reports the configuration of IO (redundant or non-redundant).

lists cause of the fault identifies the response of the Controller

NoteA Controller does not automatically shut-down upon detection of IO compare error.However, sometimes a shut-down is required to comply to local regulation. In such cases refer to “Shutdown at assertion of Safety Manager alarm markers” on page 112.



Compare error detection and synchronization

Input compare errorsInput compare error detection applies to all hardware inputs.

Differences in the input status read should be momentary. Persisting differences could be the result of detected hardware faults. In that case, the faulty input channel is reported in the diagnostics, and both Control Processors use the process value read from the healthy input channel.

A persisting difference in status of an input while no faults are detected at the accessory hardware channels leads to an input compare error.

Output compare errorsAn output compare error applies to all digital hardware.

In configurations with a redundant Controller, both Control Processors will continuously have an identical application status, resulting in identical process outputs.

An output compare error is detected if there is a difference between the Control Processors with respect to:

• the calculated application output values for digital outputs (DO) or communication outputs (DO, BO) to another Safety Manager™.

• the actual application values sent to digital outputs (DO) or communication outputs (DO, BO) to another Safety Manager.

If outputs are no longer synchronized an Output Compare error is generated.

Table 24 Controller response to IO compare faults

IO compare errorRelated to redun

dancyOccurs when detecting Controller

responsedigital inputs N.A. a persisting difference for more than 1

DTIapply FR state

analog inputs N.A. a deviation of >2% for more than 1 DTI (SAI-1620m only).

digital outputs

N.A. a difference between outputs

analog outputs

N.A.

SM IO faults


Input synchronization algorithmIn configurations with a redundant Controller, the process inputs are scanned every application program cycle by both Control Processors.

Each Control Processor executes the application cycle independently of the other. It is therefore essential that they use identical values for the process inputs.

There is no problem if the process inputs are stable. However, if an input value changes when the Control Processors read the value, both Control Processors could read a different value. In such cases, an identical input value in the Controller is obtained via input synchronization.

If inputs are no longer synchronized, the signal value freezes to the last known synchronized state and a synchronization timer -equal to the configured Diagnostic Test Interval- is started. This state is maintained until:

• a synchronized state is obtained or

• the synchronization timer runs out.

If a synchronized state is not achieved within the configured Diagnostic Test Interval the fault reaction is activated and an Input Compare error is generated.

If a synchronized state is achieved within the configured Diagnostic Test Interval the synchronization timer is reset.

Synchronization algorithms are used for digital and analog inputs.

Digital input synchronizationA digital input compare error is detected if the inputs of both Control Processors are stable but different (for example Control Processor 1 continuously ‘0’, Control Processor 2 continuously ‘1’), for the duration of the configured Diagnostic Test Interval (DTI).

The input compare error detection algorithm puts the following demands on the dynamic nature of the digital process inputs:

1. If an input state changes, it must become stable again within the configured Diagnostic Test Interval.

2. The frequency of continuously changing inputs must be less than 1/DTI.

Analog input synchronizationFor analog inputs, the synchronized value is the mean value of the input values. An input compare error is detected if the input values differ more than 2% of the full scale for the duration of the configured Diagnostic Test Interval.



The input compare error detection algorithm puts the following demands on the dynamic nature of the analog process inputs:

1. For inputs allocated on a redundant module (type SAI-0410 or SAI-1620m), the slope steepness must be less than 125 mA/s.

2. For inputs allocated on a non-redundant module (type SAI-1620m), the slope steepness must be less than 20 mA/s

.

CautionAnalog input compare errors may, for example, occur when calibrating smart transmitters using hand-held terminals. Refer to the Troubleshooting and Maintenance Guide for details on calibrating smart transmitters that are connected to Safety Manager analog inputs.

SM Controller faults


SM Controller faultsBelow topics provide an overview of detected Controller faults and the Controller response to these faults.

Each topic is accompanied by a fault response table. The principle of these tables is explained in “Fault response tables” on page 97.

The following fault topics can be distinguished:

Fault response tablesThis chapter works with fault response tables to explain the response towards faults.

Table 25 on page 98 explains the meaning of each column in the various Controller fault response tables.

Topic SeeQPP faults page 98

USI faults page 100

BKM faults page 101

PSU faults page 102

Communication faults page 102

Tip• The left column (CPX) identifies the response of the faulty Control Processor and can

be seen as system response for a non-redundant system.• The right column represents the system response when redundancy is provided.





Alarm markersAll detected faults cause an alarm marker to be set low or 0.

Depending on the fault, a single marker, or several markers are set. Some markers are general and are always set upon a Controller fault.

For more information about alarm markers, see “Safety Manager alarm markers, registers and diagnostic inputs” on page 82.

QPP faultsTable 26 on page 99 provides an overview of faults that the Controller detects related to the QPP and the response to these faults.

Table 25 Explanation of a “response to Controller faults” table

This row identifies the fault topicrelated to user con-

figurablediagnostics report includes Controller fault response

CPX( faulty) CPY (not faulty)identifies the type of fault.

See note*

* This column identifies if the Controller response or set point can be configured by user setting.

lists the core message of related diagnostic messages.

lists the response of faulty CP

lists the response of other CP (if any!)

When both columns are merged the response of both CP’s is identical.



Table 26 Controller response to QPP faults

QPP faultsrelated to user con-


CPX( faulty) CPY (not faulty)temperature monitoring

set points high alarm run run

low alarm

high-high alarm halt CP run

low-low alarm

1 sensor faulty and temp. and more than 3 degrees from shutdown limits

run run

1 sensor faulty and temp. and less than 3 degrees from shutdown limits

halt CP run

Memory no QPP memory halt CP run

Execution no execution time out of range / failure

halt CP run

error on logical sheet halt CP halt CP

Watchdog no output shorted halt CP

de-energized watchdog line for redundant outputs

halt CP run

de-energized watchdog line for non-redundant outputs

CP runs, but is not active on non-redundant outputs

run

Watchdog no faulty halt CP run

Bus drivers

Internal link

QPP module

secondary switch-off

no faulty halt CP run

repair timer runtime running run run

expired halt CP run

software no corrupted halt CP run



USI faultsTable 27 on page 101 provides an overview of detected faults in relation to the USI and the response to these faults.

A fault in the USI also means that the communication channels of that USI are down. For an overview of faults related to communication lines, see “Communication faults” on page 102.

intervention no QPP key switch to “IDLE” position

halt CP run

Spurious watchdog interrupt

safe state initiated

SD input de-energized halt CP halt CP

synchronization no QPP-0001 halt CP run

system software halted CP does not start

run

base timer halt CP run

IO compare error Both CPs apply FR state

time sync yes source unavailable Both CPs switch to other source

internal communication

no halt CP run

Table 26 Controller response to QPP faults (continued)

QPP faultsrelated to user con-


CPX( faulty) CPY (not faulty)

AttentionThe column “Controller response” of Table 27 on page 101 applies only when no redundancy is provided in the communication. If redundancy is provided, the Controller response shall be “none”.



BKM faultsTable 28 on page 101 provides an overview of faults that can be detected in relation to the BKM and the response to these faults.

Table 27 Controller response to USI faults

USI faultsrelated to user con-


CPX( faulty) CPY (not faulty)Memory yes USI module apply FR state

to affected COM inputs

none

Execution

communication USI module

module faulty USI module

synchronization system software

Memory USI module

software corrupted

Table 28 Controller response to BKM faults

BKM faultsrelated to user con-


CPX( faulty) CPY (not faulty)

intervention during normal operation

no reset key switch Both CPs clear fault database, restart deactivated components

force key switch Both CPs enable / disable forces

intervention during OLM

reset key switch start halted CP halt running CP

key switch reset key switch failure run

force key switch failure start repair timer

module faulty no BKM module run run

battery no faulty / low run run

lifetime expired

transport switch



PSU faultsTable 29 on page 102 provides an overview of faults that can be detected in relation to the PSU and the response to these faults.

Communication faults

Table 30 on page 102 provides an overview of faults that can be detected in relation to communication and the response to these faults.

Table 29 Controller response to PSU faults

PSU faultsrelated to user con-


CPX( faulty) CPY (not faulty)Voltage monitoring

no spurious watchdog interrupt

halt CP run

module faulty PSU module

Notes• Please note that a fault in the communication lines may be caused by USI modules.

For an overview of USI faults, see “USI faults” on page 100.• Redundancy in communication channels can also be achieved with non-redundant

systems by assigning two channels to a device. In this case the table heading “Controller fault response” no longer relates to CPX or CPY but to ChannelX or ChannelY.

Table 30 Controller response to communication faults

Communication faultsrelated to user con-


ChannelX ChannelY

Experion™ PKS, device communication

time-out communication fault ChannelX.

switch to Channely

continue, if configured

communication fault ChannelY.

continue switch to ChannelX

communication fault ChannelX and ChannelY.

Both CPs apply fault reaction state to SM Controller inputs

Safety Station no nothing* none none



Communication time-outIf no communication with the external device is established within a predefined time frame a communication time-out is generated.

A communication time-out always results in a communication failure. Communication time-outs can be configured by the user. See “Rules of thumb with respect to safety and availability” on page 107.

If a device is connected to Safety Manager via a redundant communication link, the fault detection applies to each link separately resulting in single-fault tolerant communication.

* As it is quite common for portable Safety Stations to be (dis-)connected on a regular basis, no diagnostic report or alarm marker is linked to this event.



Calculation errors

Calculation errors may occur in the application program.

Calculation errors occur if:

• The calculated value of an analog output is outside the specified range.

• The square root of a negative number is taken.

• A divide-by-zero occurs.

• An overflow occurs during a calculation.

• The value for a counter is outside the specified range.

Calculation errors reflect an incorrect design of the application program for the intended function. Once a calculation error occurs for a specific process Point, a correct result of successive calculations based on this Point cannot be guaranteed.

Guidelines on how to avoid calculation errors in the Safety Manager™ application are presented below.

Preventing calculation errorsCalculation errors can be prevented as follows:

• Overall process design.

• Inclusion of Safety Manager™ diagnostic data.

• Validation of signals in the Functional Logic Diagrams (FLDs).

• Exception handling during the actual calculation.

Prevention by designIn line with good software engineering practice, as promoted by IEC 61508, calculation errors should be avoided by design. This means that an application should be designed in such a way that the operands of a symbol in the FLDs can never get an invalid value. The design approach starts with making sure that input values as obtained from the process remain within a predefined range. This approach ensures that the derived values are also valid for successive operations.

Sometimes, however, it cannot be guaranteed that an input value remains within a predefined range which is valid for all functions. For example, a signal derived

CautionSafety Manager™ stops if a calculation error occurs.

Calculation errors


from a reverse-acting, non-linear 4-20 mA transmitter which has been configured for a zero top scale in the application domain could become negative if the transmitter fails and delivers a signal beyond 20 mA. If the signal is then linearized through a square-root function, a system stop occurs (square root of negative number).

Preventive measuresIf a valid input value cannot be guaranteed, preventive measures must be built into the design. A comparison function can be used as an indicator that the transmitter value has left its normal operational band and that the calculation should not be done. The alarm signal is used to implement a corrective action and to indicate the exception to the operator (see Figure 30 on page 105).

If diagnostics are not available (e.g. for 0-20 mA transmitters), it is necessary to implement range checking in the application. The result of the range check is again used for the implementation of corrective actions.

Figure 29 Intended square-root function

Transmitter

Figure 30 Square-root function with validated input value

Transmitter

Validatedinput value

Alarm/Annunciation

Process value

TipRange checking is also useful to define the boundaries of analog outputs 0(4)-20mA, thus preventing a system shutdown due to driving values that exceed the boundaries.



An important advantage of input validation is that it can be implemented for input values of which the validity cannot be guaranteed. Furthermore, the invalid input can be exactly identified. This allows the implementation of effective correction strategies of only the affected part of the process.

Common function blockA last option is to create a common function block, e.g. square root. The function block validates the operand(s) and only performs the intended function if the operands are valid. Otherwise a predefined value is returned. An additional function block output should be provided which indicates if the calculation result is valid or not. This output signal can be used for the implementation of corrective actions in the application (see Figure 31 on page 106).

Figure 31 Square-root function with validity check in function block

Transmitter

Function block

Alarm/Annunciation

Processvalue

Rules of thumb with respect to safety and availability


Rules of thumb with respect to safety and availabilityThe philosophy behind the concept of fault reaction is to grant the design engineer the choice of customizing the system’s fault reaction towards the safety and availability demands of the process.

Rules of thumb with respect to safety and availability settings can be divided in the following topics:

IO settingsIO settings determine the response of Safety Manager™ towards detected faults related to the IO.

Analog output property settingsFigure 32 on page 107 shows the module properties of an analog output module. The properties of this module has the check box Test disabled which can be checked.

Checking this box prevents the system from testing and generating undesired warnings. On the other hand will this also prevent the system from generating safety related warnings.

Topic SeeIO settings page 107

System settings page 108

Figure 32 Properties of an analog output module

WarningWhen checking the Test disabled check box the analog output module may not be used as part of a safety loop.



Advised fault reaction settings• For normally energized safety related applications, like ESD applications, the

advised predefined safe state is de-energized or ‘Low’.

• For normally de-energized safety related applications, like FGS applications, the advised predefined safe state for inputs is energized or ‘High’ /’Top Scale’.

• For all other applications a preferred safe state cannot be determined beforehand; the user can choose between scanning (‘Scan’) and freeze last known value (‘Hold/Freeze’).

Advised safety related settingsFigure 33 on page 108 provides an example of point properties. Each point has the Safety related pull down menu with the options No and Yes. (Initially this field is undefined.)For hardwired IO these options have no effect on the system response. The selection made in this pull down menu is for documentation purposes only.

System settingsSystem settings determine the response of Safety Manager™ towards detected faults not directly related to the IO.

Figure 33 Point detail

Rules of thumb with respect to safety and availability


Advised SIL levelThe Safety Integrity Level (SIL) field shows the highest SIL level Safety Manager is used for.

This variable has no impact on the system response towards safety related faults since the system response towards these is always based on SIL3.

Advised repair timer settingsA repair timer is a configurable count-down timer triggered upon detection of a fault that minimizes the safety availability of the system.

The repair timer settings determine the time period that faulty Control Processors and their outputs allowed to continue without being halted. The default setting for a repair timer is 200 hours.

Extending the repair time increases the risk of a second fault arising and affecting the safety of the process; this is to be avoided whenever possible.

When in doubt, consult your Safety Matter Expert at Honeywell.

Advised DTI settingsSafety Manager uses the DTI to detect and respond to faults.

To detect all safety related hardware and software faults in a Safety Instrumented System (SIS), a fixed Diagnostic Test Interval must be determined.

The Diagnostic Test Interval depends on:

1. the Process Safety Time,

2. the demand mode of operation and

3. the amount of hardware and software to be tested.

The DTI for Safety Manager is never shorter than 1 second.

Within the Safety Manager™, the default Diagnostic Test Interval is set at typically 3 seconds. This setting needs to be verified for each process.

Changing the DTI setting affects the application cycle time.

• Reducing the DTI will:

- Cause the application cycles to become longer

- Cause the system to respond faster to detected faults

• Increasing the DTI will:

CautionMake sure that a running repair timer is recognized and can be responded to, before the repair timer expires.



- Cause the application cycles to become faster

- Cause the system to respond slower to detected faults

Application cycle timeThe application cycle time is the time period needed to execute the application software once.

Factors that influence the application cycle time are:

1. The architecture of the Safety Manager™

2. The amount and type of IO

3. The applied diagnostic test interval setting

4. The complexity of the application software (FLDs)

The actual application cycle time is calculated by the Application Compiler.

Tip:The application cycle time can be estimated by Honeywell SMS, based on above data.


8Using Safety Manager alarm markers and diagnostic inputs

Safety Manager™ alarm markers and diagnostic inputs can be used within the functional logic diagrams (FLDs) to monitor and respond to changing system states, alarms and diagnostics.

This is illustrated by the following three examples.

Example SeeShutdown at assertion of Safety Manager alarm markers

This example shows how to program a shutdown in case of assertion of Safety Manager alarm markers. This kind of programming could be used if the system is intended to run in SIL3 without operator surveillance.

page 112

Unit shutdownThis example shows how diagnostic inputs of type IO-TYPE O can be used to realize independent safeguarding of process units including unit shutdown in case of defects.

page 113

Diagnostic status exchange with DCSThis example discusses the functional logic which can be used to report the status of alarm markers and diagnostic inputs to a distributed control system (DCS).

page 117

8 – Using Safety Manager alarm markers and diagnostic inputs


Shutdown at assertion of Safety Manager alarm markersIf it is not sufficient to initiate an alarm when Safety Manager™ detects a fault and immediate system response is required, the Safety Manager alarm markers can be used to shut down the system via the application.

Figure 34 on page 112 shows an example of how to shut down the system in case of an IO compare error. An additional manual shutdown input is provided with which the operator can initiate a shutdown by hand.

If an IO compare error is detected or a manual shutdown is initiated, a divide-by-zero is forced and Safety Manager shuts down. Other alarm markers can be used in a similar way.

Figure 34 Diagram to shut down system in case of output compare error

NoteA manual shutdown can also be realized via the shutdown (SD) input of the SM Controller. In this way, a tested solid-state hard wired connection can be used, which allows the secondary means of de-energization of all outputs to be de-activated. This unique feature allows an ESD push button chain to be connected to Safety Manager which can then be used to initiate an emergency shutdown (ESD), fully independent of the Control Processor.

Unit shutdown


Unit shutdown

Process unitsIf a process can be divided into independent process units, the overall process availability can be increased by a separate shutdown of the units within Safety Manager™. In this way, whenever a fault is detected in the hardware of a process unit, only the affected unit needs to be shut down, while the other parts of the process remain unaffected.

Configuration of unit shutdown (watchdog grouping)This subsection covers the required configuration, application programming and wiring to achieve shutdown per process unit.

Figure 35 on page 113 shows a standard wiring diagram for unit shutdown of three separate process units.

For each process unit, a relay is used to connect the watchdog signal of the unit output to the process Safety Manager watchdog. The relays are controlled via outputs of Safety Manager: the unit shutdown outputs. In normal operation, all relays are activated. If a fault is detected in a process unit, the corresponding relay is deactivated, which results in a shutdown of the relevant unit.

Figure 35 Wiring diagram for unit shutdown

Safety Manager9236295192362951

Watchdog signal

Relay Relay RelaySafe "Relay-controlling"Digital Output module

Safe "Process”Digital Output modules



The unit relays must meet the requirements of DIN VDE 0116, part 8.7.4.5 and 8.7.4.6 of October 1989, i.e.:

1. Mechanical reliability > 3 ∗ 106 switches.

2. Contacts protected (for example fuses, series resistors, etc.) at 0.6 ∗ nominal contact current.

3. Electrical reliability > 2.5 ∗ 105 switches.

Unit shutdown outputsThe unit shutdown outputs must:

• Be allocated on safe modules (such as a SDO-0824 or SDOL-0424 module)

• Have their ‘fault reaction state’ set to ‘low’. This guarantees that Safety Manager directs the process to its safe state if a fault occurs which affects this output.

• Have set the ‘power-up status’ of the unit shutdown output to ‘ON’.This allows a correct start-up of Safety Manager with activated unit relays.

For optimal availability it is recommended that unit shutdown outputs are allocated to redundant output modules.

Process outputs (safety related)The process outputs must be allocated to a Safety Manager output module of the type:

TipThe relay output FTA TSRO-0824 complies to these requirements.

• SDO-0824 Safety-related digital output module(24 Vdc, 0.55 A, 8 channels)

• SAO-0220m Safety-related analog output module(0(4)-20 mA, 2 channels)



• SDO-0424 Safety-related digital output module(24 Vdc, 2 A, 4 channels)

• SDOL-0424 Safety-related loop-monitored digital output module(24 Vdc, 1 A, 4 channels)

Unit shutdown


To allow the programming of the response via the application, the fault reaction of these outputs must be set to ‘Appl’. This disables the automatic response of Safety Manager in case a fault occurs at safety-related output modules.

Application programmingTo realize unit shutdown in the functional logic diagrams, all diagnostic inputs related to output modules of each process unit are connected to an AND gate.

For a listing of diagnostic inputs related to output modules see “Diagnostic inputs” on page 85.

Figure 36 on page 115 shows how the output signal of the AND gate is connected to the unit shutdown.

As long as all diagnostic inputs are “healthy”, they are high, the unit shutdown output is high and the unit relay is activated (relay contact closed).

If a diagnostic input of an output channel in the unit becomes “unhealthy”, the corresponding unit shutdown output becomes low and the unit relay is deactivated (relay contact open).

A defective output channel can be switched-off in accordance with the normal Safety Manager response for safety-related signals. To switch off a defective output channel, the calculated application output and the channel diagnostic input must be supplied to the output channel via an AND gate.

Figure 36 Functional logic diagram of unit shutdown



The Safety Manager ‘FaultReset’ alarm marker is connected to all unit shutdown outputs via an OR gate. When an error is detected and repaired in a unit, the unit may be restarted using the ‘FaultReset’ alarm marker.

The minimum and maximum time the unit output is enabled by the ‘FaultReset’ is limited to ensure that the ‘FaultReset’ is detected by the output. The pulse length (typically set at 800 ms) may not exceed the Diagnostic Test Interval.

Diagnostic status exchange with DCS


Diagnostic status exchange with DCS

Distributed control systems (DCS)Safety Manager™ alarm markers and the diagnostic inputs can be transferred to distributed control systems (DCSs), for example to generate an operator alarm or to initiate a corrective action within the DCS.

Figure 37 on page 117 shows the functional logic diagram to report the occurrence of an input fault (‘InputFault’ alarm marker) and the use of a diagnostic input (IO type AI) to report the status of an analog input channel to a DCS system.

The status of the Points is transferred to the DCS via outputs with location ‘COM’, which are allocated to the communication channel to the DCS.

NoteExperion™ PKS can also access diagnostics through dedicated interfaces. See Overview Guidefor details.

Figure 37 Safety Manager system information to DCS



Behavior of alarm markersThe behavior of the alarm markers is quasi-static. Normally, if no fault is present, the value of the markers is high. If a fault is detected, the corresponding alarm marker becomes low. On subsequent faults the alarm marker becomes high during one application program cycle of Safety Manager (for example 300 ms) and then low again (see “Safety Manager alarm markers, registers and diagnostic inputs” on page 82).

If the scan cycle of the DCS lasts longer than the Safety Manager application cycle, it is possible that any subsequent faults are not detected by the DCS. The Safety Manager alarm marker is therefore connected to the output of the DCS via a delayed off timer. Thus, a pulse on the alarm marker is extended to the configured timer value. To ensure detection by the DCS, the timer value must be larger than the DCS scan time.

Behavior of diagnostic inputsThe behavior of the diagnostic inputs is static. Normally, an IO channel is healthy and the value of the corresponding diagnostic input is high. If the IO channel becomes faulty, the diagnostic input becomes low. It remains low until the fault is repaired and a fault reset has been given. The diagnostic input can therefore be connected directly to the output to the DCS.


9Fire and gas application example

Following topics are described in this section:

Topic SeeIntroduction page 120

General system and Fire and Gas alarms page 121

Input loops page 124

Loop status page 125

Output loops page 127

Monitoring for alarm status page 135

Monitoring for failure status page 138

Inhibit function page 140

9 – Fire and gas application example


IntroductionThis section describes an application for a Fire & Gas (F&G) application which is designed according to the requirements of EN-54 part 2 and NFPA 72, with the INHIBIT options installed. The basic Fire and Gas application is based on the basic Fire and Gas function described in Cause & Effect diagrams (for details see the Fire and Gas Application manual). The actual basic F&G application for Safety Manager™ is stored as BFGA_1 revision 0.

Safety Manager does not support alphanumeric displays, so this option of EN-54 part 2 and NFPA 72 is not shown here. Visualization of alarms, faults, inhibits etc. will be arranged by means of lamps or leds on a mimic panel (common alarms, faults, etc.) and graphical displays on Experion™ PKS (common and detailed alarms, faults, etc.). On Experion PKS all alarms, faults, inhibits, status and warning signals will be collected listed in alarm list screens and will be stored for historian functions.

The figures in this chapter are FLDs taken from the basic F&G application BFGA_1. Where applicable, references to the EN-54 part 2 or NFPA 72 standard are shown in italics in square brackets. The status of the installation that is monitored and the status of Safety Manager must be uniquely displayed [EN-54 part 2, 7.2] [NFPA72, 3.8.7]. In the complete example this is accomplished by the use of hardwired digital IO signals, which can drive LEDs, or lamps on the mimic panel for the common alarm, fault and inhibit signals.

Detailed alarm signals as well as common alarm, fault and inhibit signals will also be displayed on Experion PKS. These signals are transferred to these systems via the communication networks such as the Safety Manager-Safety Manager communication link or the dedicated Experion Ethernet network. [EN-54 part 2, 7.9] [NFPA72, 1.5.4.4]. Failure of the communication link must be alarmed [EN-54 part 2, 8.2.5.b].

Please note that the sheet references to safety instrumented functions in the functional logic diagrams must point to a higher FLD number, which means that they are used in the same application cycle to get the best possible response time. This response time of automatic fire detectors resulting in the required outputs is 3 seconds [EN-54 part 2, 7.7.2] [NFPA72, 1.5.4.1.2, 1.5.4.2.2 & 1.5.4.3.3].

General system and Fire and Gas alarms


General system and Fire and Gas alarmsThe system alarm FLD 2000 (Figure 38 on page 122) covers the status indication that the Safety Manager™ F&G control system is powered on and switched on, the indication for an earth leakage alarm [EN-54 part 2, 8.2.4.c] and the indication for a PSU or power failure [EN-54 part 2, 8.2.4.b, 8.2.4.d].

FLD 2002 (Figure 39 on page 122) contains the common failure alarm that is set in case of a failure of a component in the Fire & Gas detection system, including failures in the F&G detectors. A fault results in activation of the (yellow) General fault indication lamp [EN-54 part 2, 8.2.1.a, 8.5.a] and activation of the General Fault buzzer [EN-54 part 2, 8.2.1.c, 8.5.b] [NFPA72, 1.5.7.4] on the mimic panel. The buzzer can be silenced by means of a reset buzzer [EN-54 part 2, 8.6.1] switch on the panel. A new fault alarm activates the buzzer again [EN-54 part 2, 8.6.3].

FLD 2004 (Figure 40 on page 123) contains the common Fire/Gas alarm that is set in case of detection of fire or gas by the Fire & Gas detection system. An alarm results in activation of the (red) General Fire/Gas alarm indication lamp [EN-54 part 2, 7.2.a] and activation of the General Fire/Gas alarm buzzer [EN-54 part 2, 7.2.c] on the mimic panel. The buzzer can be silenced by means of a reset buzzer [EN-54 part 2, 7.4.1] [NFPA72, 1.5.7.2] switch on the panel. A new alarm activates the buzzer again [EN-54 part 2, 7.4.3].

The failures in the F&G detectors are handled in other FLDs, in this example see FLD 530 (Figure 41 on page 123) of a smoke detector input loop [EN-54 part 2, 8.1.1]. Inside function block FB2411 alarm and fault signals are generated for this detector and used in the logic. Smoke detectors have an automatic latching function. Detectors in alarm state have to be reset by switching off detector device [EN-54 part 2, 7.6.1]. This reset function is included in the function block.



Figure 38 FLD2000 system alarms

Figure 39 FLD2002 general fault alarm

General system and Fire and Gas alarms


Figure 40 FLD2004 general fire/gas alarm

Figure 41 FLD530 smoke detector input loop



Input loopsThe basic Fire and Gas application has a number of Fire & Gas detector input loops (see FLD 530 (Figure 41 on page 123) and FLD 120 (Figure 42 on page 124)). The Fire & Gas detectors are connected to analog input modules. The output of the detectors can be a digital contact with loop-monitoring or an analog input signal. The function blocks 2400, 2401, 2402, 2403, 2404, 2405, 2411, 2412 and 2413, handle all functions for an input loop [EN-54 part 2,7.1.2, 7.1.5]. These functions are:

• Setting of alarm and fault levels [EN-54 part 2,7.1.2].

• Loop status (open loop, short-circuit) as determined by Safety Manager™ [EN-54 part 2, 8.2.4] [NFPA72, 1.5.8.1].

• Inhibit for the input loop [EN-54 part 2, 8.1.2].

Figure 42 FLD120 gas detector input loop

Loop status


Loop statusThe loop status (operational status, failure status and inhibited status) is indicated on TPS or Experion™ displays with an indication per status [EN-54 part 2, 7.2.b, 7.3.1, 8.2.1.b] [NFPA72, 1.5.7.1.1]. All states are also transferred to other FLDs via sheet transfers to generate the common status indication and to drive the audible indications (horn) [EN-54 part 2, 7.8]. [NFPA72, 1.5.7.2]

Individual fault, alarm and inhibit signals are also grouped per area or zone for the indication on TPS or Experion™ displays and on the mimic panel [NFPA72, 1.5.7.1.2]. See FLD 230 common low level alarm (Figure 43 on page 125) and FLD 232 common detector fault (Figure 44 on page 126).

Figure 43 FLD230 common low level alarm Area 1



Figure 44 FLD232 common F&G detector fault Area 1

Output loops


Output loopsThe basic Fire and Gas application has a number of output loops for the required safety actions and annunciation.

The various different output loops are described in detail below.

Sounders and beaconsOne of the main tasks of a F&G safety system is to alert people of potential hazards and initiate the required evacuation of buildings and areas [NFPA72, 3.2].

The main notification appliances are beacons, sounders and bells. An example of these sounders and beacons can be found on FLD 240 (Figure 45 on page 128).

These sounders and beacons shall be assigned and installed for each zone or area [NFPA72, 1.5.7.3].

These output signals are normally of the “energize-for-action” type. This means that a Safe reaction of the F&G safety system does not result in activation of these external alarming devices.

The loop shall be monitored for short circuit as a minimum [NFPA72, 1.5.8.4], while other possible faults, e.g. open loop or ground fault, shall not influence other output loops [NFPA72, 1.5.8.3].

It is advised to connect the notification appliances to line-monitored digital output modules, type SDOL-04xx. These modules provide full line-monitoring detection of short circuit as well as open loop.

Devices that have a very high power consumption cannot be connected to SDOL-04xx modules. In those cases the installation of an external switching device close to the notification appliance is advised. A SDOL-04xx module can monitor the loop to this external switching device.

Power can also be supplied by means of a Safe relay contact that switches the required power to the external device. For these solutions a short test-interval time is advised to assure regular testing and proper functioning of the non monitored parts of these output loops.



Deluge valveThe deluge valves of fire suppression systems are often directly controlled by the F&G safety system.

An example of the connection of such a deluge valve can be found on FLD 290 (Figure 46 on page 129).

These output signals are normally of the “energize-for-action” type. This means that a Safe reaction of the F&G safety system does not result in opening of the valve.

The deluge valves shall be connected to line-monitored digital output modules, type SDOL-04xx. These modules provide full line-monitoring of short circuit as well as open loop.

The status signals of the deluge valve (see FLD 162, Figure 47 on page 129) and related fire suppression system (see FLD 160, Figure 48 on page 130) are normally monitored and sent to the control system [NFPA72, 3.8.6.3].

Figure 45 FLD240 sounders and beacons

Output loops


Figure 46 FLD290 deluge valve

Figure 47 FLD162 status signals deluge valve



Firewater pumpsThe firewater pumps for the fire suppression systems are often directly controlled by the F&G safety system.

An example of the connection of firewater pumps can be found on FLD 260 (Figure 49 on page 131).

The firewater pumps are started by fire or gas detection of the F&G safety system or by manual activation on the mimic panel.

The status of the firewater pumps is monitored by the F&G safety system [NFPA72, 3.8.9], to check the actual state. It checks the required running state because firewater pumps can also be started manually or by other systems, see FLD 262 (Figure 50 on page 131).

The start signal of the firewater pump of the F&G safety system is normally a “de-energize-to-start” type. This means that the Safe state of the F&G safety system starts the firewater pumps. The firewater pumps do not normally activate the fire suppression systems but bring these systems to the required pressure.

In the case that the start of the firewater pumps do initiate the activation of the fire suppression systems, the start signal is of the “energize-to-start” type so that the Safe states of the F&G safety system do not directly lead to activation of the fire suppression systems. These signals are normally line-monitored.

Figure 48 FLD160 status signals fire suppression system

Output loops


The start signals are normally pulsed and routed via dedicated motor control systems. These systems shall comply with the required standards [NFPA72, 3.8.9.1].

Figure 49 FLD260 start firewater pump(s)

Figure 50 FLD262 discrepancy alarm firewater pump



PA/GA systemThe F&G safety system can sent an alarm signal to the PA/GA system.

An example of the connection of PA/GA system can be found on FLD 250 (Figure 51 on page 132).

The F&G safety system sends the alarm signal to the PA/GA system on a confirmed fire or gas detection.

The alarm signal to the PA/GA system of the F&G safety system is normally a “energize-to-start” type. This means that the Safe state of the F&G safety system does not lead to an F&G alarm to the PA/GA system. The signals in the basic F&G application are usually pulsed which depends on the actual requirements by the PA/GA system.

The PA/GA system shall comply with the required standards [NFPA72, 3.12].

HVAC systemThe climate in the rooms protected by the F&G safety systems is normally controlled by HVAC systems.

A HVAC system has to act in the case of the fire or gas detection. A part of these control actions are taken by the HVAC system. The F&G safety system transmits a hardwired fire alarm signal to the HVAC system in the case of a hazard detection [NFPA72 3.9.3.4]. This signal to the HVAC system of the F&G safety system is normally a “energize-to-act” type, so the Safe state of the F&G safety

Figure 51 FLD250 alarm signal to PA/GA

Output loops


system does not lead to actions by the HVAC system. See for example FLD 680 (Figure 52 on page 133).

The HVAC system normally also includes special fire dampers. These dampers are normally directly controlled by the F&G safety system, see for example FLD 690 (Figure 53 on page 134).

These signals are of the “energize-to-open” type. This means that the Safe reaction of the F&G safety system leads to closure of the fire dampers.

Figure 52 FLD680 HVAC trip signal



Figure 53 FLD690 close fire damper signals

Monitoring for alarm status


Monitoring for alarm statusThe input loops are monitored for alarms. If an alarm status occurs, an audible alarm (horn) must also be activated [EN-54 part 2, 7.1.4].

The first type of audible alarm is located on the mimic panel and operator consoles. For this purpose the alarms of all F&G detectors are grouped (see FLD 250, Figure 54 on page 136) to activate common F&G audible and visual alarm in FLD 2004 (Figure 55 on page 136).

In this example these alarms activate an alarm signal to an external PA/GA system as well [EN-54 part 2, 7.9].

The output signal to the PA/GA system can be inhibited as required by the applicable standards [EN-54 part 2, 9.4.1.c].

The second type of audible alarms is located inside the buildings and the detection zones to alert people in the affected zones for potential hazards. For this purpose the alarms of all F&G detectors are grouped per area or zone (see Figure 56 on page 137) to activate the common F&G audible alarms in the affected areas. Normally these audible alarms are combined with visual alarm devices such as flash beacons. [EN-54 part 2, 7.8]. The output signal to the sounders and beacons can be inhibited as required by the applicable standards [EN-54 part 2, 9.4.2.a].

The visual alarm remains active as long as an alarm is active [NFPA72, 1.5.7.1], the audible alarm can be silenced by means of a reset signal [EN-54 part 2, 7.8.a]. For compliance with NFPA 72, this switch shall be of the key type [NFPA72, 1.5.4.8]. A new F&G alarm activates the horn again [EN-54 part 2, 7.4.3].



Figure 54 FLD250 grouping of alarm signals

Figure 55 FLD2004 Fire and Gas alarm lamp and buzzer on mimic panel

Monitoring for alarm status


Figure 56 FLD240 audible and visual alarm signals



Monitoring for failure statusAll components of the Fire & Gas system, including the input loops and output loops, are monitored for failures [EN-54 part 2, 8.2.4, 8.2.5.a] [NFPA72, 1.5.8.1]. If a failure occurs, an audible alarm (horn) must be activated which has a different tone than the Fire & Gas audible alarm [NFPA72, 1.5.4.6.1, 1.5.4.7 & 3.7.2].

This audible alarm is located on the mimic panel and operator consoles [NFPA72, 1.5.4.6.2]. For this purpose the faults of all F&G detectors are grouped (see FLD 232, Figure 57 on page 138) to activate a common General fault audible and visual alarm in FLD 2002 (Figure 58 on page 139).

The other faults collected in FLD 2002 (Figure 58 on page 139) to generate general fault alarm are:

• ‘OutputFault’ which indicates if an output module or F&G output loop is faulty [NFPA72, 1.5.8.4].

• Power supply failures which indicate that a power supply or circuit breaker fails. [NFPA72, 1.5.8.6.1]

• Earth leakage failure which indicates that an earth fault has been detected.

Figure 57 FLD232 grouping of detector fault signals

Monitoring for failure status


• ‘ExtComFaultCCX’ which indicates that a communication error is detected in communication channel X (select one of 8 available channels) [EN-54 part 2, 8.9].Depending on the application, other internal failures of Safety Manager™ can also be covered by the common failure alarm. If more than one failure group is used in aFire & Gas detection system, logic as shown in FLD 2002 (Figure 58 on page 139) is required for each failure group.

The visual alarm remains active as long as a fault is active [NFPA72, 1.5.4.6.3], the audible alarm can be silenced by means of a reset signal [EN-54 part 2, 8.6.1]. For compliance with NFPA 72, this switch shall be of the key operated type [NFPA72, 1.5.4.6.4]. A new fault will activate the horn again [EN-54 part 2, 8.6.3].

Figure 58 FLD2002 general fault alarm lamp and buzzer on mimic panel



Inhibit functionDuring operation it may be required that a detector device needs to be inhibited for a certain period to avoid nuisance alarms during that period [EN-54 part 29.4.a]. An inhibit can be required during the replacement of the detector device or because of other external activities (e.g. welding activities in the neighborhood of a smoke detector).

Inhibition of a detector device is only allowed under certain conditions. The inhibition has to be enabled by means of a hardwired ENABLE switch [EN-54 part 2, 9.1.2] on the mimic panel and Safety Manager™ checks that only a certain amount of inhibits (M) are active within a predefined group. The inhibit request of a certain detector device is made by the operator on the operator console by means of a soft key switch. The inhibit request signal is transferred to Safety Manager via the serial link. Safety Manager checks if the conditions are met (ENABLE switch on, amount of active inhibits < M). In case the inhibit request is granted, the inhibit indication signal is send to Experion™ [EN-54 part 2, 9.2.b] and the inhibit signal of the specific detector is sent to the Safety Manager logic. See for example FLD 101 (Figure 59 on page 140). For more details on M-out-of-N inhibit functionality, refer to the Fire and Gas Application manual.

Inhibit signals are also grouped per area to generate a common inhibit indication per area on the F&G mimic panel and the overall display on the Experion console [EN-54 part 2, 9.2.a]. See FLD 234 (Figure 60 on page 141) for inhibited F&G detectors and FLD 236 (Figure 61 on page 141) for F&G inhibited outputs.

Figure 59 FLD101 inhibit M-out-of-N function F&G detector devices

Inhibit function


Figure 60 FLD234 common F&G detector inhibited Area 1

Figure 61 FLD236 common F&G outputs inhibited Area 1


10Special requirements for TUV-approved applications

Safety Manager™ can be used for processes which require, amongst others, TUV approval. The requirements for the safety applications are the following:

1. The maximum application cycle time is half the Process Safety Time. For example, the accepted Process Safety Time for a burner control system in accordance with TRD-411 for boilers > 30 kW (July 1985) Table 1, TRD-412 (July 1985) Table 1 and DIN 4788 (June 1977) Part 2 Chapter 3.2.3.2 1 is 1 second. This implies that the application cycle time must be 0.5 second or less. The application cycle time is calculated by the SM Controller and can be seen on the System Information screen of Controller Management. The application execution time is limited to 2 seconds by the hardware of the watchdog.

2. If Safety Manager detects a fault in its output hardware that is configured with Fault Reaction Low, it can de-energize parts of the process instead of de-energizing all outputs. The de-energization of process parts or all outputs is fully implemented in the software and cannot be influenced by the user (see also item 3). The de-energization depends on the output module type:

10 – Special requirements for TUV-approved applications


If a complete output module (configured with Fault Reaction Low) is detected faulty, all outputs connected to the Control Processor that controls the output module are de-energized via the watchdog functionality of the Control Processor. If the output is located in a non-redundant IO section, all outputs of Safety Manager are de-energized. De-energization is only effected if safety-related outputs are allocated to the faulty module.

3. If Safety Manager detects a fault in its output hardware (configured with Fault Reaction Low, see item 2 above), a repair timer is started. When this timer expires, all outputs are de-energized via the watchdog functionality. This timer can be set to the following values:

• Not used. The timer is not started so an output fault may be present in the system without further action.

• 0 minutes. This results in immediate de-energization of all outputs in case of an output fault.

• 0 hours to 2047 hours. This represents the interval time between the fault occurrence and automatic system shutdown.

4. If Safety Manager detects a fault in its input hardware (configured with Fault Reaction Low, High, Bottom scale, Top scale), the faulty input is set to its configured Fault Reaction state.

• SDO-0824 Safety Related digital output module(24 Vdc, 0.55 A, 8 channels)De-energization per group of output channels:Group 1: outputs 1, 2, 3, 4.Group 2: outputs 5, 6, 7, 8.

• SAO-0220m Safety Related analog output module(0(4)-20 mA, 2 channels)De-energization per channel.

• SDO-04110 Safety Related digital output module(110 Vdc, 0.32 A,4 channels)De-energization of group 1: outputs 1, 2, 3, 4.

• SDO-0448 Safety Related digital output module(48 Vdc, 0.75 A, 4 channels)De-energization of group 1: outputs 1, 2, 3, 4.

• SDO-0424 Safety Related digital output module(24 Vdc, 2 A, 4 channels)De-energization of group 1: outputs 1, 2De-energization of group 2: outputs 3, 4.

• SDOL-0424 Safety Related loop-monitored digital output module (24 Vdc, 1 A, 4 channels)De-energization of group 1: outputs 1 to 4.


5. The watchdog functionality of Safety Manager contains a shutdown (SD) input. For normal operation, the SD input must be 24 Vdc. If the input is forced to 0 V, a Safety Manager shutdown and de-energization of the outputs take place, independent of the QPP.

6. For more details on IO wiring details, termination of IO signals and power supply distribution see Hardware Reference.

7. The Diagnostic Test Interval (DTI, the time in which all IO tests are executed) can be set for each SM Controller in the Controller Properties in the Network Configurator.

8. The repair timer can be set for each SM Controller in the Controller Properties in the Hardware Configurator.

9. The values of the voltage monitor analog input channels of the SAI-1620m modules must be checked in the application to ensure that they are within the transmitter power supply range of the transmitters connected to that analog input module.

10. To reduce the influence of disturbances on the power supply lines, all major metal parts (cabinet sidewalls, doors, 19-inch chassis, horizontal bus chassis and flaps, swing frames, etc.) must be properly grounded.

11. All power supply inputs (except 110/230 Vac) require a power supply filter directly fitted after the power supply input terminals.

12. Grounding of the power supplies of Safety Manager is only permitted for the 0 Vdc. Grounding of the +24 Vdc / +48 Vdc / +60 Vdc / +110 Vdc is not allowed because an earth fault results in an unsafe situation.

13. The wiring of the external power supply (24 Vdc) and the internal power supply (5 Vdc) must be physically separated. This can be realized by using separate ducts and a separate power supply distribution.

14. Do not use radio frequency transmitting equipment within a radius of 1 m (3 ft) of the system cabinet when the doors are opened.

15. Safety-related inputs require the use of tested input modules (SDI-1624, SDI-1648, SAI-1620mm, SAI-0410, or SDIL-1608) and safety-related input sensors (transmitters). If the input sensors (transmitters) are not safety related, multiple sensors (transmitters) must be used.

16. If Safety Manager operates without operator surveillance, some measures have to be taken. During the design and implementation stages of the safety system a reliability calculation analysis (the maximum time period in which inspection has to take place) has to be performed. Without operator



surveillance the following measures have to be taken to comply with the safety integrity requirements:

• Inspection of Safety Manager status if the Safety Manager application is fault free, at least once per determined time period.

• Alarm indication of Safety Manager if a fault is detected and subsequent inspection of the Safety Manager status within the safety determined time period.

17. The operating conditions of Safety Manager shall not exceed the following ranges:)

• Operating temperature: -5°C to 70°C (23°F to 158°F)

• Relative humidity: 5% to 95%, non-condensing

• Vibration: 1G (10-55-10 Hz)

• Shock: 15 G (11 ms, 3 axes, both directions of the axe)

• Supply voltage: 110 Vdc (+25% / -15%), 48 Vdc (+15% / - 15%), 24 Vdc (+30% / -15%)

For details refer to Hardware Reference.The operating temperature is measured in Safety Manager. This temperature is higher than the temperature outside the cabinet, which results in a lower ambient temperature for the cabinet. Depending on the internal dissipation in the cabinet and the ventilation, a temperature difference of 25°C (77°F) is allowed, which results in a maximum ambient temperature of 45°C (113°F). To minimize the temperature difference, forced ventilation with one or more fans may be required. By using the temperature pre-alarm setpoints, an alarm can be given if the internal temperature is too high.

18. The storage conditions of the Safety Manager hardware modules shall not exceed the following ranges:Storage temperature: –25 to +80°C (–13 to 176°F).

F&G applicationsFire and Gas (F&G) applications have the following additional requirements:

1. Each visual indication (alarm, override or test, failure) shall have its own dedicated digital output. This digital output may be a hardware output or a communication output, e.g. to a DCS system. Override and test status may be combined in one visual indication. Alphanumeric displays are not supported.

2. Redundant power supplies must be connected to Safety Manager in such a way that the redundant power supplies do not fail at the same time, e.g. by using different primary power sources (e.g. 220 Vac mains and a 24 Vdc from a battery backup). Detection of power supply failure (e.g. via a voltage-monitoring module) shall be part of the system design.


3. Faults in the Fire & Gas detection system are indicated visually. This indication must also be active if the Fire & Gas detection system has been switched off. This can be set up as shown in Figure 62 on page 147, using a normally de-energized relay, or via a visual indication in a DCS display which is activated if the communication to the Fire & Gas detection system fails. The protected side of the fuses are connected to a voltage-monitoring device to detect blown fuses.

4. The field instruments, including panel instruments such as (key) switches, which are used in conjunction with Safety Manager, must meet the requirements of the applicable parts of the EN-54 standard. Visual and audible indications shall be as defined in paragraph 3.2 of EN-54 part 2.

5. Field inputs must have loop-monitoring to detect short-circuits and open loops. Input module types that can be used are: SAI-0410, SAI-1620m and SDIL-1608.Field outputs must also have loop-monitoring. Output module type that can be used: SDOL-0424.

6. The Fire & Gas detection system shall have earth leakage monitoring/detection facilities.

7. Remote display of alarms, failures etc. may only be given via interconnection of Safety Manager systems using the communication option between Safety Manager systems or via hard wired outputs with loop-monitoring via the

Figure 62 Power supply

Power Supply Unit 2e.g. 200 VAC

Power Supply Unit 1e.g. 200 VAC

200 VAC / 24 VDC

Voltage Monitoring

Safety Manager

Controllerfault

0 VDC



SDOL-0424 digital output modules. Communication and loop monitoring failures must be alarmed.

8. Safety Manager is only the basis for an EN-54 compliant application. The responsibility for a full EN-54 compliant application lies with the person(s) responsible for configuring and application programming of Safety Manager. The requirements of EN-54 which must be met by the application can be found in section 9, which references the requirements that must be fulfilled in the application.

9. For details on the requirements of the mechanical construction (cabinet, indications, horns) refer to “EN-54 part 2 paragraph 3.2.”

List of abbreviations


List of abbreviationsAI Analog Input

AO Analog Output

ASM Abnormal Situation Management

BKM Battery and Key switch Module

BMS Burner Management System

CP Control Processor

DCS Distributed Control System

DI Digital Input

DO Digital Output

DTI Diagnostic Test Interval

E/E/PES Electrical/Electronic/Programmable Electronic System

EMC Electromagnetic Compatibility

ESD • Electrostatic Discharge• Emergency ShutDown system

EUC Equipment Under Control

EUT Equipment Under Test

F&G Fire and Gas

FB Function Block

FGS Fire and Gas System

FLD Functional Logic Diagram

FTA Field Termination Assembly

FTE Fault Tolerant Ethernet

HIPS High-Integrity Protection Systems

HMI Human Machine Interface

HSE High Speed Ethernet

IO Input/Output

IP • Internet Protocol• Ingress Protection

IS Intrinsically Safe

LAN Local Area Network

LED Light-Emitting Diode

MAC Media Access Control

MAP Manufacturing Automation Protocol

List of abbreviations


MOS Maintenance Override Switch

MTBF Mean Time Between Failure

MTTF Mean Time To Failure

MTTR Mean Time To Repair

OLE Object Linking and Embedding

OPC Object linking and embedding for Process Control

OS Operating System

P&ID Piping and Instrumentation Diagram

PE Protective Earth

PES Programmable Electronic System

PFD Probability of Failure on Demand

PKS Process Knowledge System

PLC Programmable Logic Controller

PST Process Safety Time

PSU Power Supply Unit

PUC Process Under Control

PV Process Value

QMR Quadruple Modular Redundant

QPP Quad Processor Pack

RFI Radio Frequency Interference

SCADA Supervisory Control And Data Acquisition

SIC System Interconnection Cable

SIF Safety Instrumented Function

SIL Safety Integrity Level

SIS Safety Instrumented System

SMOD Secondary Means Of De-energization

SRS Safety-Related System

USI Universal Safety Interface

UTP Unshielded Twisted Pair

WAN Wide Area Network

Safety Manager Glossary


Safety Manager GlossaryA

AlarmAn automatic signal that serves as a warning of an event or danger.

ApplicationThe definition of the EUC-dependent function for Safety Manager.

Application CompilerA tool of the Safety Builder used to create a controller file.

Application EditorA tool of the Safety Builder used to create or edit functional logic diagrams.

Application valueThe value of a process Point as provided to, or calculated by, the application software.

Application ViewerA tool of the Safety Builder used to view functional logic diagrams on-line.

Availability• The ratio of system up time to total operating time.

• The ability of an item to perform its designated function when required for use.



B

Battery and Key switch Module (BKM)A module in the SM Controller used to:

• Supply battery power to the system memory (RAM) and the real time clock of the Control Processor modules, in case of power outage.

• Enable or disable forces, by turning the Force key switch. When enabled, forcing of certain input and output signals is allowed. When disabled, all forces are removed.

• Provide a fault reset, by turning the Reset key switch. See Fault reset.

C

Communication moduleSee: Universal Safety Interface (USI)

Communication time-outAn error caused by an unacceptable large time interval during which there was no communication.

Control Processor (CP)Core component of the SM Controller consisting of: Power Supply Unit (PSU), Quadruple Processor Pack (QPP) and 1 or 2 communication modules (USI).

Controller chassis19” chassis to slot the BKM and Control Processor modules.

Controller ManagementA tool of the Safety Builder used to perform the following functions:

• Load controller.

• View system status.

• Retrieve controller and application files.

Cycle timeThe time period needed to execute the application software once.

WarningTurning the Reset key switch during an On-Line Modification procedure may cause the Control Processors to swap status.



D

Database RebuilderRepair function for the information storage for Safety Builder created databases.

Deutsches Institut für Normung (DIN)German Institute for Standards, which determines the standards for electrical and other equipment in Germany.

Diagnostic Test Interval (DTI)The time period used by Safety Manager to cyclically locate and isolate safety related faults within on-line system components that could otherwise cause a hazardous situation. See also “Process Safety Time (PST)” on page 162.

Within Safety Manager, the default DTI is set at three seconds.

Distributed Control System (DCS)System designed to control industrial processes. A DCS receives the measured values of the process instrumentation, e.g. flow, pressure, temperature. It controls the process via analog control equipment such as control valves. In addition, a DCS may receive many digital signals for alarm and management purposes.

Dual Modular Redundant (DMR)Safety configuration providing 1oo2 configuration. The DMR technology is used in the architecture of a non redundant QPP where on-board 1oo2D voting is based on dual-processor technology.

DMR is characterized by a high level of diagnostics and fault coverage.

E

Electrical/Electronic/Programmable Electronic (E/E/PE) deviceA device based on electrical (E) and/or electronic (E) and/or programmable electronic (PE) technology.

NoteThis term is intended to cover any and all devices operating on electrical principles and would include:• electro-mechanical devices (“electrical”);• solid state non-programmable electronic devices (“electronic”);• electronic devices based on computer technology (“programmable electronic”).



Electrical/Electronic/Programmable Electronic system (E/E/PES)A system based on one or more E/E/PE devices, connected to (and including) input devices (e.g. sensors) and/or output devices/final elements (e.g. actuators), for the purpose of control, protection or monitoring.

See also: “Programmable Electronic System (PES)” on page 162.

Electromagnetic Compatibility (EMC)The ability of a device, equipment or system to function satisfactory in its electromagnetic environment without introducing intolerable electromagnetic disturbances to anything in that environment.

Electrostatic discharge (ESD)The transfer of electrostatic charge between bodies of different electrostatic potential, which may cause damage to system components.

Emergency Shutdown (ESD)Manual or automatic turning off or closing down of process equipment in case of anomalous conditions in order to prevent damage to the system or process.

Equipment Under Control (EUC)Equipment/machinery/apparatus/Plant used for manufacturing, process, transportation, medical or other activities for which designated safety-related systems could be used to:

• prevent hazardous events associated with the EUC from taking place; or,

• mitigate the effects of the hazardous events.

ErrorSee the Safety Manual.

EthernetA local area network specification developed by Xerox in 1976. The specification served as the basis for the IEEE 802.3 standard, which specifies the physical and lower software layers of the network. It uses CSMA/CD to handle simultaneous transmissions and is the most popular LAN Technology is use today. More commonly used to reference an Ethernet Network running at 10 Mb/s.

See also: Local Area Network (LAN).

Event• Occurrence of some programmed action within a process which can affect

another process.

• Asynchronous occurrence that is detected by the control system, time and other information is recorded, e.g. process alarm.



Experion PKSHoneywell Process Knowledge System™ for process, business and asset management.

Experion PKS StationWindows 2000 based station for viewing process schematics and interactions with the system. This station provides comprehensive alarm and event detection, management, reporting facilities, and history collection along with the capability of custom process graphics.

External risk reduction measuresPhysical measures taken externally to safety-related systems to reduce or mitigate the risks. Examples would include a drain system, fire wall, etc.

F

FailureSee the Safety Manual.

FaultSee the Safety Manual.

Fault resetAn action that clears the fault database and attempts a restart of tripped or halted components of the system.

Fault Tolerant Ethernet (FTE)Experion PKS patented advanced networking solution that delivers greater system availability.

FCPrefix used to identify conformal-coated module from non conformal coated modules. See also: FS.

• FC-SDI-1624 is a safe digital input module with conformal coating

• FS-SDI-1624 is a safe digital input module without conformal coating

Field Termination Assembly (FTA)Assembly to connect field wiring to the SM IO modules.

Field valueThe value of a process Point as present at the interface of the system with the EUC.



FieldbusWiring solution and communication protocol in which multiple sensors and actuators are connected to a DCS or SIS, using a single cable.

Fire and Gas systemIndependent protective system which continuously monitors certain process Points (e.g. combustible gas levels) and environmental Points (e.g. heat, smoke, temperature and toxic gas levels). If any of these Points exceed a predetermined level, the system will raise an alarm and take automatic action to close operating valves and damper doors, activate extinguishers, cut off electrical power and vent dangerous gases.

ForceA signal override of some sort that is applied on a system level.

A force applied to an input affects the input application state as it overrides the actual field value and diagnostic state of the forced input.

A force applied to an output affects the output field state as it overrides the application value or diagnostic value with the forced value.

FSPrefix used to identify non conformal-coated module from conformal coated modules. See also: FC.

• FS-SDI-1624 is a safe digital input module without conformal coating

• FC-SDI-1624 is a safe digital input module with conformal coating

Function blockElement in a functional logic diagram (FLD) which performs a user defined logic function. Function blocks are designed to implement & re-use complex functions via a single (user defined) element.

Functional Logic Diagram (FLD)Diagrammatic representation of the application (conform the IEC 61131-3 standard) which is used to program Safety Manager. FLDs are directly translated into code that can be executed by Safety Manager, thus eliminating the need for manual programming. See also: Application Editor.

CautionForcing introduces a potentially dangerous situation as the corresponding Point could go unnoticed to the unsafe state while the force is active.



Functional safetySee the Safety Manual.

Functional safety assessmentSee the Safety Manual.

H

Hardware ConfiguratorA tool of the Safety Builder used to configure the hardware of Safety Manager.

Hardware safety integritySee the Safety Manual.

HazardA physical situation with a potential for human injury.

High voltage A voltage of 30VAC, 40VDC or above.

I

IEC 61131-3Part of the international standard IEC 61131, which provides a complete collection of standards on programmable controllers and their associated peripherals.

The IEC 61131-3 specifies the syntax and semantics of programming languages for programmable controllers as defined in part 1 of IEC 61131 (FLD symbols).

IEC 61508International IEC standard on functional safety entitled “Functional safety: safety-related systems”, which sets out a generic approach for all electrically based systems that are used to perform safety functions. A major objective of this international standard is to facilitate the development of application sector standards.

NoteThe term includes danger to persons arising within a short time scale (e.g. fire and explosion) and also those that have a long-term effect on a persons health (e.g. release of a toxic substance).



Institute of Electrical and Electronic Engineers (IEEE)An American professional organization of scientists and engineers whose purpose is the advancement of electrical engineering, electronics and allied branches of engineering and science. It also acts as a standardization body.

International Electrotechnical Commission (IEC)An international standards development and certification group in the area of electronics and electrical engineering, including industrial process measurement, control and safety.

Interval time between faultsSee: Repair time.

IO busA bus-structure within Safety Manager that interconnects the Control Processor with the IO.

IO bus driverPart of the Quad Processor Pack that controls the IO bus.

IO chassis19” chassis to slot the (redundant) IO extender(s) and SM IO modules.

IO databaseDatabase in which input, output and configuration data is stored.

IO extenderModule which controls the IO bus of the IO chassis. A maximum of ten IO extender modules can be connected to one IO bus.

IO moduleModule which handles input or output functions of Safety Manager. IO modules can be digital or analog.

L

Local Area Network (LAN)A general term to refer to the network and its components that are local to a particular set of devices.

See also: Wide area network (WAN).



M

Maintenance overrideA function, which allows the user to apply an application value to an input independent of the input channel scan value.

Maintenance Override Switch (MOS)Switch used to file a request for a maintenance override. Acknowledgement is decided by the application program. An acknowledged maintenance override allows maintenance to be performed on field sensors or field inputs without causing the safety system to trip the process.

Master-clock sourceThe source that is responsible for the time synchronization between a group of systems or within a network.

Mean Time Between Failure (MTBF)• For a stated period in the life of a functional unit, the mean value of the length

of time between consecutive failures under stated conditions.

• The expected or observed time between consecutive failures in a system or component.

MTBF is used for items which involve repair.

See also: Mean Time To Repair (MTTR), Mean Time To Failure (MTTF).

Mean Time To Failure (MTTF)The average time the system or component of the system works without failing.

MTTF is used for items with no repair.

See also: Mean Time To Repair (MTTR), Mean Time Between Failure (MTBF).

Mean Time To Repair (MTTR)The mean time to repair a safety-related system, or part thereof. This time is measured from the time the failure occurs to the time the repair is completed.

Media Access Control (MAC)The lower sublayer of the data link layer (Layer 2) unique to each IEEE 802 local area network. MAC provides a mechanism by which users access (share) the network.

Mode of operationSee the Safety Manual.



Multidrop linkA multidrop link is a physical link that interconnects multiple systems (see Figure Figure 63 on page 160).

N

NamurA 2-wire proximity switch operating at a working voltage of 8.2 V and an operating current of 8mA max (CENELEC Standard). Because of the small amount of energy needed to operate NAMUR sensors, they can be used in intrinsically safe applications.

Network ConfiguratorA tool of the Safety Builder used to configure the communication architecture.

NodeHardware entity connected to a network.

O

Object linking and embedding for Process Control (OPC)Technology developed originally by Microsoft, now being standardized. Microsoft technology for application interoperability. Object Linking and Embedding (OLE) is a set of services that provides a powerful means to create documents consisting of multiple sources of information from different applications. Objects can be almost any type of information, including text, bitmap images, vector graphics, voice, or video clips.

Figure 63 Multidrop link

CP 1

CP 1Master

Slave 1 Slave 2 Slave 3CP 1 CP 1

NoteSpecial switching amplifiers or dedicated input modules, like the SDIL-1624, are required to read the status of NAMUR proximity switches.



Off-lineA system is said to be “off-line” when it is not in active control of equipment or a process.

A process or equipment is said to be “off-line” when it is in shut-down.

On-lineA system is said to be “on-line” when it is in active control of equipment or a process.

A process or equipment is said to be “on-line” when it is operating.

Operating temperatureThe temperature a system is operating on. The operating temperature is measured in the CP chassis at the QPP module.

Operational stateThe values of an application Point during normal process operation.

P

Peer-to-peerA logical connection between two points.

PlantA component of Safety Builder which represents a collection of devices, controllers and communication networks interconnecting the devices and controllers.

PointA data structure in the IO database, usually containing information about a field entity. A point can contain one or more parameters. Safety Manager uses different point types to represent a range of different field values.

Point ConfiguratorA tool of the Safety Builder used to create and modify Points of a SM Controller.

Point ViewerA tool of the Safety Builder used to view Points with dynamic update of states and values.

Power Supply Unit (PSU)Separate module which supplies electrical power to the SM Controller.



Probability of Failure on Demand (PFD)A value that indicates the probability of a system failing to respond to a demand. PFD equals 1 minus Safety Availability. (ISA, S84.01, 1996)

Process Safety Time (PST)The time that a process can tolerate a faulty situation without causing a hazardous situation. See also “Diagnostic Test Interval (DTI)” on page 153.

Process valueAn amount, expressed in engineering units, that represents the value of a process variable, e.g. a temperature, a pressure or a flow.

Programmable Electronic System (PES)See the Safety Manual.

Programmable Electronics (PE)See the Safety Manual.

Q

Quad Processor Pack (QPP)The main processing module of the SM Controller.

Quadruple Modular Redundant (QMR)Safety configuration providing a 2oo4D configuration. The QMR technology is used in the architecture of a redundant QPP where on-board 1oo2D voting (see Dual Modular Redundant (DMR)) is combined with 1oo2D voting between the two QPPs.

Voting takes place on two levels: First on a module level and secondly between the Control Processors.

QMR is characterized by a high level of diagnostics, fault coverage and fault tolerance.

R

Redundancy• In an item, the existence of more than one means of performing a required

function.

• Use of duplicate (or triple or quadruple) modules or devices to minimize the chance that a failure might disable an entire system.



Repair time• The time required to identify the location of a fault and repair the fault.

• A time window allowed by the system to identify the location of a fault and repair the fault. If the repair is not successfully completed within the given time window a trip is to be expected.

Repair timerA count-down timer that starts if a fault has been detected which degrades the existing safety level of Safety Manager.

A repair timer keeps track of the remaining repair time (see Repair time) and can only be reset by repairing the fault that initiated the timer.

If a repair timer runs out, the corresponding Control Processor halts.

ResetSee: Fault reset.

RiskSee the Safety Manual.

RouterA network device which forwards packets (messages or fragments of messages) between networks.

The forwarding decision is based on network layer information and routing tables, often constructed by routing protocols.

S

SafetySee the Safety Manual.

Safety AvailabilityThe fraction of time (%) that a safety system is able to perform its designated safety service when the process is operating. See also “Probability of Failure on Demand (PFD)” on page 162.

Safety BuilderStation software used to configure, design, validate, log and monitor a Safety Manager project.



Safety Instrumented Function (SIF)A Safety Instrumented Function (SIF) is an isolated function, initially designed to protect “life and limb” against a specific hazard. A more popular term for SIF is safety loop. Each SIF operates on its own Safety Integrity Level.

See also:

• “Safety instrumented System (SIS)” on page 164

• “Safety Integrity Level (SIL)” on page 164

Safety instrumented System (SIS)A Safety Instrumented System (SIS) is a system that executes one or more SIFs. The various SIFs inside a SIS may each require a different Safety Integrity Level. A SIS should be able to support all SIFs, including the one with the highest SIL level.

See also:

• “Safety Instrumented Function (SIF)” on page 164

• “Safety Integrity Level (SIL)” on page 164

Safety integritySee the Safety Manual.

Safety Integrity Level (SIL)See the Safety Manual.

Safety life cycleSee the Safety Manual.

Safety ManagerA safety solution to protect the integrity of the process. Safety Manager includes the following components:

• Safety Manager

• Safety Station

For details see the Overview Guide.

Safety-related system (SRS)See the Safety Manual.

Safety StationStation running Safety Builder and Safety Historian.

Second fault timerSee: Repair timer.



Secondary Means Of De-energization (SMOD)Auxiliary transistor on the output module, which is de-energized in case a “stuck at” failure occurs at one of the output transistors (due to random hardware failures). This results in a safe state for the output.

ShutdownA process by which an operating Plant or system is brought to a non-operational state.

SICCIO signal wiring using system interconnection cables that hook up the FTA board to the IO.

SICPIO signal wiring using system interconnection cables that hook up the screw terminals to the IO.

SM ControllerAssembly of Control Processor, Controller chassis and BKM. A Controller can be redundant or non redundant. A redundant Controller contains two Control Processors. A non redundant Controller contains one Control Processor. Note that IO is not included.

SM IOA set of IO chassis linked to a Safety Manager Controller.

Safety ManagerAn Safety Manager™ comprises the following subsystems:

• SM Controller

• SM IO

• FTA

For details see the Overview Guide.

Storage temperatureThe temperature the system can be stored at.

SwitchA network device which forwards packets (messages or fragments of messages) by means of packet switching.

The forwarding decision is based on the most expedient route (as determined by some routing algorithm). Not all packets travelling between the same two hosts, even those from a single message, will necessarily follow the same route.



System Interconnection Cable (SIC)Cables to connect IO modules with FTAs or terminals.

T

TimestampAs a verb, the act of putting the current time together with an event. As a noun, the time value held with an event.

TrendA display defined primarily for presentation of and navigation through historical information.

TripAn action by which part of an operating Plant or system is brought to a non-operational state.

See also: Shutdown.

Triple Modular Redundant (TMR)Safety technology which is based on comparison principles and which requires triplicated system components.

U

Universal Safety Interface (USI)Communication module of the SM Controller.

V

ValidationSee the Safety Manual.



VerificationConfirmation by examination and provision of objective evidence that the specified requirements have been fulfilled.

Voting configurationTo prevent that a safety-related system remains passive or false signals occur in this system it is possible to use voting. With voting the safety-related system makes a decision based on signals. The usage of more than one signal enhances the safety and reliability of the system.

W

WatchdogA combination of diagnostics and an output device (typically a switch) the aim of which is to monitor the correct operation of the programmable electronic (PE) devices and takes action upon detection of an incorrect operation.

Wide area network (WAN)A general term to refer to a piece of a network and its components that are used to inter-connect multiple LANs over a wide area.

NoteIn the context of IEC 61508, verification means the process of demonstrating for each phase of the relevant safety lifecycle (overall, E/E/PES, software), by analysis and/or tests, that, for the specific inputs, the deliverables meet in all respects the objectives and requirements set for the specific phase.Examples of verification activities would include:1. Reviews on deliverables (documents from all phases of the safety lifecycle) to ensure

compliance with the objectives and requirements of the phase taking into account the specific inputs to that phase.

2. Design reviews.3. Tests performed on the designed products to ensure that they perform according to

their specifications.4. Integration tests performed where different parts of a system are put together in a

step-by-step manner and by the performance of environmental tests to ensure that all the parts work together in the specified manner.

NoteThe watchdog is used to de-energize a group of safety outputs when dangerous failures are detected in order to put the EUC into a safe state. The watchdog is used to increase the on-line diagnostic coverage of the logic system


Index

Aalarm markers 116

behavior 84FaultReset 116normal state 84

alarms 135allocation IO signals 61analog input faults 89Analog inputs (AI)

Synchronization 95analog output faults 91application 57, 62, 120, 143

database 57, 62program cycle time 143software implementation 62

application design 7architectures Safety Manager 32availability 32

Bbasic skills and knowledge 3BKM faults 101

Ccalculation errors 104

calculated value outside specified range 104counter outside specified range 104divide by zero 104function blocks 106overflow 104prevention 104square root negative number 104

Canadian Standards Association (CSA) 14CE compliance 13CE marking 18channel status 85clearing all forces 68

clock source 159communication 51

~ link 51communication faults 102compare error 94compatibility check 70

on-line modification 70compliance standards 13, 15, 18configurations Safety

Manager 32, 33, 34, 35, 37, 39availability requirements 32basic architectures 32Dual Modular Redundant (DMR)

architecture 32non-redundant Controller, non-redundant

IO 34Quadruple Modular Redundant (QMR)

architecture 33redundant Controller, non-redundant IO 35redundant Controller, redundant IO 37redundant Controller, redundant IO,

non-redundant IO 39connections safety system 49continuous mode of operation 25, 27Controller properties 59, 60

diagnostic test interval 60maximum repair time 60safety integrity level 59

cycle time 143

Ddangerous failure 22databases 57, 62

IO database 57de-energization 143, 144deluge valve 128design phases 44

ESD system 44safety system 44

detector 124


Index

detectors 121diagnostic inputs 82, 85, 115

LoopI 86LoopO 86SensAI 86

diagnostic message 76diagnostic test interval 60, 143

Controller properties 60diagnostics

calculation errors 105digital input faults 88Digital inputs (I)

Synchronization 95digital output faults 89directives 18, 19, 20

EMC directive (89/336/EEC) 19low voltage directive (73/23/EEC) 20

DTI 60, 143Controller properties 60

Dual Modular Redundant (DMR) 32

Eearth leakage monitoring/detection 147Electromagnetic Compatibility (EMC) 19electromagnetic disturbance 19EMC directive (89/336/EEC) 19emergency shutdown (ESD) 112, 145

input 145Equipment Under Control (EUC) 4, 5error 22, 24

human ~ 24ESD system 44

design phases 44EU directives 18, 19, 20EUC risk 22European Committee for Standardization 13European Economic Area (EEA) 19, 20European Union 18, 19, 20

FF&G

alarms 135deluge valve 128firewater pumps 130HVAC system 132PA/GA system 132

F&G detectors 121Factory Mutual (FM) 14failure 22, 26, 60

dangerous ~ 22isolation 60safe ~ 26

fault 23, 71, 138, 144database 76detection 72, 75reaction 72reaction state 77repair 81response 72timer 144

fault detectioncycle 76

fault detection and responsebehavior alarm markers 84

faultsanalog input 89analog output 91BKM 101calculation errors 104communication 102digital input 88digital output 89IO compare 94PSU 102QPP 99USI 101

field instruments 147filters 145Fire & Gas 120Fire&Gas (F&G) applications 146, 147

earth leakage monitoring/detection 147field instruments 147loop-monitoring 147redundant power supplies 146remote display 147requirements 146

firewater pumps 130force

clear all 68key switch 68

forcing inputs/outputs 68clearing all forces 68

function blockscalculation errors 106

Functional Block Diagram 7

Index


functional logic diagrams (FLDs) 51, 58functional safety 23functional safety assessment 24functional safety standards 13

Ggrounding 145

Hhardware safety integrity 24hazard analysis 9high demand mode of operation 25, 27human error 24humidity 146

relative ~ 146HVAC system 132

IIEC 61131-3 13IEC 61508 4, 8, 9IEC 61511 4, 8, 9implementation 62

application software 62inhibit 140input filters 145input signals 61

physical allocation 61Input synchronization

Analog inputs 95Digital inputs 95

inputs 68clearing all forces 68

Instrument Society of America (ISA) 13instrumentation 49

~ index 49safety system 49

International Electronical Commission (IEC) 13interval time between faults 60IO compare faults 94IO database 57, 62IO signals 61

physical allocation 61isolate 72

Lladder diagram 7line-monitored 127Lloyds Register of Shipping 14logical functions (in FLDs) 51loop status 86LoopI diagnostic input 86loop-monitoring 147LoopO diagnostic input 86low demand mode of operation 25, 27low voltage directive (73/23/EEC) 20

Mmarker

diagnostic 76diagnostic message 76

markersalarm 76, 82, 83state 84system 82

master ~ 159mode of operation 25, 27

continuous ~ 25, 27high demand ~ 25, 27low demand ~ 25, 27

Nnon-redundant Controller, non-redundant IO 34

Oon-line modification (OLM) 70

compatibility check 70operating conditions 146

operating temperature 146relative humidity 146shock 146vibration 146

operator surveillance 145, 146output signals 61

physical allocation 61outputs 68

clearing all forces 68


Index

PPA/GA system 132phases 44

ESD system 44safety system 44

physical allocation 61Safety Manager 61

points 68clearing all forces 68

power supply 145, 146~ failure 146~ filters 145redundant unit (PSU) 146

power supply unit (PSU) 146redundant 146

prerequisite skills 3process 50, 113, 114

~ interface 50~ outputs (in unit shutdown) 114~ units 113

Process safety time 72Process Under Control (PUC) 4Programmable Electronic System (PES) 25PSU faults 102

QQPP faults 99Quad Processor Pack (QPP) 34

watchdog 34Quadruple Modular Redundant (QMR) 33

Rradio interference 145redundant 146

power supplies 146redundant Controller, non-redundant IO 35redundant Controller, redundant IO 37redundant Controller, redundant IO,

non-redundant IO 39registers

alarm 84system 83

relative humidity 146remote display 147Repair time 73

repair timer 73, 79, 144risk 26risk assessment 9risk reduction measures 42

SSafe 73safe failure 26safety 23, 26

functional ~ 23Safety Builder 56, 58

functions 58Safety Instrumented Function (SIF) 4Safety Instrumented System (SIS) 4safety integrity 24, 30

hardware ~ 24systematic ~ 30

Safety Integrity Level (SIL) 4safety integrity level (SIL) 59safety life cycle 28, 41, 42, 44, 46

E/E/PES 42objectives 44phases 44sequence of phases 46software 42

Safety Manager 13, 61physical allocation 61standards compliance 13

Safety Manager configurations 32, 33, 34, 35, 37, 39

availability requirements 32basic architectures 32Dual Modular Redundant (DMR)

architecture 32non-redundant Controller, non-redundant

IO 34Quadruple Modular Redundant (QMR)

architecture 33redundant Controller, non-redundant IO 35redundant Controller, redundant IO 37redundant Controller, redundant IO,

non-redundant IO 39Safety related 73safety relation 115safety standards 13, 15, 18safety system 44, 49, 50, 51

connections 49

Index


design phases 44function 51instrumentation 49process interface 50

safety system specification 49, 50, 51, 53approval 53connections 49functional logic diagrams (FLDs) 51functionality 51IO signals 50

safety time 145safety-related inputs 145safety-related system 28Secondary Means 73Secondary Means of De-energization

(SMOD) 34self-tests 60SensAI diagnostic input 86shock 146shutdown 112, 113, 114, 115

emergency ~ (ESD) 112unit ~ 113, 114, 115

Single fault tolerant 74SIS 71SMOD 73smoke detectors 121sounders and beacons 127standards compliance 13, 15, 18states

Control Processor 74IO 75process 75

statuschannel 85loop 86

storage conditions 146structured text 7Synchronization

Analog inputs 95Digital inputs 95

synchronize 93, 94, 95system configuration parameters 59systematic safety integrity 30systems 32, 33, 34, 35, 37, 39

basic architectures 32Dual Modular Redundant (DMR)

architecture 32

non-redundant Controller, non-redundant IO 34

Quadruple Modular Redundant (QMR) architecture 33

redundant Controller, non-redundant IO 35redundant Controller, redundant IO 37redundant Controller, redundant IO,

non-redundant IO 39

Ttag numbers 49

description 49status 49

temperature 146operating ~ 146

textual languages 7time functions (in FLDs) 51time-out 103timer 144

fault 144TUV 14

UUL 1998 13Underwriters Laboratories (UL) 14unit relays 114unit shutdown 113, 114, 115

~ outputs 114application programming 115configuration 113diagnostic inputs 115process outputs (safety-related) 114safety relation of outputs 115

unit shutdown outputs 114USI faults 101

Vvalidation 30vibration 146voltage levels 145

separation 145voltage-monitoring 145, 146


Index

Wwatchdog 34, 80

Fax Transmittal Fax Number: +31 (0)73 6219 125

Reader Comments

To: Honeywell Safety Management Systems, attn. Technical Documentation Group

From: Name: Date:

Title:

Company:

Address:

City: State: Zip:

Telephone: Fax:

Safety Manager Safety Manual, Release 101, Issue 5, 20 June 2005

Comments:

You may also call the Technical Documentation Group at +31 (0)73 6273 273,email Honeywell SMS at [email protected], or write to:

Honeywell Industry SolutionsSafety Management SystemsP.O. box 1165201 AC ‘s-HertogenboschThe Netherlands

Safety ManagerUser documentation

Honeywell Industry SolutionsSafety Management SystemsRietveldenweg 32a5222 AR ‘s-HertogenboschThe Netherlands

safety manual safety manager rel 101

Documents