MOST Safety Manual V1.3

8/12/2019 MOST Safety Manual V1.3

1/48

Measurement Technology Ltd.Power Court, Luton, BedfordshireENGLAND LU1 3JJ

COPYRIGHT 2005 by Measurement Technology, Ltd. All rights reserved.

No part of this publication may be copied or distributed, transmitted, transcribed, stored in a retrievalsystem or translated into any human or computer language in any form or by any means, electronic,mechanical, magnetic, manual or otherwise, or disclosed to third parties without the express writtenpermission of:Measurement Technology, Ltd., Power Court, Luton, Bedfordshire, England LU1 3JJ

Safety Manual

For the

MOST SafetyNet System

Issue 1.328 July 2005

Author

Dil Wetherill


2/48


3/48

Safety Manual for the MOST SafetyNet System___________________________________________________________________________________

______________________________________________________________________________________

Measurement Technology Ltd. Issue: 1.3

CONFIDENTIAL 28 July 2005 Page 3 of 48

Table of Contents

1 INTRODUCTION.......................................................................................................................5

1.1 Scope .......................................................................................................................... 61.2 Document Structure .................................................................................................... 6

2 PRODUCT OVERVIEW ............................................................................................................7

2.1 MOST.......................................................................................................................... 72.2 MOST SafetyNet System............................................................................................ 82.3 MOST SafetyNet System Normal and Safe States..................................................... 8

2.3.1 MOST SafetyNet System Component Overview................................................. 92.4 MOST SafetyNet Controllers..................................................................................... 10

2.4.1 Controlled Shutdown by SafetyNet Controllers ................................................. 102.4.2 SafetyNet Controller Diagnostic Checks............................................................ 112.4.3 Redundant SafetyNet Controllers...................................................................... 11

2.5 SafetyNet IO Modules............................................................................................... 122.5.1 Configuration...................................................................................................... 122.5.2 LED Indication.................................................................................................... 122.5.3 Module States.................................................................................................... 12

2.5.3.1 Power Up........................................................................................................ 142.5.3.2 Cold Start ....................................................................................................... 142.5.3.3 Halt State........................................................................................................ 142.5.3.4 Running State................................................................................................. 142.5.3.5 Failsafe State ................................................................................................. 152.5.3.6 Controlled Shutdown...................................................................................... 152.5.3.7 Fault State ...................................................................................................... 15

2.5.4 SafetyNet IO Module Diagnostics...................................................................... 16

2.5.5 Downloading new IO Module Firmware............................................................. 162.5.6 SafetyNet Analogue Input Module..................................................................... 162.5.6.1 HART Data ..................................................................................................... 172.5.6.2 Configuration .................................................................................................. 172.5.6.3 Alarms ............................................................................................................ 182.5.6.4 Analogue Input Diagnostics ........................................................................... 19

2.5.7 SafetyNet Digital Input/Output Module .............................................................. 202.5.8 SafetyNet Input Channel Configuration ............................................................. 21

2.5.8.1 SafetyNet Input Channel Diagnostics ............................................................ 212.5.8.2 SafetyNet Input Line Fault Detection ............................................................. 221.1.1.3 SafetyNet Output Channel Single Pulsed Mode Configuration .................. 231.1.1.4 SafetyNet Output Channel Continuous Pulsed Mode Configuration .......... 231.1.1.5 SafetyNet Output Channel Discrete Mode Configuration ........................... 241.1.1.6 Output Switch Health Testing......................................................................... 251.1.1.7 SafetyNet Output Channel Line Fault Detection............................................ 26

1.6 Power Supplies ......................................................................................................... 281.7 Workbench................................................................................................................ 29

1.7.1 Safe Mode.......................................................................................................... 301.7.2 Configuration Mode............................................................................................ 301.7.3 Safe and Non-interfering Data ........................................................................... 301.7.4 Peer-to-Peer Communication with other Controllers......................................... 311.7.5 Communication with Remote Modbus Devices ................................................. 311.7.6 Workbench Password Protection....................................................................... 311.7.7 Security Levels................................................................................................... 321.7.8 SafetyNet Controller Password.......................................................................... 32

1.7.9 Key Switch Protection........................................................................................ 33


4/48


______________________________________________________________________________________



1.7.10 Trusted Hosts..................................................................................................... 341.7.11 IO Configurator .................................................................................................. 341.7.12 Network Configurator ......................................................................................... 351.7.13 SafetyNet Logic Static Analysis Tool................................................................. 351.7.14 SafetyNet Logic Differences Utility .................................................................... 351.7.15 Version Management Control ............................................................................ 351.7.16 SafetyNet Controller Change Control Log ......................................................... 36

3 SUITABLE APPLICATIONS...................................................................................................37

3.1 General Application Requirements ........................................................................... 373.1.1 Operator Interface.............................................................................................. 373.1.2 Programming Interface ...................................................................................... 383.1.3 Hardware Fault Tolerance, Safe Failure Fraction and Type.............................. 383.1.4 Calculating PFD for Low Demand Applications................................................. 391.1.5 Calculating PFH for High Demand Applications ................................................ 401.1.6 Calculating Response Time............................................................................... 41

1.1.7 Diagnostic Test Interval and Fault Reaction Time............................................. 411.1.8 Applicable Standards......................................................................................... 42

4 PROOF TESTING...................................................................................................................43

APPENDIX A GLOSSARY OF TERMS AND ABBREVIATIONS FOR IEC61508....................44

APPENDIX B SUMMARY OF SAFETY RELATED DATA.........................................................48

List of Figures

Figure 1 Basic Components of a MOST System..............................................................................7Figure 2 MOST SafetyNet System Component Overview ...............................................................9Figure 3 SafetyNet IO Module States and Transitions...................................................................13Figure 4 The operation of alarms for the SafetyNet Analogue Input Module.................................18Figure 5 Resistor Values for Line Fault Detection..........................................................................22Figure 6 Typical Low Demand Application .....................................................................................39Figure 7 Typical High Demand Application ....................................................................................40

List o f Tables

Table 1 Measured and Resistor Values for Line Fault Detection with SafetyNetDigital Input channels ...................................................................................................22

Table 2 Measured and Resistor Values for Line Fault Detection with normally de-energised SafetyNet Digital Output channels with reverse test current..................26

Table 3 Measured and Resistor Values for Line Fault Detection with normally de-energised SafetyNet Digital Output channels with forward test current..................27

In the text, any wording which is in boldhas specific meaning within IEC 61508. Furtherexplanations and definitions of these terms can be found in Annex A of this Safety Manual orin IEC 61508 - 4: Definitions and abbreviations.


5/48


______________________________________________________________________________________



1 Introduction

This Safety Manual describes the actions that must be taken to use the MOST SafetyNetSystem in safety-relatedapplications.

The actions that are described can be either technical or procedural. For example, aprocedural action would be the need to maintain password protection of configurationprogrammes, so that non-approved staff cannot modify these.

This document is limited to those actions that are required to ensure compliance with therelevant safety certifications and standards. Other documents in particular the MTLApplication Note AN9025 An Introduction to Functional Safety, IEC 61508 and IEC 61511,but also the relevant Instruction Manuals and Datasheets must be referred to for informationoutside the scope of this document. These documents may be found on the MTL MOST

website www.mtlmost.com.

The Safety Manual is approved and certified by TV as part of the overall SafetyNet System.Satisfying the requirements it describes is a necessary part of using the SafetyNet System insafety-relatedapplications.

Failure to complete the actions described in this document would contravene the certificationrequirements.

Completing the actions described in this document will only satisfy some of the requirementsdefined by IEC 61508 for safety-relatedapplications. It will be necessary to satisfy the fullrequirements of IEC 61508 and for Process Industry applications - the requirements ofIEC61511, in order to use the MOST SafetyNet System in safety-relatedapplications.


6/48


______________________________________________________________________________________



1.1 Scope

The MOST SafetyNet System is intended for use as part of a programmable electronicsystemas defined by IEC61508. It is suitable for safety functionsup to safety integritylevel 2(SIL2).

The SafetyNet System employs a 1oo1D (i.e. 1 out of 1 with diagnostics) architecture toachieve SIL2. SafetyNet Controllers may be used in redundant mode to increase systemavailability, but this is neither required by, nor relevant to, the safety-relatedperformance ofthe system.

Configuring and programming the SafetyNet System must be via an MTL software programknown as the Workbench.

In addition to completing the actions specifically related to the SafetyNet System, it isnecessary to satisfy the wider requirements of IEC61508. This includes such elements withinthe framework of the safety lifecycle, such as hazard and risk analysis and defining thesafety requirements specification. This work must be carried out through appropriate andcompetent Safety Management procedures and staff.

1.2 Document Structure

This Safety Manual describes the actions that must be taken to use the MOST SafetyNetSystem in safety-relatedapplications. The main sections are as follows:

Section 1 Introduction

Section 2 Product Overview, gives an overview of the MOST product range in general andthe MOST SafetyNet products in particular.

Section 3 Suitable Applications, describes the use of the MOST SafetyNet System inpractical applications.

Section 4 Proof Testing, describes the proof testing that is necessary.

A glossary of terms and abbreviations used within this Safety Manual is given in Appendix A.

A summary of the essential data for safety applications for the MOST SafetyNet System is

given in Appendix B.


7/48


______________________________________________________________________________________



2 Product Overview

2.1 MOST

The MOST Process Control System (on which the MOST SafetyNet System is based) wasoriginally developed to meet the requirements of modern process control. The systemcomprises:

IO modules, in both General Purpose and Intrinsically Safe format. Field terminals to which field wiring is terminated, incorporating fusing and loop

disconnect. Controllers which can be programmed to carry out the control of the process. Carriers on which the other components can be mounted. Power supplies and other miscellaneous hardware. Workbench software which is used to configure the system and to generate the control

programmes which will be run by the Controllers. Communication between IO Modules and Controllers on a given node is via an internal

and proprietary protocol called Railbus.

Figure 1 Basic Components of a MOST System

Controller

IO Module

FieldTerminal

Carriers


8/48


9/48


______________________________________________________________________________________



2.3.1 MOST SafetyNet System Component Overview

The figure below gives an overview of the role each element of the MOST SafeyNet Systemhas in implementing the safety function.

Figure 2 MOST SafetyNet System Component Overview

SafetyNet Controller runsthe safety application programand carries out diagnosticchecks to ensure it isoperating correctly. If a fault isdetected it will shut itselfdown.

SafetyNet Module configuredfor digital inputs. Monitors theinputs and also checks for linefaults. Internal diagnostics

check the module is operatingcorrectly.

SafetyNet AI Module monitors theinputs and carries out internaldiagnostics to check the module isoperating correctly.

SafetyNet Module configured fordigital outputs. Obeys commands toset outputs sent by the Controller.Internal diagnostics check that themodule is working correctly. If a faultis detected, will set outputs to theirsafe state of de- energised.


10/48


______________________________________________________________________________________



2.4 MOST SafetyNet Controllers

The 8851-LC-MT SafetyNet Controller shares the same hardware platform as a standardMOST Controller. Safety compliance is assured by constraining the Controller so that it canonly perform appropriate operations and adding additional diagnostic software that detectsfailures and takes appropriate action should errors be detected.

If the SafetyNet Controller detects a dangerous fault (i.e. one that would prevent theSafetyNet System from carrying out its safety function) then it will initiate a controlledshutdown. A controlled shutdown has two objectives firstly, to ensure that the SafetyNetSystem enters its failsafe mode; and secondly, to record sufficient data to allow the reason forthe shutdown to be determined.

2.4.1 Controlled Shutdown by SafetyNet Controllers

A controlled shutdown involves the following steps:

All SafetyNet Controller activity that could affect IO Modules is suspended. This leads tothe IO Modules entering failsafe mode (loss of communication with the module trips thefailsafe timer).

The current System State is saved for subsequent analysis. An event journal and areason for failure message is also saved. This contains details of the fault that triggeredthe shutdown and time stamp data.

The Controller main processor is reset. This is done to ensure that whenever possible the SafetyNet Controller returns to a state from which fault diagnosis can be carried out.

Following the processor reset, the configuration, program and warm start data is CRCchecked and re-loaded. The SafetyNet Controller then enters its Failed State. Communication with IO Modules

is still suspended, as is running of control strategies. Communication over the LAN islimited to certain commands, such as reading the reason for failure message.

A SafetyNet Controller in Failed State illuminates both red FAULT and FAILSAFE LEDs.

Uncontrolled shutdown is defined for the MOST SafetyNet System as a shutdown in which itis not possible to record the event journal and the reason for failure message. Uncontrolledshutdown will occur in such cases as a hardware fault or hardware watchdog triggering areset of the processor.

Should the power supply to the SafetyNet Controller fail and then be reinstated, the SafetyNet

Controller will enter cold start mode. Cold start re-initialises all data, including IO Moduledata. (The warm start mode available in the standard Controller is disabled in this case, as awarm start in a state which is not pre-defined is unsuitable for a safety-related application).

The SafetyNet Controller cold start mode has two configurable options Offline, in whichmanual intervention is required to bring the SafetyNet Controller online, and Automaticwhereby the SafetyNet Controller will automatically come online once the power is restored.


11/48


______________________________________________________________________________________



2.4.2 SafetyNet Controller Diagnost ic Checks

The SafetyNet Controller automatically carries out a number of diagnostic checks on acontinuous basis. All checks are monitored and completed at least once every 5 seconds (i.e.the test is confirmed as being done at least once every 5 seconds). This period is called thediagnostic test interval.

The certifying authority that has granted the MOST SafetyNet System approval for use inSIL2 safety-related applicationshas confirmed the completeness of the diagnostic tests.No further testing of SafetyNet Controllers is required beyond the Proof Testsspecified inSection 4.

2.4.3 Redundant SafetyNet Contro llers

When a second Controller is added to introduce redundancy to a MOST node, the newController will only operate as a standby when it confirms that it has the identically the samefirmware and control strategy as the master. If they are not identical, the new Controller willnot start up.

When used in redundant mode, MOST Controllers perform the same processing on the samedata at the same time. A number of rendezvous points are defined in each cycle at whichthe master and slave must arrive within a defined time period and cross check one anothersdata. Only the master writes outputs to the Railbus, but the standby Controller checks that itwould have written the same data had it been master. (The exception to this is when themaster allows the standby to write the agreed output to confirm that the standby is capable of

writing successfully).

A standby Controller will take over from a master if the master fails to arrive at a rendezvouspoint, or if the masters self-diagnosis detects a fault. A standby Controller will report to themaster that it is unable to act as a redundant back-up if it self-diagnoses a fault.

Using MOST SafetyNet Controllers in redundant mode will increase their availability, but willhave no effect on their ability to perform a safety-relatedfunction they would still becertified for use as part of a SIL2system.

When used in Redundant Mode, SafetyNet Controllers cross-check that one Controller is themaster and the other is the standby (i.e. anything other than one Controller as master andone as standby is reported as an error). If an error is detected, controlled shutdown is

triggered.


12/48


______________________________________________________________________________________



2.5 SafetyNet IO Modules

SafetyNet IO Modules share many of the same attributes as standard MOST IO Modules.They have the same physical form and are connected to the Module Carriers and FieldTerminals in the same manner as standard modules.

They differ from the standard modules in that they perform additional software diagnosticchecks and have hardware specifically designed for safety-relatedapplications.

2.5.1 Configuration

SafetyNet IO Modules are configured via the IO Configurator within the Workbench.

2.5.2 LED Indication

Each MOST IO Module features a green LED marked Pwr, a red LED marked Fault and typically - a yellow LED for each IO channel marked with the appropriate channel number.

LEDs may be on, off, flashing or blinking. An LED is flashing is when it is turned on and offwith an equal mark-space ratio. An LED is blinking is when it repeatedly alternates betweenbeing on for a short period and then on for a longer period (this is continuous transmission ofthe letter a in morse code: .-).

The indication provided by the LEDs is described in Section 2.5.3 and its Sub-sections.

2.5.3 Module States

SafetyNet IO Modules can be in one of four states:

Running State the IO module is working normally and reading inputs or writing outputsas required. The module carries out diagnostic tests to ensure that it continues to operatecorrectly and that it is capable of carrying out the required safety function. All validRailbus commands are accepted.

Failsafe State the IO module has been running normally but has either been instructedto enter Failsafe State by the Controller, or the module itself has detected that theFailsafe Timeout has expired. If the module enters the Failsafe State, it will remain thereuntil (and if) the Controller instructs it to return to the Running State.

Fault State the IO module has been through a Controlled Shutdown, either because awatchdog timer has expired or because a module hardware fault has been detected.

Halt State the IO module has failed its initial training via the Railbus. The IO module isinactive it does not read or write to the Railbus, and it does not read or write to the IOchannels, once they have been set to their default configuration (which is all channelsinactive, all Input/ Output channels set to 'Input').


13/48


______________________________________________________________________________________



The diagram below shows the transitions between the various IO Module States:

Figure 3 SafetyNet IO Module States and Transitions

The individual steps and states shown in the above diagram are explained in more detail inthe following sections.

Power Up

Controlled Shutdown

Fail

Cold Start

Pass

Fault

Halt

Running

Failsafe

Pass

Reset Command

Exit failsafecommand

Failed InternalDiagnostics Enter Failsafe

Command orFailsafeTimeout

Reset Command

No addresslearnt

Reset Command

Failed InternalDiagnostics

Fail


14/48


______________________________________________________________________________________



2.5.3.1 Power Up

De-powering and re-powering a SafetyNet IO Module will cause it to enter the 'Power-Up' andsubsequent processes, irrespective of what state the module had been in prior to the removalof the power. (These transitions are not shown on the above diagram for simplicity). All datastored within the module IO data, diagnostic, status and any event logs not yet transmittedto the Controller will be lost in doing this.

If a SafetyNet IO Module fails Power Up, it will enter the Fault State, if it passes it will carryout a Cold Start.

2.5.3.2 Cold Start

The SafetyNet IO Module carries out a number of tests and learns its address. If the modulepasses the tests and learns its address, it will move on to the Running State. If it fails any ofthe tests it will move to a Controlled Shutdown. If it fails to learn its address it will enter theHalt State. During the Cold Start the red Fault LED will flash.

2.5.3.3 Halt State

This state is entered if the module has failed to learn its address during a Cold Start. In thisstate:

The Red Fault LED blinks.

The module is inactive, all Railbus commands are ignored, inputs are not scanned,outputs are de-energised and diagnostic tests are suspended.

The module can only exit the Halt State by going through a power cycle (as the module hasfailed to learn its address, it cannot be addressed).

2.5.3.4 Running State

This state is the normal operating state for the module. In this state:

Input channels are scanned and output channels are written to.

Railbus is fully active, accepting all valid commands. Background diagnostics are running and if a failure is detected, then the module will enter

Controlled Shutdown. The yellow LEDs indicate the channel status.


15/48


______________________________________________________________________________________



2.5.3.5 Failsafe State

This module state will be entered from the Running State either due to loss ofcommunications with the Controller or because the module has received an instruction fromthe Controller to enter the Failsafe State. In this state:

The Red Fault LED is lit. The Failsafe flag is set in the Device Status Register. All Railbus Write requests are rejected, except instructions to Reset or to exit the Failsafe

State. Scanning of inputs and HART data is performed. Outputs are de-energised. Background diagnostics are running and if a failure is detected, then the module will enter

Controlled Shutdown.

2.5.3.6 Controlled Shutdown

A Controlled Shutdown has two objectives to bring the IO Module back to a state fromwhich it can be re-started and to try and store the reason for failure. Controlled shutdowninvolves the following steps:

The IO Module is re-initialised. The Event Log and the Diagnostic Status Register record the reason for the failure. The Railbus is enabled allowing the module training sequence to begin. Module training is completed to allow the Controller to address the module.

Following a Controlled Shutdown the IO Module will enter the Fault State.

2.5.3.7 Fault State

The module will enter the Fault State after a Controlled Shutdown. In this state:

The red Fault LED blinks. All Railbus Write requests are rejected (including the instruction to exit Failsafe State),

except for instructions to Reset or to receive new firmware. All channels are set to inactive (no scanning of inputs is performed, outputs are de-

energised) Fault State is indicated in the Diagnostic Status Register.

The module can only exit the Fault State by a power cycle or by receiving a Reset command(or firmware download see Section 2.5.5). The module will enter a cold start when re-starting from the Fault State.


16/48


______________________________________________________________________________________



2.5.4 SafetyNet IO Module Diagnostics

The SafetyNet IO Modules automatically carry out a number of diagnostic checks on acontinuous basis. All checks are monitored and completed at least once every 5 seconds (i.e.the test is confirmed as being done as well as being passed at least once every 5 seconds).This period is called the diagnostic test interval.

The certifying authority that has granted the MOST SafetyNet System approval for use inSIL2 safety-relatedapplications has confirmed the completeness of the diagnostic tests. Nofurther testing of SafetyNet IO Modules is required to comply with the certification, beyond theproof tests that are specified in Section 4.

2.5.5 Downloading new IO Module Firmware

New IO Module Firmware can be downloaded via the IO Configurator. A right mouse click onan IO Module icon will present options including Reprogram which can be used todownload new firmware to an IO Module in Running, Failsafe, or Fault state to cause it toenter a Cold Start.

It is extremely unlikely that a download of new module firmware would be used with the safetysystem carrying out its safety function. This is allowed within the SafetyNet system (whenthe system is in Configuration Mode) but may not be allowed by the local requirements to testchanges to the operation of the safety function before it is approved for use.

When such an on-line download is required and permitted, a new safety application

programme can be downloaded to a SafetyNet Controller without affecting the existingapplication. The new application will be written to the Safety Controller over a number ofcycles, such that the response timeof the SafetyNet System is not materially worsened bythis operation. Once the new application is installed and has passed verification testing bythe Controller, then new application will be acted upon.

2.5.6 SafetyNet Analogue Input Module

The 8810-HI-TX SafetyNet Analogue Input Module is an 8 channel module for use with 2-, 3-or 4-wire transmitters which may or may not be HART devices. The inputs are suitable foruse in SIL2 applications, using a 1oo1D architecture to meet the requirements for use in asafety-related system.

Apart from the diagnostic checks that are carried out in order to meet the safety requirements,the module is otherwise identical in operation to a standard Analogue Input Module withHART.

Detailed information regarding the use of the SafetyNet Analogue Input Module is given in theappropriate data sheets and user documentation. The information given here only relates tothe safety-relatedaspects of the module.


17/48


18/48


______________________________________________________________________________________



2.5.6.3 Alarms

If the unfiltered input value exceeds an alarm point, then the appropriate alarm flag is set.When the unfiltered value falls back below the alarm point by the configured dead band, thealarm flag is removed. Setting the low alarms to 0mA and the high alarms to 25mA willdisable them. A configurable dead band can be set to prevent alarms being cleared byprocess noise.

If the high-high and low-low alarms are set to be above 21.0mA for high-high alarms andbelow 3.6mA for low-low, then these alarms will operate as specified by NAMUR NE43. Thedead band will be ignored and alarms will only be set if the unfiltered input value exceeds thealarm value for more than 4 seconds. The alarms are cleared when the unfiltered input valuefalls below the alarm point.

Figure 7 shows the operation of alarms with the unfiltered input value.

Deadband

Hi Hi NAMUR Alarm Set (4 sec. delay)

Hi Hi Alarm SetHi Hi NAMUR Alarm Cleared

Hi Alarm Set Hi Alarm Cleared

Low Alarm Set

Low Low NAMUR Alarm Set (4 sec. delay)

Low Low Alarm Set

Low Alarm Cleared

Low Low Alarm Cleared

Hi Hi Alarm Limit

Hi Alarm Limit

Low Alarm Limit

Low Low Alarm Limit

Deadband

25mA / 6.25vDC

0 mA / 0 vDC

Monitored Input Channel

Deadband

Hi Hi Alarm Cleared

Deadband

Low Low NAMUR Alarm Cleared

Figure 4 The operation of alarms for the SafetyNet Analogue Input Module


19/48


______________________________________________________________________________________



2.5.6.4 Analogue Input Diagnostics

The SafetyNet Analogue Input Module carries out a diagnostic check to confirm the accuracyof the analogue input measurement.

In addition to the primary measurement of the input value, a second diagnostic measurementis made using different internal circuitry. The accuracy of the primary measurement isconfirmed by comparing it with the value measured by the diagnostic measurement. Theprimary measurement is reported as faulty if it differs from the diagnostic measurement valueby more than 2%.

The primary measurement circuitry is routinely switched to measure a number of knowninternal references. The channel is reported as faulty if it reports a value that differs from theknown value by more than 2%.

If a channel fails either test, it will be flagged as faulty and made inactive. It can be madeactive by a Reset Command or by cycling its power supply. (Note the module and its otherchannels will carry on operating normally).


20/48


______________________________________________________________________________________



2.5.7 SafetyNet Digital Input /Output Module

The 8811-IO-DC SafetyNet Digital IO Module is an 8-channel module, with each channelconfigurable as either an input, a pulsed output (single or continuous) or as a discrete output.Channels can be further configured to provide a number of modes of operation and faultdetection appropriate to the input device or load connected to that channel.

When configured as an input, the channel is suitable for use in SIL2 safety functions, with a1oo1D architecture.

When configured as an output, the channel suitable for use in SIL2 safety functions. Theoutput employs two switches, arranged in series with the load. This provides a level ofredundancy (a single switch failure does not prevent the output from de-energising the load).However, the channel is still treated as 1oo1D when carrying out the assessment of the

suitability of the channel for a particular safety integrity.The SafetyNet Digital IO Module can be in one of four states Running, Failsafe, Fault, orHalt. See Section 2.5.3 2.5.1.

Detailed information regarding the use of the SafetyNet Digital IO Module is given in theappropriate data sheets and user documentation. The information given here only refers tothe safety-relatedaspects of the module.


21/48


______________________________________________________________________________________



2.5.8 SafetyNet Input Channel Configuration

A SafetyNet Digital Input channel can be configured as a discrete input, a pulse counter or asa latching input.

A change in the input state occurs if the states observed at the start and end of the filter timeinterval are the same. If they are different, the previous state is maintained.

The filter time interval can be configured between 0 and 8 seconds, in 1ms intervals.

Inputs can be configured to latch a particular (filtered) input transition either transitionsfrom 0 to 1, or transitions 1 to 0. The latch is cleared by a reset signal from the SafetyNetapplication programme.

Inputs can be configured to count (filtered) input transitions. The counter wraps round from65 535 to 0 without warning. Input transitions are counted even if the channel is configured tolatch the input.

Inputs can be configured to be unsupervised (i.e. with no line fault detection enabled), withopen circuit line fault detection or open circuit line fault detection andshort circuit detection. Ifline fault detection is enabled, the line will be tested at least once every 5s.

Input channels can be configured to be Inactive. When in this state:

The channels input state is set to zero. All signal processing for the channel is discontinued, including line fault detection. The channel fault flag is set to healthy.

2.5.8.1 SafetyNet Input Channel Diagnostics

A number of internal diagnostic tests are carried out on individual channels. If any of the testsare failed, the channel is flagged as which are configured as inputs.

If a channel fails any of the tests, it will be flagged as faulty and made inactive. It can bemade active by a Reset Command or by cycling its power supply. (Note the module and itsother channels will carry on operating normally).


22/48


______________________________________________________________________________________



2.5.8.2 SafetyNet Input Line Fault Detection

Input channels can be configured for line fault detection either with open circuit detection oropen and short circuit detection.

For open circuit detection it is necessary to incorporate an end of line (parallel) resistance into the field wiring, close to the switch. For open and short circuit detection, it is alsonecessary to incorporate a series resistance in to the field wiring, close to the switch.The diagram below describes this and gives the values for the resistances.

Figure 5 Resistor Values for Line Fault Detection

The table below gives the measured values that are used for reporting open and circuit linefaults according to NFPA 72:

Input mode Unsupervised Open circuit detect Open & shortcircuit detect

NFPA 72 class Unsupervised Class B, style B Class B, style C

Open line(measured as)

- >45k >45k

Open contact(measured as)

>8k 8-14k


23/48


______________________________________________________________________________________



2.5.8.3 SafetyNet Output Channel Single Pulsed Mode Configuration

When configured as a single pulsed mode output, a channel is suitable for use - for example -with agent release solenoids that latch once they have been pulsed. The channel can only bepulsed ON.

Outputs can be configured to be unsupervised (i.e. with all fault detection disabled) or to testthe modules output switches and/or to detect line faults.

The option for detecting line faults can be further configured to test for open and/or shortcircuits, with the open circuit test by either a forward or reverse test current. The line faulttests are only performed when the channel is OFF.

If any of the fault detection functions are enabled, they will be tested at least once every 5s.

Output channels in single pulsed mode can be configured to be Inactive. When in this state:

The channel is de-energised. If the de-activation command is received while the output isON, it will be immediately de-energised.

The stored Output State (the value returned to the Controller) is set to zero and all signalprocessing for the channel is discontinued, including line fault detection.

The channel fault flag is set to healthy.

2.5.8.4 SafetyNet Output Channel Continuous Pulsed ModeConfiguration

When configured as a continuous pulsed mode output, a channel is suitable for use - forexample - with sounding alarms. As different ON-OFF patterns can be generated, the samealarm can be used to indicate different events.

Outputs can be configured to be unsupervised (i.e. with all fault detection disabled) or to testthe modules output switches or to detect line faults.


If any of the fault detection functions are enabled, they will be tested at least once every 5s.

Output channels in continuous pulsed mode can be configured to be Inactive. When in thisstate:

The channel is de-energised. If the de-activation command is received while the output isON, it will be immediately de-energised.

The stored Output State (the value returned to the Controller) is set to zero and all signalprocessing for the channel is discontinued, including line fault detection.

The channel fault flag is set to healthy.


24/48


______________________________________________________________________________________



2.5.8.5 SafetyNet Output Channel Discrete Mode Configuration

When configured as a discrete mode output, a channel is suitable for use - for example - witha solenoid valve.

The state of the hardware of an output channel is read back. The result obtained is known asthe read-back state and is used to set the stored state. If the read-back state is not the sameas the desired output state then the channel fault flag shall be set.

The output will go off or remain off when the channel is de-activated.

Outputs can be configured to be unsupervised (i.e. with all fault detection disabled) or to testthe modules output switches or to detect line faults.


The output is comprised of two switches arranged in series with the load, such that a singlepoint of failure is does not prevent an energised channel from being de-energised. SeeSection 2.5.8.6 for a more comprehensive discussion of the actions that must be taken in theevent of an output switch failure.


25/48


______________________________________________________________________________________



2.5.8.6 Output Switch Health Testing

When a channel is configured for switch health testing a test is performed that detects if eitherof the pair of switches is stuck open or closed.

If a single switch is stuck, the channel reports this and the application can determine theappropriate action to take. The correct action to take will depend on the nature of the faultand the requirements of the safety function. The table below shows what action must betaken in the event of various switch failure scenarios.

Output Normally

Switch failure mode Energised (both

switches normally

closed)

De-energised (both

switches normally

open)

1 switch stuck open De-energised to safestate by fault

Channel cannot beenergised

1 switch stuck closed Partfail - channel canstill be de-energised

Partfail - channel canstill be energised

Both stuck open De-energised to safestate by fault

Channel cannot beenergised

Both stuck closed Unsafe channelcannot be de-

energised

Output will be energised

The action that should be taken in each of the above scenarios will depend on the particularrequirements of the application. The Digital IO Module will report single or dual switch failuresand the SafetyNet Logic Application program must be written so as to take the appropriateaction both in terms of operating the safety function (or not) and informing the Operator ofthe status of the output channel.


26/48


______________________________________________________________________________________



2.5.8.7 SafetyNet Output Channel Line Fault Detection

Normally de-energised output channels can employ line fault detection open circuit and/orshort circuit detection can be configured. (For normally energised outputs open or shortcircuit line faults will de-energise the load, taking it in to the safe state).

For normally de-energised outputs, where the load incorporates a diode to allow for line faultdetection using a reverse test current, a 10kresistor needs to be wired in parallel with theload, as shown below:

The table below gives the measured values that are used for reporting open and short circuitline faults with reverse test currents:

Output mode Open circuit detect Short circuit detect


>45k -

Shorted line(measured as)

-


27/48


______________________________________________________________________________________



For normally de-energised loads that do not incorporate a diode to faciliate line faultdetection, the measured values that are used for reporting open and short circuit line faultscan be configured by the user, so that the resistance of the field wiring and the load itself canbe taken in to account.

The table below gives the measured values that are used for reporting open and short circuitline faults with forward test currents:

Output mode Open circuit detect Short circuit detect


>45k -

Shorted line(measured as)

- User configuredbetween 8and 1k

End of line resistor Not required -

Series resistor - Not required

Table 3 Measured and Resistor Values for Line Fault Detection with normally de-energisedSafetyNet Digital Output channels with forward test current

The reverse test current is never more than 1.5mA, the forward test current is never morethan 25mA. In the case of the forward test current, it must be confirmed that this current isnot sufficient to energise the load.


28/48


______________________________________________________________________________________



2.6 Power Supplies

The SafetyNet System is certified for use with MOST Power Supplies 8913-PS-AC to supplythe 12V System and Controller power and 8914-PS-AC to supply the 24Vdc Bussed FieldPower. Use of any other power supplies will invalidate the certification for use in safety-related applications.

For further information regarding the provision of power and arrangements for earthing,please refer to the Instruction Manual INM8900 MTL8000 Power Supplies.


29/48


______________________________________________________________________________________



2.7 Workbench

The MOST Workbench is an engineering tool for configuring parameters and writing controlprogrammes (known as Strategies) that will be downloaded to MOST Controllers. Dependingon the licences purchased, the Workbench can be used with both standard and/or SafetyNetSystems. The latter incorporates special features that are only used when working withSafetyNet Controllers.

This Section describes the features of the Workbench applicable to the SafetyNet System more general information regarding the operation and use of the Workbench can be found inthe Workbench training manual.

A summary of Workbench modifications specific to its use with SafetyNet Systems is givenbelow:

Two modes of operation are defined for the SafetyNet System: Configuration Mode, inwhich configuration parameters and control strategies can be modified in the Workbenchand downloaded to the SafetyNet Controller; and Safe Mode in which the SafetyNetController is running its control strategy and will not accept modifications.

SafetyNet Controllers can retrieve peer-to-peer data from other SafetyNet Controllers orfrom standard Controllers, but only data that is safe can be used in the SafetyNet Logicapplication.

Only safe data can be used in the SafetyNet Logic application the user is preventedfrom using non-interfering data.

Password protection of security access is enhanced to control which personnel areallowed to perform operations related to the safety.

A Key Switch facility is provided that can be used to further restrict access to safety

aspects of each SafetyNet Controller. A Trusted Host Table is provided that defines which hosts i.e. Ethernet LAN drivers -

can write to each SafetyNet Controller. A Static Analysis Tool is included in to the SafetyNet Logic programming environment to

capture unsafe or suspect conditions. Version management controls are enhanced to ensure compatibility between versions of

the Workbench and the SafetyNet Controller firmware and hardware. Change control logging and event recording are enhanced within the Workbench and

SafetyNet Controllers.

More detailed descriptions of these features are provided in the following sections.


30/48


______________________________________________________________________________________



2.7.1 Safe Mode

Safe Mode is the state in which the MOST SafetyNet System is acting as a safetyrelatedsystemand carrying out its safety function. When the system is in this state, it is notpossible to make modifications to configuration parameters or control strategies.

2.7.2 Configuration Mode

Configuration Mode is the same as Safe Mode, except that changes can be made to theconfiguration parameters and the control programmes of the SafetyNet Controller.

Instructing the MOST SafetyNet System to leave Safe Mode and enter Configuration Mode in which, although thesafety functionis being carried out, it is possible to make

modifications to configuration parameters or control strategies.

Configuration Mode can only be entered when the following conditions are met:

The user is designated as having Safety Responsibility and enters an appropriatepassword.

The Key Switch, if one is present, is set to Unlocked. The particular instance of the Workbench from which the instructions are being sent is

identified in the Trusted Hosts Table.

If this particular Workbench is one of those in the Trusted Hosts Table, then a commandbutton to move between Safe and Configuration Mode is presented to the user. The current

status is displayed and the button is used to switch to the other mode.

2.7.3 Safe and Non-interfering Data

A SafetyNet application program can only read data from other SafetyNet applicationprogrammes, SafetyNet Controllers or SafetyNet IO Modules. This data is known as SafeData within the SafetyNet documenation. No other data can be read by the SafetyNetapplication.

In some instances, the SafetyNet Controllercan read data that is not sourced from theSafetyNet application programmes, Controllers or IO Modules but this does not affect the

SafetyNet application programme. This data is known as non-interfering within theSafetyNet documentation. The ability of the SafetyNet Controller to read and subsequentlywrite non-interfering data is the route by which standard IO Modules and remote Modbusdevices mounted on a SafetyNet node, can communicate and be controlled by standardapplication programmes.

The SafetyNet Logic Application can write data to any location (standard or SafetyNet IOModules, standard or SafetyNet Controllers, remote Modbus devices, HMI or other networkedhosts).


31/48


______________________________________________________________________________________



2.7.4 Peer-to-Peer Communication with other Controllers

SafetyNet Controllers can retrieve peer-to-peer safe data from other SafetyNet Controllersand non-interfering data from from standard Controllers.

2.7.5 Communication with Remote Modbus Devices

SafetyNet Controllers can write data to Remote Modbus devices that may or may not formpart of the safety function, but any data read from such devices is non-interfering.

2.7.6 Workbench Password Protection

Access to the Workbench software program is restricted by password protection. Passwordsmust be a minimum of 6 characters and can be changed at any time by the user.

The Workbench does not provide an automatic log-out facility, so this must be implementedvia the password protection options for the screen saver. If the screen saver protection istriggered (because neither the keyboard nor the mouse has been used within a specifiedperiod of time) then the user must use the screen saver password to re-enter the system. Nodata is lost when the system is locked and unlocked in this way and the system returns to theexactly the condition it was in when the system first became locked.


32/48


______________________________________________________________________________________



2.7.7 Securi ty Levels

A number of Security Levels are defined within the Workbench, which restrict access tocertain features:

Level 0 Disabled. No access to the Workbench. Level 1 Strategy Viewer. Access limited to running Strategy Viewer. Cannot tune or

change the strategy and cannot view any other data. Level 2 - Workbench Viewer. Has the access given to Level 1 - Strategy Viewer, plus the

ability to view (as read-only) all data within the Workbench. Can view drawings in theStrategy Builder, but cannot change them.

Level 3 - Workbench Editor. Has the access given to Level 2 - Workbench Viewer, plusthe ability to edit data within the Workbench. Can create new data points, but cannotcreate or delete projects, controllers, or drawings. Can edit drawings within Strategy

Builder and change tuning constants. Level 4 - Create/Delete. Has the access given to Level 3 - Workbench Editor, plus theability to create or delete projects, controllers, or drawings.

Level 5 Administrator. Full access to all Workbench features. Can run administrativetools and utilities and can reset passwords for all lower levels.

Users from level 3 and higher can optionally be given Safety Responsibility - this will allowthem the access defined above for both standard and SafetyNet Controllers. When users atlevel 3 and level 4 do not have Safety Responsibility they have the access to SafetyNetControllers defined by level 2 i.e. they can view strategies and data, but cannot changethem. Users with Safety Responsibility can switch SafetyNet Controllers between Safe andConfiguration Modes. Users with levels lower security levels or those without SafetyResponsibility can only access the SafetyNet Controllers when they are in Safe Mode.

2.7.8 SafetyNet Controller Password

When a new Controller is added to the Workbench, it may be added as a SafetyNet Controlleror a standard Controller. During the IO configuration of a SafetyNet Controller, the user willbe given the option to enter a Controller password (this option is not presented for standardControllers). It is recommended that SafetyNet Controller Passwords are used, but it is not arequirement.

If the password is lost it cannot be recovered (even by a user with Level 5 Administratoraccess). The SafetyNet Controller must be reset to clear its memories and re-programmed if

the password is lost. This is done via the Network Configurator. With the NetworkConfigurator running, the SafetyNet Controller must be de-powered and then re-poweredwhile the Controller button on the Controller Carrier is depressed. The button must be helddown until the 2 red LEDs and the single yellow LED flash in unison. When this is done theNetwork Configurator will prompt the user to Clean the SafetyNet Controller. This will setthe SafetyNet Controller to its default values - which includes no password and clearing allcontrol strategies and IO configuration parameters. If required a new password can then beset.

SafetyNet Controller Passwords must be between 6 and 15 characters in length. Thepassword can be changed via the IO Configurator.


33/48


______________________________________________________________________________________



2.7.9 Key Switch Protection

When a SafetyNet Controller is added to the Workbench, the user is given the option ofselecting a tag to use as a Key Switch. This can be used for example to provide themeans by which an Operator can lock the SafetyNet System in Safe Mode, so that they takingthe system out of this mode can only be done with their awareness and permission.

The Key Switch is assigned from a pull-down list launched by a right mouse click on aSafetyNet Controller icon, where all digital input tags are presented as options for selection.When a particular tag is chosen, its channel health tag is automatically entered as the KeySwitch health tag. If the chosen tag does not have an identified health tag, then an additionaltag may be selected that will act in this way.

Only users with Safety Responsibility can enter, delete or edit the Key Switch value and its

associated health tag.If a Key Switch is assigned then it must be set to unlocked (and be healthy) when any of thefollowing operations are carried out (the SafetyNet Controller must also be in ConfigurationMode):

Switching between Safe and Configuration Modes. Downloading and editing IO Configuration parameters. Downloading and editing Control Strategies. Downloading and editing the Trusted Hosts Table. Configuring the Network


34/48


______________________________________________________________________________________



2.7.10 Trusted Hosts

A SafetyNet Controllers Trusted Hosts Table defines which entities on the LAN are allowed towrite to that SafetyNet Controller (any LAN entity can read from SafetyNet Controllers). Thisprevents access to the SafetyNet Controller from unknown or untrustworthy devices.

Trusted Hosts would typically be instances of the Workbench, Remote Modbus Devices andHMI stations. (Note: other Controllers are not included in the Trusted Host Table as they aresubject to a different system of authenticity checking).

Each entry in the Trusted Host table consists of the following:

MAC address of host (LAN A) MAC address of host (LAN B for FTE Nodes)

Modbus writes allowed or not Workbench writes allowed or not HART passthrough allowed or not Descriptive name (for use in event logs etc) optional

To allow Remote Modbus Devices to write data from to SafetyNet Controller, the serial portsCOM1 and COM2 can be added as Trusted Hosts.

A user can edit the Trusted Host Table when:

The user is designated as having Safety Responsibility The Key Switch, if one is present, is Unlocked The user enters the appropriate SafetyNet Controller password, if one is required

Note: The Trusted Host Table can be edited from any instance of the Workbench (even onethat is not listed in the Trusted Host Table) and while the SafetyNet Controller is in SafeMode. This is to allow for the situation where the PC running the only instance of theWorkbench has failed and a new instance needs to be introduced to bring the SafetyNetController out of Safe Mode and in to Configuration Mode.

Note: The Trusted Host Table is designed to prevent unauthorised local access to LAN towhich the SafetyNet Controllers are connected. The prevention of unauthorised remoteaccess must also be considered, and features such as network firewalls implemented toprevent such remote access.

2.7.11 IO Configurator

The IO Configurator should be launched from within the Workbench.

When the IO Configurator is launched, the user will already have entered their username andpassword and the system will already have identified their Security Level. If the user hasSafety Responsibility, then they will be able to write a new IO Configuration to a SafetyNetController, provided that:

The Key Switch, if one is present, is Unlocked The SafetyNet Controller is in Configuration Mode

The user enters the appropriate SafetyNet Controller password, if one is required


35/48


______________________________________________________________________________________



2.7.12 Network Configurator

The Network Configurator should be launched from within the Workbench.

When the Network Configurator is launched, the user will already have entered theirusername and password and the system will already have identified their Security Level. Ifthe user has Safety Responsibility, then they will be able to write a new NetworkConfiguration to a SafetyNet Controller, provided that:

The Key Switch, if one is present, is Unlocked The SafetyNet Controller is in Configuration Mode The user enters the appropriate SafetyNet Controller password, if one is required

2.7.13 SafetyNet Logic Static Analysis Tool

The Static Analysis Tool is used to detect errors in SafetyNet Logic Control Strategies beforethey are compiled prior to being downloaded to a SafetyNet Controller. If a strategy failsstatic analysis, then the user will be notified of the error and will not be able to download thestrategy to a SafetyNet Controller.

2.7.14 SafetyNet Logic Differences Utili ty

Once a strategy is successfully compiled, it can be downloaded to a SafetyNet Controller. Ondownload, two text reports are generated: a Download Report and a Master Tag Xref, which

can be used for comparison with earlier downloads using a differences utility within theWorkbench.

2.7.15 Version Management Control

To ensure that the user downloads compatible versions of the control strategy and the varioustables associated with that control strategy, it is only possible to download both the tables andthe control strategy.

Note: Tables refer to the data tables that define:

Register initialisation table Peer-to-peer mapping table Remote device mapping Event recording Register mapping


36/48


______________________________________________________________________________________



2.7.16 SafetyNet Controller Change Control Log

The Workbench maintains a Change Control Log that records change messages in a table inthe master database. For standard Controllers, this function can be turned off, but forSafetyNet Controllers it will always be on. The log can be viewed by executing aLogChangeReport command from the Workbench Report Generator.

A record is made in the Change Control Log when:

IO Modules are added, deleted, or moved Tags are added to, removed from, or moved within an IO Module IO Configuration parameters are saved Controller IP addresses or node numbers are entered or modified External node numbers are entered or modified

Serial communications parameters are entered or modified A successful download is made to a Controller A strategy is removed The Controller password is changed

Note that when a table (such as the Trusted Hosts Table) is saved, a record is kept in theChange Control Log that the save took place. The information that the table contained canonly be viewed via the Download Report and the Differences tool.

The Change Control Log will record the date, time, Host, application used as well as the detailof the change made.


37/48


______________________________________________________________________________________



3 Suitable Appl ications

The MOST SafetyNet System can be used to provide safety functionsup to Safety IntegrityLevel 2(SIL2). It can be used in both low demandand high demandapplications.

Typical low demand applications are:

Fire and Gas protection systems, which monitor for the presence of fire or a release ofgas

Emergency Shut-Down or Process Shut-Down systems that are used to monitor thecorrect operation of a process and its process control system and which will perform acontrolled shut-down if safety limits are exceeded or a dangerous situation is detected

In both cases, the process safety timewill normally be greater than the response timeof

the MOST SafetyNet System.

The use of the MOST SafetyNet System in general applications and Fire & Gas andEmergency Shutdown specifically, is discussed in more detail in the following Section.

For high demand applications, the MOST SafetyNet System is restricted in its use by thelength of the diagnostic test interval(5-seconds). This restricts its use to those applicationswhere the process safety timeis longer than the 5-second diagnostic test intervalplus thefault reaction time. The MOST SafetyNet System will have a response time typically in therange of 50 to 200 milliseconds, to which must be added the response time of the inputsensorsand the output final elementsto give the total fault reaction time. An example of ahigh demandapplication for which the MOST SafetyNet System is suitable is given inSection Error! Reference source not found..

3.1 General Appl ication Requirements

3.1.1 Operator Interface

The MOST SafetyNet System will normally be connected to Operator Interfaces made up of acombination of PC consoles, matrix panels, mimic panels and press switches.

These interfaces allow the operator to monitor the operation of the system and to over-ridethe automatic system in some instances (such as to prevent extinguishant release or to

manually initiate alarms).

The SafetyNet System will allow detected faults (from line fault monitoring, internal SafetyNetSystem diagnostics etc.) to be displayed or indicated via the chosen Operator Interfacesaccording to the application program.

The Operator Interface can have the capability of modifying safety-related parameters andprograms, but use of this capability must be restricted to authorised and qualified personnelby some restricted access system (e.g. password or key protection).


38/48


______________________________________________________________________________________



3.1.2 Programming Interface

Programming, downloading safety-relatedparameters and programs and switching betweenoperating states is carried out via an engineering workstation using the MOST Workbench.

Access to the Programming Interface shall only be permitted for authorised and suitablyqualified personnel. Access must be restricted by the use of passwords (and the options todo this are provided for within the MOST Workbench) and/or some other forms of restrictingaccess.

The Programming Interface may be used as the Operator Interface, but use of theProgramming Interface must be restricted to authorised and qualified personnel.

Programming may only be carried out while the safety system is not performing a safety

function.

3.1.3 Hardware Fault Tolerance, Safe Failure Fraction and Type

The MOST SafetyNet System has a hardware fault toleranceof 0 i.e. a single hardwarefault will render the system unable to carry out a safety function. (The output channels ofthe SafetyNet Digital Input Output Module have a hardware fault tolerance of 1, but this isthe exception within the MOST SafetyNet System).

The MOST SafetyNet System has a safe failure fractionof > 90%.

Since the MOST SafetyNet System is a Type Bsystem, with a hardware fault tolerance of 0and a safe failure fraction of >90%, it is suitable for with safety functions requiring a safetyintegrity level of 2.


39/48


______________________________________________________________________________________



3.1.4 Calculating PFD for Low Demand Appl ications

This Section gives a basic introduction to calculating the average probability of failure ondemand (PFDavg) for a safety function incorporating the MOST SafetyNet System.

For the purpose of this example, the following assumptions have been made:

All components are certified as suitable for use in SIL2 safety-relatedapplications All elements are used in 1oo1arrangements The Mean Time to Repair is not considered as any fault will trigger the safety function The approximation PFDavg = 1/2 Tp du is valid for the proof test interval considered

PFDavgfor a particular safety function is the sum of the probabilities of the average failure ondemand of each element of the system, taking in to account the proof test in tervalof each

element.

Figure 6 below includes a pressure transmitter for an input device, an 8810-HI-TX AnalogueInput Module, a SafetyNet Controller, an 8811-IO-DC Digital I/O Module configured as anoutput and a valve.

Figure 6 Typical Low Demand Application

PFDavgfor each element is calculated according to the equation above, where DUis theundetected dangerous failurerate per 109hours and Tpis the proof testinterval. (In this

example, Tpis 1 year (8760 hours) for all components of the safety function).

The value for PFDavg for each element is approximately half of the product of Tpand DU.

The value of PFDavgfor the system is the sum of PFDavgfor the individual elements.

PFDavg= 0.4 x 10-3+ 0.1 x 10-3+ 0.4 x 10-3 + 0.2 x 10-3 + 6.1 x 10-3 = 7.2 x 10-3

Using the table given in Section 2.3.5, this value would be (just) suitable for a SIL 2safetyfunction. Other conditions (hardware fault tolerance andsafe failure fraction) also allowits use in a SIL 2application.

See IEC 61508-6 and AN90035 for a more comprehensive guide to the calculation ofPFDavg.

PressureTransmitter

8810-HI-TXSafetyNet

AI

8851-LC-MTSafetyNetController

8811-IO-DCSafetyNet

DI/DO

Valve

DU= 100 (typ)Tp= 1 year

PFDavg= 0.4x10-3

DU= 16.9Tp= 1 year

PFDavg= 0.1x10-3

DU= 87.9Tp= 1 year

PFDavg= 0.4x10-3

DU= 49.1Tp= 1 year

PFDavg= 0.2x10-3

PFDavg = (1/2 * Tp * DU )

DUis failure rate per 109hours, Tpof 1 year = 8760 hours, PFDavgis the probability of dangerous failure

DU= 1400 (typ)Tp= 1 year

PFDavg= 6.1x10-3


40/48


______________________________________________________________________________________



3.1.5 Calculating PFH for High Demand Appl ications

As an example, taking SafetyNet System for which the final element is now an exhaust valve,and calculating probability of dangerous failures per hour (PFH).

For the purpose of this example, the following assumptions have been made:

All components are certified as suitable for use in SIL2 safety-relatedapplications All elements are used in 1oo1arrangements The Mean Time to Repair is not considered as any fault will trigger the safety function

Figure 7 Typical High Demand Application

Adding the individual PFH values (which are found by dividing the individual DUvalues by thenumber of hours in a year - 8760) gives:

PFH= 100 x 10-9+ 16.9 x 10-9+ 87.9 x 10-9 + 49.1 x 10-9 + 90 x 10-9 = 343.9 x 10-9

(Note that the proof test that makes a significant difference to the PFDavgof the valve is notconsidered here and the valves DUbecomes a very significant part of the overall PFH.)

Using the table given in Section 2.3.5, the PFHvalue of 343.9 x 10-9which is 3.4 x 10-7, which

is suitable for a SIL2safety function, as are the hardware fault toleranceand safe failurefractionof each element of the safety function.

See IEC 61508-6 for a comprehensive guide to the calculation of PFH.

PressureTransmitter

8810-HI-TXSafetyNet

AI

8851-LC-MTSafetyNetController

8811-IO-DCSafetyNet

DI/DO

ExhaustValve

DU= 100 (typ) DU= 16.9 DU= 90 (typ)

PFH= DU

DU= 87.9 DU= 49.1

DUfor all elements is failure rate per year, PFH is probability of failure per hour


41/48


42/48


______________________________________________________________________________________



3.1.8 Appl icable Standards

IEC 61508:2002. Functional Safety of Electrical/Electronic/Programmable ElectronicSafety-related Systems.

IEC 61511:2003. Functional Safety - Safety Instrumented Systems for the ProcessSector.

EN 54-2:1998. Fire Detection and Fire Alarm Systems Part 2: Control and indicatingequipment.

NFPA 72: 2002. National Fire Alarm Code. EN 50270:1999. Electromagnetic Compatibility - Electrical apparatus for the detection

and measurement of combustible gases, toxic gases or oxygen. EN 50130-4:1996. Electromagnetic compatibility- Product family standard: Immunity

requirements for components of fire, intruder and social alarm systems. IEC 61131-2: 2003. Programmable controllers, Equipment requirements and tests.

EN 61326: 1997. Electrical Equipment for Measurement, Control and Laboratory Use EMC requirements. EN 60079-13:2003. Electrical apparatus for explosive gas atmospheres Part 15: Type of

protection n. FM 3611: 2004. Non-incendive Electrical Equipment for use in Class I and II, Division 2,

and Class III Divisions 1 and 2, Hazardous (Classified) Locations. CSA C22.2 No 213-M1987, Reaffirmed 2004. Non-incendive Electrical Equipment for

Use in Class I, Division 2 Hazardous Locations. ISA-S71.04-1985. Environmental Conditions for Process Measurement and Control

Systems: Airborne Contaminants.


43/48


______________________________________________________________________________________



4 Proof Testing

The proof test interval for the MOST SafetyNet System will normally be between one andthree years, depending on the application. As a minimum, the tests should achieve thefollowing:

Proving that each safety function operates as required. Checking that digital outputs are neither stuck ON nor stuck OFF. Calibrating analogue input modules. Take the SafetyNet Controller and IO Modules through a power cycle i.e. turn the power

OFF and back ON (this ensures that the start-up procedures are tested).


44/48


______________________________________________________________________________________



Appendix A Glossary of terms and abbreviations forIEC61508

Note: where a definition of the term or abbreviation is given in IEC61508-4 Definitions andabbreviations, the definition from the standard is given first in quotation marks, followed byfurther explanation if this is necessary.

1oo1D a system which has no hardware fault toleranceand some level of diagnosticcoverage to detect faults.

1oo2D a system which has a hardware fault toleranceof 1 and some level of diagnosticcoverage to detect faults.

Average probabil ity of failure of protect ion on demand or PFDavgis the probability that

a safety system will be unable to carry out its required safety functionwhen a hazardoussituation arises and a demand in other words a request for the safety function to act occurs. This probability is used to determine the suitability of safety systems in low demandapplications. The value of PFDavgof a particular element within the safety system isdetermined by its intrinsic reliability, but also by the length of time between proof tests.

Average probabil ity of failure on demand (PFDavg) is the safety integrity failuremeasure for safety-relatedprotection systems operating in low demandmode

Continuous mode also known as high demand. A safety functionfor high demandorcontinuous modemay be required to carry out its safety functionmore often than once peryear. The alternative is a low demandapplication, in which the safety functionwould

normally be required to operate once per year, or less.

Control failures a number of techniques are specified in the standard to PFDavgduringthe operationof the E/E/PE safety-related system. These techniques, when combined withthe techniques specified for fault avoidancein all stages of the safety life cycle, play animportant part in ensuring that the E/E/PE safety-related systemattains its safety integritylevel.

Diagnostic test interval interval between on-line tests to detect faults in a safety-relatedsystemthat has a specified diagnostic test coverage. The diagnostic test intervalis animportant factor (when combined with the fault reaction time), in determining if a particularsafety-related system(with no tolerance to hardware faults) is suitable for use in a givenhigh demand/continuous modeapplication.

Electrical, electronic or programmable electronic system (E/E/PES) system for control,protection or monitoring based on one or more electrical/electronic programmable electronicdevices, including all elements of the system such as power supplies, sensors and other inputdevices, data highways and other communication paths, and actuators and other outputdevices.

Equipment under control(EUC) the equipment, plant and machinery that is the source ofthe risk.EUC control system system which responds to input signals from the process and/or froman operator and generates output signals causing the EUC to operate in the desired manner.

EUC risk risk arising from the EUCor its interaction with the EUC control system.


45/48


______________________________________________________________________________________



External risk reduction facility measure to reduce or mitigate the risks which areseparate and distinct from, and do not use, E/E/PE safety-related systemsor othertechnologies safety-related systems. Examples: A drain system, a fire wall and a bund areall external risk reduction facilities.

Fault avoidance use of techniques and procedures which aim to avoid the introduction offaults during any phase of the safety lifecycle of the safety-related system.

Fault reaction the time taken for safety functionto perform its specified action - to achieveor maintain a safe state. This should be considered along with the diagnostic test intervaland the process safety timefor systems that have a hardware fault toleranceof zero andwhich are operating in high demand mode.

Final elements the actuators (such as valves, solenoids, solenoid

MOST Safety Manual V1.3

Documents

Transcript of MOST Safety Manual V1.3