GA TMR-S Safety Manual - Certipedia · 2020. 8. 7. · Title GA TMR-S safety manual File GA TMR-S...

GEBHARDT Automation GmbH GA TMR/10-S

GA TMR SMART-S

safety systems

Safety Manual

Title GA TMR-S safety manual

File GA TMR-S safety manual Rev01.03 11102005.doc

Document number G0.HA.0003.021.00.088.01.03.E.E.O

document history

Revision index Description Author Review Release

Date

00.00 nur Konzept und Gliederung, mit Kommentaren A= SS R = Re =

08.09.2005

00.01 Entwurf weitgehend fertig, einige Kapitel noch offen. Details zu klären, externe Dokument-Referenzen noch offen.

A= SS R = Re =

16.09.2005

00.02 Erweitert und Verbesserungsvorschläge eingearbeitet A= SS R = Re =

19.09.2005

00.03 Translated to english, old parts modified, new parts added

A= SS R = Re =

29.09.2005

01.02 update to official version of german document A= SS R = Re =

10.10.2005

01.03 names modified, reference to “revision release list”, operating voltage modified, diagnostic test interval modified

A= SS R = Re =

11.10.2005

Involved at GEBHARDT Automation GmbH: Ulrich Gebhardt (UG), Wolfgang Paulicks (WP), Markus König (MK), Stephan Schild (SS), Dr. Peter Dellwig (PD)

GA TMR-S safety manual Rev01.03 11102005.doc page 2 of 40

Contents 1 INTRODUCTION ...................................................................................................................................... 6

1.1 CONTACT INFORMATION...................................................................................................................... 6 1.2 DOCUMENT SCOPE, APPLIED STANDARDS ............................................................................................ 7 1.3 GENERAL STATEMENTS........................................................................................................................ 8 1.4 DOCUMENT MAP .................................................................................................................................. 9

2 SAFETY LIFECYCLE ............................................................................................................................ 10 3 PRODUCT OVERVIEW......................................................................................................................... 12

3.1 COMPLETE SYSTEM............................................................................................................................ 12 3.2 FUNCTIONAL PRINCIPLE..................................................................................................................... 13 3.3 HARDWARE COMPONENTS ................................................................................................................. 14 3.4 ERROR RESPONSE............................................................................................................................... 14 3.5 FUNCTIONAL AND DISPLAY ELEMENTS OF HARDWARE COMPONENTS ................................................ 15

3.5.1 Elements of MCxxx-S cards.......................................................................................................... 15 3.5.2 Elements of ICU cards ................................................................................................................. 16 3.5.3 Elements of FPR cards................................................................................................................. 17 3.5.4 Elements of DSPVCU cards ......................................................................................................... 17 3.5.5 Elements of cooling fan ................................................................................................................ 18 3.5.6 Elements of TFAB DIGIO 2oo3 ................................................................................................... 18

3.6 SAFETY TIME AND REACTION TIME .................................................................................................... 19 3.6.1 System reaction time .................................................................................................................... 19 3.6.2 Diagnostic test interval ................................................................................................................ 19 3.6.3 Process safety time....................................................................................................................... 19 3.6.4 Proof test interval......................................................................................................................... 20

4 PES SYSTEM ENGINEERING.............................................................................................................. 21 4.1 HARDWARE ENGINEERING................................................................................................................. 21

4.1.1 Specification of safety requirements............................................................................................. 21 4.1.2 Hardware design and validation planning................................................................................... 21 4.1.3 System integration........................................................................................................................ 21 4.1.4 Hardware engineering, check list ................................................................................................ 22

4.2 SOFTWARE ENGINEERING .................................................................................................................. 22 4.2.1 Specification of safety requirements............................................................................................. 22 4.2.2 Software design and validation planning ..................................................................................... 22 4.2.3 Integration of PES hardware and software.................................................................................. 23 4.2.4 Software validation ...................................................................................................................... 23 4.2.5 Software engineering, check list................................................................................................... 24

5 ASSEMBLY AND INSTALLATION..................................................................................................... 25 5.1 QUALIFIED PERSONNEL...................................................................................................................... 25 5.2 SAFETY-RELEVANT RESTRICTIONS OF USE ......................................................................................... 25 5.3 MOUNTING AND CONNECTING ........................................................................................................... 25 5.4 ASSEMBLY AND INSTALLATION, CHECK LIST ..................................................................................... 26

6 FORCING I/O SIGNALS........................................................................................................................ 27 6.1 PROCEDURE ....................................................................................................................................... 27 6.2 FORCING I/O SIGNALS, CHECK LIST .................................................................................................... 27

7 COMMISSIONING ................................................................................................................................. 28 7.1 QUALIFIED PERSONNEL...................................................................................................................... 28 7.2 COMMISSIONING PROCEDURES .......................................................................................................... 28 7.3 APPLICATION SOFTWARE MODIFICATION........................................................................................... 29

7.3.1 Program modifications................................................................................................................. 29 7.3.2 Parameter modification................................................................................................................ 29 7.3.3 Online modification...................................................................................................................... 29

7.4 COMMISSIONING, CHECK LIST............................................................................................................ 30


8 MAINTENANCE ..................................................................................................................................... 31

8.1 QUALIFIED PERSONNEL...................................................................................................................... 31 8.2 MAINTENANCE PROCEDURES ............................................................................................................. 31 8.3 EXCHANGE OF COMPONENTS ............................................................................................................. 31 8.4 MAINTENANCE, CHECK LIST .............................................................................................................. 32

9 ACCESS AUTHORISATION................................................................................................................. 33 9.1 USER LOGIN ....................................................................................................................................... 33 9.2 KEY SWITCH FOR OPERATING MODE .................................................................................................. 33

10 DIAGNOSTIC INFORMATION............................................................................................................ 34 10.1 DIAGNOSTIC DATA............................................................................................................................. 34 10.2 PROCESS DATA................................................................................................................................... 34 10.3 ANALYSING ERROR MESSAGES .......................................................................................................... 35

11 COMMON TECHNICAL DATA ........................................................................................................... 36 12 SAFETY SPECIFIC DATA .................................................................................................................... 37

12.1 EQUATIONS FOR PROBABILITY OF FAILURE........................................................................................ 37 12.2 EXAMPLE........................................................................................................................................... 38

13 INDEX ....................................................................................................................................................... 40


List of figures Figure 1: document map............................................................................................................ 9 Figure 2: overall safety lifecycle............................................................................................. 10 Figure 3: hardware safety lifecycle ......................................................................................... 11 Figure 4: software safety lifecycle .......................................................................................... 11 Figure 5: Example for network integration ............................................................................. 12 Figure 6: Functional principle of GA TMR-S systems ........................................................... 13 Figure 7: front panel and elements of MCxxx-S cards ........................................................... 15 Figure 8: front panel and elements of ICU card...................................................................... 16 Figure 9: front panel and elements of FPR card...................................................................... 17 Figure 10: front panel and elements of DSPVCU card........................................................... 17 Figure 11: front panel and elements of cooling fan ................................................................ 18 Figure 12: TFAB DIGIO 2oo3 majority voter ........................................................................ 18 Figure 13: user login ............................................................................................................... 33 Figure 14: key switch Running/Maintenance.......................................................................... 33 Figure 15: Reliability diagram for 2-out-of-3 ......................................................................... 38 List of tables Table 1: check list hardware engineering................................................................................ 22 Table 2: check list software engineering, system integration ................................................. 24 Table 3: check list software engineering, programming ......................................................... 24 Table 4: check list software engineering, validation............................................................... 24 Table 5: check list assembly and installation .......................................................................... 26 Table 6: check list forcing i/o signals...................................................................................... 27 Table 7: check list commissioning .......................................................................................... 30 Table 8: check list commissioning, program modification ..................................................... 30 Table 9: check list maintenance, exchanging cards ................................................................ 32 Table 10: SIL rating for low and high demand modes............................................................ 39 Table 11: Safety integrity of hardware subsystems, type B.................................................... 39


1 Introduction

1.1 Contact information

GEBHARDT Automation GmbH

Oelkinghauser Str. 12 a D- 58256 Ennepetal Germany

Tel.: +49 2333 7908 - 0

available during working hours, Mo to Fr, from 800 to 1700 (5 pm) central european time (CET, GMT+1).

FAX: +49 2333 7908 - 24

Web: www.gebhardt-automation.de

Support [email protected] Information [email protected]


1.2 Document scope, applied standards This document applies to the following products:

• GA TMR/10-S • GA TMR SMART-S

hardware revision 00, date 01. Oct. 2005.

The GEBHARDT Automation GmbH safety systems are TÜV certified for safety integrity level SIL 3 according to IEC 61508 standard and conform to :

TÜV Rheinland Group TÜV Industrie Service GmbH Automation, Software und Informationstechnologie Am Grauen Stein D - 51105 Köln

TÜVRheinland

FunktionaleFunctional

SicherheitSafety

Bauart geprüft Type approved

Frei

willi

ge P

rüfu

ng n

ach

vere

inba

rten

Stan

dard

s

Certificate and test report No. 968/EZ 207.00/05 Programmable electronic safety systems GA TMR/10-S and GA TMR SMART-S

GEBHARDT Automation GmbH is entitled to use the above mark of conformity for „Func-tional Safety“ with its SIL3 certified safety systems. The systems are designed in accordance with following standards. All important, safety rele-vant features are tested according to:

• IEC 61508 Part 1 – 7: 1998 + 1999 Functional safety of programmable electronic systems

• DIN EN 954-1: 03.97

Sicherheit von Maschinen; Sicherheitsbezogene Teile von Steuerungen Teil 1: Allgemeine Gestaltungsleitsätze

• DIN EN 60204 Teil 1: 11.98

Sicherheit von Maschinen - Elektrische Ausrüstung von Maschinen Teil 1: Allgemeine Anforderungen

• DIN EN 50178: 1998

Ausrüstung von Starkstromanlagen mit elektronischen Betriebsmitteln • IEC 61131-2: 2003

Programmable controllers Part 2: Equipment requirements and tests


1.3 General statements All technical data and information in this document were compiled and controlled with ut-most care. Nevertheless errors can not completely be excluded. GEBHARDT Automation GmbH assumes no liability for consequences due to incorrect information. Accurate implementation of all safety instructions by qualified personnel is required for safe installation, commissioning, operating and maintenance of GA TMR-S safety systems. Unqualified use or handling of the systems may impair the performance of safety functions and lead to severe damage to property, environment or personnel. GEBHARDT Automation shall have neither liability nor responsibility for improper use of equipment. The GA TMR-S systems are designed, manufactured and tested according to applicable safety standards. They must be used only as specified in technical descriptions and be con-nected only to approved external devices. Modification is strictly prohibited. Use only approved replacement parts for repair and main-tenance. It is strictly prohibited to reproduce the software for GA TMR-S systems except for the pur-pose of backup. Any reverse engineering, such as reverse compilation or dis-assembling of the software is strictly prohibited. The GEBHARDT Automation products mentioned in this document may be registered tra-demarks. All other company and product names mentioned in this document are trademarks or regis-tered trademarks of their respective companies. No part of this document may be reproduced or transferred without prior written consent from GEBHARDT Automation GmbH. GEBHARDT Automation GmbH reserves the right to make improvements at any time, with-out notice or obligation. All rights reserved.


1.4 Document map

GA MCAD-S mod 1technical

description

GA TFAB-DIGIO-2oo3technical

description

GA MCDOT-S mod 1technical

description

GA MCDIN-S mod 1technical

description

GA safeEditonline help

GA safeEdituser manual

GA TMR-Ssafety manual

GA TMR-Sinstallation

manual

central manuals

software

hardware

FlyerNon-SIL3 systems

Flyeri/o cards

FlyerSafety &

Availability

FlyerGA TMR-S

systems

information

GA TMR-S rackstechnical

description

GA DSPVCUtechnical

description

GA FPR mod 1technical

description

GA ICU mod 1technical

description

TÜVRevision

Release List

Figure 1: document map

Figure 1 shows documents relevant to GA TMR-S safety systems. This manual will reference to the appropriate documents as required. Informative documents show an overview of their respective topic but are not safety relevant. They are not referenced in this safety manual.


2 Safety lifecycle For systematic assessment of safety the IEC 61508 standard considers the complete lifecycle of a system: beginning at the planning stage, continuing with commissioning, distribution, maintenance and repair, up to de-commissioning. This overall safety lifecycle is separated into 16 phases, defining methods and activities to achieve the required safety integrity for each phase.

Concept1

Overall scopedefinition2

Hazard and riskanalysis3

Overall safetyrequirements4

Safety requirementsallocation5

Overall installationand commissioning12

Overall safetyvalidation13

Overall operation,maintenance and repairr14 Overall modification

and retrofit15

Decommissioningor disposal16

Safety-relatedSystems:E/E/PES

Realisation(see E/E/PES

safetylifecycle)

9 Safety-relatedsystems:

other technology

Realisation

10 External riskreductionfacilities

Realisation

11Overall planning

Overalloperation andmaintenance

planning

Overallsafety

validationplanning

Overallinstallation andcommissioning

planning

6 7 8

Figure 2: overall safety lifecycle

This document concentrates on phase 9 of the overall safety lifecycle, the safety-related E/E/PES system. Specific lifecycles for hardware and software safety design define more detailed phases. Phases 10 (other technology, i.e. mechanical emergency shut down) and 11 (external facili-ties, i.e. escape routes or protective barriers) are not relevant for the scope of this document.


9.1.1

9.1

Safety functionsrequirementsspecification

E/E/PES safety requirementsspecification

9.1.2 Safety integrityrequirementsspecification

E/E/PES safetyvalidation planning

9.2 E/E/PES designand development

9.3

E/E/PES integration9.4

E/E/PESsafety validation

9.6

E/E/PES operation andmaintenanceprocedures

9.5

to box 12 inoverall safety lifecycle


Figure 3: hardware safety lifecycle

The hardware safety lifecycle must be considered during planning and design of the E/E/PES system. This document defines activities and procedures for each phase.

9.1.1

9.1

Safety functionsrequirementsspecification

Software safetyrequirements specification

9.1.2 Safety integrityrequirementsspecification

Software safetyvalidation planning

9.2 Software designand development

9.3

PE integration(hardware/software)

9.4

Software safetyvalidation

9.6

Software operation andmodification procedures

9.5



Figure 4: software safety lifecycle

The software safety lifecycle must be considered during planning and design of software for the E/E/PES system. This document defines activities and procedures for each phase.


3 Product overview

3.1 Complete system

Figure 5: Example for network integration

A safety project usually consists of at least one PES system GA TMR-S, one engineering station and one visualisation system (DCS, distributed control system). The PES system autonomously handles all safety functions. During normal operation, “running mode”, no other system (other PES, Engineering, DCS) can influence the PES. Only while switched to “maintenance mode” with a hardware key switch an authorized user can influence or modify the PES system. Safety relevant communication between GA TMR-S systems is currently available only via hardwired i/o signals. Engineering station is a PC, running Windows (2000 or XP) and the integrated development tool GA safeEdit. After activating maintenance mode this system may be used for commis-sioning and maintenance of GA TMR-S systems. In normal operation (running mode) the engineering station is not required, but may be used by authorized users for extended system diagnostics. Optionally engineering may share a PC with DCS. Both programs may be run in parallel on one computer. The visualisation system (DCS) accesses i/o data and system information via read access us-ing open communication protocols. There is no write access to the PES system. In addition to process values the DCS communication also allows access to diagnostic information, for visualisation, data logging and trending. Figure 5 shows two variants for a project consisting of one engineering station, one DCS and two PES systems: The left figure shows redundant networks. Communication for engineering and process visu-alisation is completely redundant, each TMR unit uses a separate, redundant network. In case of network failure this guarantees undisturbed communication to the remaining components. Engineering station and DCS must support three independent network cards. The right figure shows a simple, non-redundant, network. The redundant TMR units all use the same network. In case of network failure the complete communication may be lost. Safety functions and safety integrity are not influenced by network failures. GA TMR-S safety manual Rev01.03 11102005.doc page 12 of 40

Networks according to Figure 5 may be extended with further systems of all types (PES, DCS, Engineering). The same network may also include other, not safety related systems.

3.2 Functional principle

MCU-Adigital inputsanalog inputs

MCU-Bdigital inputsanalog inputs





MCU-Aredundant

control program

softw

are

1oo2

softw

are

Mo3

softw

are

Mo3

softw

are

Mo3

softw

are

Mo3

softw

are

Mo3

softw

are

Mo3

MCU-Bredundant

control program

MCU-Aredundant

control program

softw

are

1oo2

MCU-Bredundant

control program

outputs

2-ou

t-of-3

maj

ority

vot

ing,

ext

erna

l rel

ay h

ardw

are

datasensors

sensors

sensors

status

status

data

status

status

MCU-Aredundant

control program

softw

are

1oo2

MCU-Bredundant

control program

data

status

data, status

data, status

data, status

data, status

data, status

data, status

status

input cardsMCAD-S MCDIN-Sor

output cardsMCDOT-S

unit A

unit B

unit C

Figure 6: Functional principle of GA TMR-S systems

Figure 6 shows the functional principle of GA TMR-S systems. Input cards (MCDIN-S for digital inputs, MCAD-S for analog inputs) read field signals. Each card uses two redundant processors, MCU-A (micro controller unit A) and MCU-B, both having access to all signals. Using the internal data bus, ICU (industrial controller unit) communication cards and FPR (four ported RAM) memory cards the field signals are transmitted to output cards. For signal preprocessing the field signals may be exchanged between the input cards. Output cards MCDOT-S have access to all signals generated by input cards, field signals and preprocessed signals. Via software-configurable Mo3 selection (Mid of three) the triple re-dundant field signals may be combined into unified signals according to safety requirements, either by majority voting (digital signals) or by analog evaluation. These unified, common signals are used on all three redundant output cards. The output cards execute the actual con-trol program. Two MCUs on every card execute the application software, working redun-dantly to determine the output signals to hardware. Their internal output states are combined


into 1-out-of-2 software signals. These signals are used for the external voter with 2-out-of-3 hardwired relay logic. The hardware voter creates the actual field output signal. Outputs to the voter and relay states are read back as analog signals, allowing extensive signal diagnos-tics. A secondary independent shut-down path can always set the outputs to the safe power-off state, even at “stuck at one” error.

3.3 Hardware components Only hardware components registered in the revision-list of tested and certified components shall be used in GA TMR-S systems. See Revision Release List.

3.4 Error response Multiple build in test functions (BITs) running on the MCU processors on all MCxxx-S cards allow very high diagnostic coverage. This includes once-only tests during power-on, cyclic tests and dynamic tests. Cyclic BITs are repeated at fixed time intervals, dynamic tests de-pend on received data from other cards. Detected errors are displayed using the front side diagnostic LEDs on every MCxxx-S card. See technical description for the specific cards. Detected errors will also lead to appropriate error response of the i/o card, probably requiring user intervention.


3.5 Functional and display elements of hardware components

3.5.1 Elements of MCxxx-S cards All i/o cards use identical functional elements and display LEDs at the front panel. Figure 7 shows diagnostic LEDs and ejection lever.

Figure 7: front panel and elements of MCxxx-S cards

A special module rail in the rack (see bottom right), combined with the guiding pin in the card’s front panel (see center right) creates galvanic connection and dissipates static charge before the card electrically connects to the system. After loosening the neck screws at top and bottom of the front panel the card can be removed from the system. By pressing the red release button on the ejection lever the integrated micro switch turns of the card’s power supply and mechanically releases the lever (see center right) for pushing downwards. This will mechanically extract the card from the rack and internal data bus, using a clamp and groove mechanism in lever and system rack. This mechanism prevents accidental removing of cards while the lever is not released. Replacement cards are inserted using the lever mechanism with clamp and groove. With the lever pushed down card insertion will be stopped when the clamp hits the groove rail. By pushing the lever upwards it will mechanically pull the card into the system and data bus. The card will be turned off while being inserted. Only after mechanically connecting to the data bus the micro switch will activate the card and lock it into position. This reduces signal inter-ference on the data bus while inserting or removing cards to non-critical limits. 4 yellow LEDs (see top right) for each MCU processor display the current operating mode and error state. See technical description of the respective card for further information.


3.5.2 Elements of ICU cards The mechanical parts with ejection lever, module rail and guiding pin are identical to MCxxx-S cards. See Figure 7 and description.

Figure 8: front panel and elements of ICU card

The front plate uses LEDs to display status information: • Ethernet Link/Act: yellow LED shows physical connection and network activity.

Normal state: flashing yellow • Ethernet 100: green LED shows fast Ethernet, with 100 MBit, LED off indicates

slow, 10 MBit connection. Normal state: static green

• T/R1 and T/R2: yellow LED indicates activity on serial port COM1 and COM2, Transmit/Receive 1 and 2 COM1 is used as programming interface only, LED always off COM2 may be used for MODBUS RTU communication, LED off or flashing

• ARC: yellow LED indicates Arcnet network activity. Arcnet is not used for TMR-S systems. Normal state: off

• MA: green LED indicates correct functionality of ICU as bus master. During system start up the LED is off. Normal state: static green

• R/U: not relevant in TMR-S systems, no default state • WDG: red LED indicates Watchdog error.

Normal state: always off


3.5.3 Elements of FPR cards The mechanical parts with ejection lever, module rail and guiding pin are identical to MCxxx-S cards. See Figure 7 and description.

Figure 9: front panel and elements of FPR card

The separate units A, B and C in the TMR-S system use shared memory areas on FPR cards (Four Ported RAM) for internal communication. The forth area, D, is not used. Each unit writes into its own area but reads from all areas. Green LEDs indicate write access (WR) to an area. Normal state is fast, almost continuous flashing. Yellow LEDs indicate read access (RD) to an area. Normal state is fast, almost con-tinuous flashing.

3.5.4 Elements of DSPVCU cards

Figure 10: front panel and elements of DSPVCU card

The DSPVCU voltage control cards are independent control cards for monitoring the secon-dary voltages of the two redundant power supplies and generating a malfunction signal in


case of over-voltage or under-voltage detection. They use a simple ejection lever, without micro switch or mechanical release. The card is not connected to the data bus. Red LEDs show failures in voltage monitoring of any of the required voltages, indicating either “Lower Limit” or “Upper Limit” failure. Normal state for all LEDs is off. The green LED is a combined “Power Good” signal, continuously on during normal opera-tion. See technical description for further details.

3.5.5 Elements of cooling fan

Figure 11: front panel and elements of cooling fan

LEDs in the front panel show the operating mode. Normal state is green LED on and red LED (alarm) off. A fan malfunction, e.g. mechanical jamming, activates the red “alarm” LED. Pressing the reset button after correcting the problem acknowledges the alarm and turns the LED off. Loosening of two retaining screws in the front panel allow removal and replacement of the cooling fan during normal operation. Fan malfunction has no direct impact on the TMR-S system. It may lead to over-temperature of the complete system or individual components.

3.5.6 Elements of TFAB DIGIO 2oo3

Figure 12: TFAB DIGIO 2oo3 majority voter

The field assembly board TFAB DIGIO 2oo3 uses no direct display elements. Two fuses at the upper left corner must be in the “pushed in” position. Three relays for each digital output signal show the output state for each unit A, B or C. Usu-ally they will show identical position (open/close). During self-tests (walking zero) one relay


will temporarily switch to the other state while the other two relays of the group keep the correct position. The TFAB is designed with force-guided safety relays, using the “de-energize to trip” princi-ple.

3.6 Safety time and reaction time

3.6.1 System reaction time System reaction time is the interval between occurrence of an external demand and the PES system’s response. It includes the time between occurrence and detection, time for internal calculations, setting of hardware output signals and relay switching times. The time for internal calculations, the program cycle time, depends on complexity of all con-trol functions handled by one MCDOT-S processor card. For details on program cycle time see GA safeEdit user manual. Usually the doubled program cycle time plus 15 msec for relay switching may be used as system reaction time. Exceptions from this time may occur when:

• safety function distributed over multiple MCDOT-S output cards • hardwired communication between GA TMR-S racks

3.6.2 Diagnostic test interval In addition to safety functions the PES system also continually performs diagnostic functions to detect erroneous system performance. Diagnostic test interval defines the time between repetitions of diagnostic tests. The diagnostic test interval must be chosen to achieve a probability of random hardware fail-ure below or equal to the target failure measure defined in safety integrity specifications. In non-redundant PES systems the sum of diagnostic test interval and failure reaction time must be less than the process safety time. For GA TMR-S systems the probability of dangerous hardware failure (failure of safety func-tion without changing to safe state) is extremely low, due to triple redundancy and fail-safe concept, so the diagnostic test interval is appropriate. It is specified in system firmware and can not be modified by the user.

3.6.3 Process safety time The process safety time is the interval between occurrence of a disorder (at machine or proc-ess, equipment under control, EUC) and reaching of a critical state. The safety system must be able to bring the process to a safe state in this time interval. Process safety time considers the complete safety loop: from sensor and transmitter, over PES system, to actuator. The PES system reaction time may be used as basis for calculating process safety time com-pliance. The diagnostic test interval is usually not required for the calculation.


3.6.4 Proof test interval The proof test is used at specified intervals to completely check the PES system and bring it back to “like new” safety integrity. Special attention is given to failures not detectable by internal diagnostic tests. As minimum all safety functions handled by the PES system must be checked according to specification. The time interval between proof tests should not exceed 10 years. Shortening the test interval will reduce the probability of system failure. Typical intervals are 10 years or 3 years.


4 PES system engineering Planning, design and realisation of the PES system are implemented according to box 9 “safety-related systems: E/E/PES” in Figure 2: overall safety lifecycle on page 10. Figure 3: hardware and Figure 4: software show detailed phases for engineering and specify required activities and procedures.

4.1 Hardware Engineering

4.1.1 Specification of safety requirements A detailed list with all safety requirements for the project is compiled. This is the basis for all decisions on hardware and software design of the PES system.

4.1.2 Hardware design and validation planning Hardware design takes the list of requirements and decides on the necessary hardware to han-dle these requirements. The number and type of PES systems, including number of i/o cards, is defined. In parallel to planning the hardware the required methods for hardware validation are defined. Specific procedures and measures during hardware design are:

• For each specified safety function the PES internal safety circle (input signals, con-trol, output signals) is designed. All input signals should be accessed by cards in the same system, all outputs must be handled on the same output card MCDOT-S. Segmentation of safety circles to multiple PES systems is possible via hardwired communication, but should be avoided when possible. Affected signals require spe-cial attention in validation planning, specifically considering system reaction time.

• Every MCDOT-S card may process multiple safety functions. Usually a uniform distribution of safety functions over processor cards is recommended to achieve similar system reaction times.

• Interdependencies of input signals used in multiple safety functions must be speci-fied and documented. They require special attention during validation.

• Distribution of i/o signals to PES systems and their respective i/o cards must be documented and considered for validation.

• Distribution of safety functions to PES systems and MCDOT-S i/o processor cards must be documented and considered for validation and software engineering.

4.1.3 System integration System integration designs the integration of the PES systems in the project’s safety concept. The following measures need to be considered:

• Integration of PES systems in the control panel, including external hardware. • Integration of multiple PES systems, with special attention on hardwired communi-

cation. • Integration of PES systems in the overall concept, including engineering station and

visualisation (DCS) • Network layout for engineering and visualisation, including redundancy and address

configuration.


4.1.4 Hardware engineering, check list No. Description Check

1 Number of i/o cards according to safety functions, including spare signals 2 Slot position of i/o cards according to system design specification. 3 Analog frequency inputs with correct cut-off frequency. 4 Appropriate distribution of safety functions over MCDOT-S i/o processor

cards with regard to output signals.

5 Hardwired communication between PES systems: acceptable system reac-tion time?

6 Connecting cables: correct cable type and length? 7 Network layout: distance, cable length, cable type (copper, optical),

switches, routers, redundancy, addressing

Table 1: check list hardware engineering

4.2 Software engineering

4.2.1 Specification of safety requirements The list of safety requirements according to chapter Specification of safety requirements on page 21 is extended with signal information on i/o signals. For each digital signal the contact mode (normally open, normally closed) if specified, for analog signals the physical range is defined. For each safety function the required safety time is specified. For each safety function the working principle is defined.

4.2.2 Software design and validation planning The distribution of safety functions to PES hardware components is implemented as applica-tion software, considering software safety specifications. For each safety function the PES-internal safety circle of input signal, application program and output signal is considered. GA safeEdit is used as programming tool, see GA safeEdit user manual. Software design considers the following measures:

• Application programming for specific safety functions on MCDOT-S cards accord-ing to hardware design specifications.

• Error response for signal failure specified for every input signal in every safety function: Mid-of-3, available/error, (see GA safeEdit user manual). Documentation and validation planning for each signal.

• Analysis of switch-over between operating modes in safety functions. Validation planning for all operating modes with special attention on the time of switch-over.

• Interdependencies between safety functions (one input signal or calculated internal state used in multiple safety functions) must be clearly defined, documented and considered in validation.

• Definition of calculated thresholds for analog inputs, physically and scaled to con-troller-internal range, with hysteresis. Documentation and validation planning.

• Power-on behaviour for safety functions, including validation. • Signal tracking for software functions with internal memory function (e.g. RS flip

flop) , including validation.


4.2.3 Integration of PES hardware and software PES system integration gives special attention to dependencies between hardware and soft-ware. An important factor is also the integration into the overall system concept, including PES diagnostics in regular process visualisation (DCS). Integration considers the following measures:

• Coordinating of hardware and software configuration (slot configuration, network, i/o access).

• Activation of signal diagnostics (cable failure, short cut) for used signals, deactiva-tion for spare signals.

• Estimation of system reaction time of all MSDOT-S output processor cards, and comparing with required system reaction time. Consider adequate reserve for soft-ware changes during commissioning.

• Memory utilization of MCDOT-S processor cards acceptable, including adequate reserve for software changes during commissioning.

• All relevant diagnostic information of PES systems should be displayed on regular process visualisation, to inform about critical states or system degradation and allow sufficient time for corrective maintenance.

4.2.4 Software validation Software validation uses the programming tool GA safeEdit and the following methods:

• Syntax check and parameter check, offline. On engineering station or PC. • Offline simulation on engineering station or PC, without PES hardware. • Online debug on PES hardware, with forced i/o signals, no field signals. • Online debug on PES hardware, with field signals simulates by test equipment (usu-

ally during panel acceptance test) • During commissioning full software test, online debug and functional, with full

field wiring. First with stopped machine, finally with the machine running.


4.2.5 Software engineering, check list No. Description Check

1 Hardware and software configuration corresponding 2 Network configuration correct in hardware and software 3 System reaction time of each MCDOT-S card acceptable as compared to

required safety times

4 Memory utilization of MCDOT-S cards acceptable with enough free memory for modifications during commissioning

5 Signal error detection cable failure/short cut active for used signals, inac-tive for spare signals

6 Access to all necessary diagnostic information specified and/or pro-grammed for process visualisation (DCS)

7 System configuration according to project requirements (time-outs, time settings, internal communication, ...)

Table 2: check list software engineering, system integration No. Description Check

1 Signal states and ranges for each signal programmed according to specifi-cation?

2 Signal behaviour (Mo3) for each signal in every safety function defined according to specification?

3 Analog thresholds programmed according to specification, including scal-ing and hysteresis?

4 Interdependencies between safety functions according to specification? 5 Power-on behaviour of safety functions according to specification? 6 Signal tracking (TMR tracking) fur software functions with internal

memory implemented according to specification?

Table 3: check list software engineering, programming

No. Description Check

1 Syntax check and parameter check: no errors, no warnings? 2 Simulation offline on PC: functionality as specified? 3 Online debug on PES system, without field signals, forced signals in

maintenance mode: functionality as specified?

4 Online debug on PES system, with simulated field signals (test equip-ment, panel acceptance test), in running mode: functionality as specified?

Table 4: check list software engineering, validation


5 Assembly and installation

5.1 Qualified personnel All persons involved in assembly and installation must be qualified according to their duties. They must be familiar with relevant technical manuals and system hardware, and be appro-priately trained in safety procedures. Qualification includes:

• training and experience in handling of electrical equipment according to approved codes of practice

• experience in installation of GA TMR-S components • training in i/o signal diagnostics with programming tool GA safeEdit may be re-

quired • instruction in project specific safety concept • training in use of appropriate safety equipment • training in first aid

5.2 Safety-relevant restrictions of use The systems must be used in normal environments only. It must be protected against acidic environments, especially H2S components.

5.3 Mounting and connecting For details on mounting and electrical connecting see technical descriptions of relevant com-ponents and GA TMR-S installation manual. Generally the following items apply:

• mounting must be stable, no mechanical vibrations all screws fixed tightly

• to allow adequate cooling all components must be mounted in correct position, kee-ping sufficient distance from other components.

• Signal lines must be kept separately from power lines. All lines require tidy wiring and appropriate labelling. If required, signal lines must be protected against over voltage and over current.

• Power supply must be in acceptable range. • Component mounting must be EMC compatible. For racks this includes correct con-

nection to protective ground. • Most components include devices sensitive to electro-static discharge. Discharges

by touching components must be avoided by using appropriate measures (touching of or connection to electrically grounded metal parts, ...). Protective measures are always required when changing components.


5.4 Assembly and installation, check list No. Description Check

1 Optical check: no damage, proper mounting, proper and tidy wiring, com-ponent labelling present and correct

2 Mechanical check: screws tightened, components fixed in position, no vibration

3 wiring: plugs connected and fixed, correct grounding, separation of signal and power wiring

4 Power-on test: all LEDs show normal state

Table 5: check list assembly and installation


6 Forcing i/o signals

6.1 Procedure With forcing all input and output signals of a PES system may be set to any specific value, independent of field inputs or PES control outputs. This will interfere in safety functions, restricting or disabling them, so forcing may be used only during commissioning and mainte-nance, under specified operating conditions. The GA safeEdit user manual explains procedures for forcing all types of i/o signals. The following items must be considered concerning forcing:

• Impact analysis: the impact on PES system and process must be analysed and clearly understood before forcing. Required operating conditions on PES system, machine and process must be defined and established.

• Forcing is allowed only to qualified personnel, during commissioning or mainte-nance. In normal operation forced signals are not allowed, because related safety functions are restricted or disabled.

• The procedure to achieve desired forced states must be clearly understood: is there any specific order required in forcing several signals? The triple redundancy must be considered in procedures.

• The procedure for releasing the forced mode must be clearly understood. • Additional external safety measures may be required to compensate for disabled

safety functions (e.g. restricted areas). • Emergency procedures must be defined and prepared to handle potential problems

due to disabled safety functions.

6.2 Forcing i/o signals, check list Nr. description Check 1 Are impacts on system and process analysed and clearly understood? 2 Are system and process requirements (e.g. operating conditions) estab-

lished?

3 Is the procedure for forcing the desired state clearly understood? 4 Is the procedure for releasing force-mode and return to normal operation

clearly understood?

5 Are required external safety/protective measures prepared? 6 Are sufficient emergency measures prepared?

Table 6: check list forcing i/o signals


7 Commissioning

7.1 Qualified personnel All persons involved in commissioning must be qualified according to their duties. They must be familiar with relevant technical manuals, system hardware and software, and be ap-propriately trained in safety procedures. Qualification includes:


• software training for the programming tool GA safeEdit for commissioning of SIL3 safety systems

• instruction in project specific safety concept • instruction in project specific application software • experience in integration of control systems with control panel • instruction in machinery and processes to be controlled • training in use of appropriate safety equipment • training in first aid

7.2 Commissioning procedures Commissioning uses the programming tool GA safeEdit for programming, system configura-tion and diagnostic of hardware and software. A visualisation on a DCS may be running in parallel via communication, for process states and diagnostics. This communication must also be checked and, when required, be modified during commissioning. During commissioning the PES system will mostly run in maintenance mode. The commis-sioning technician needs hardware keys and appropriate passwords to enter maintenance mode. The system must be protected against unauthorized access. Activities and procedures during commissioning:

• During commissioning the safety functions are not yet working or work only par-tially. Appropriate safety and emergency measures must be provided.

• At the first use of PES hardware electrical connections of all components must be checked.

• Check software system configuration: in accordance with documentation • Check network communication: all systems connected and responding • Loop check: all i/o signals in GA safeEdit diagnostic display and in visualisation.

Check full range, including cable failure and short cut. Error diagnostics must be correct in engineering station and DCS.

• Functional check of safety functions, machine stopped • Functional check of safety functions, machine running • Data back-up and documentation of all changes • Enter normal, safe operating mode. Check: running mode active, key for mode

switch removed, no signals forced, password protection


7.3 Application software modification

7.3.1 Program modifications Any modifications in existing and approved application software require an impact analysis:

• Print current program version, create software back-up. • Plan modifications and create new program with GA safeEdit. • Print and save new program. • Check for interconnections between modified safety functions and other functions,

using graphical program editor. • Analyse modified functions, including interconnected old functions, regarding:

only the desired effects on modified functions, no side-effects in modified or old functions. When modifications affect switches between operating modes the time of switching requires special attention.

• Test the new version, at first with simulation, than with stopped machine. • Check system reaction time of new software. • All changes must be documented and backed-up.

7.3.2 Parameter modification Any modifications require an impact analysis:

• Create software backup. • Plan modifications. • Check for interconnection of modified parameters in other functions, using graphi-

cal program editor. • Analyse affected safety functions, including interconnected functions:

only desired effects, no side-effects? • When changing range or scaling of i/o signals the communication to visualisation

system may be affected. • Test the new version. • All changes must be documented and backed-up.

7.3.3 Online modification Whenever possible changes should be done with the machine stopped. During modification the system’s safety integrity is partially compromised. Incorrect changes or procedures may affect safety functions. Modifications with the machine running are possible but need special attention:

• Impact analysis just like analysis for normal changes. • Additionally impact analysis for power-on behaviour. • Additionally impact analysis of different signal states on the three separate units in a

TMR-S system, during re-programming and start-up. • All units must be programmed separately. After each unit is programmed the correct

state of all i/o signals and internal states must be checked. Balancing of states by forcing of i/o signals may be required.

• During the time of modification appropriate safety measures must be used, see also chapter Forcing i/o signals on page 27.

• During modification the safety functions are affected. Appropriate emergency measures must be prepared.


7.4 Commissioning, check list No. Description Check

1 Is the project’s safety concept clearly understood? 2 Required key switches and passwords available? 3 System hardware configuration correct? 4 Communication check with all systems successful? 5 Loop check for all i/o signals: range and diagnostics correct? 6 Appropriate safety measures and emergency measures prepared? 7 Check of safety functions, machine stopped, running machine. 7a When required: program modification, see additional check list. 8 Check system reaction time, for each MCDOT-S card. 9 Set safe operating state: system locked, no i/o forcing. 10 Data back-up of complete software

Table 7: check list commissioning No. Description Check

1 Back-up old version. 2 Modification with machine stopped or running? 3 Planning of modifications and impact analysis. 4 Appropriate safety measures and emergency measures prepared? 5 Implementation and test of new software 6 Check system reaction time, for each affected MCDOT-S card. 7 Documentation of successful changes. 8 Back-up new version.

Table 8: check list commissioning, program modification


8 Maintenance

8.1 Qualified personnel All persons involved in maintenance must be qualified according to their duties. They must be familiar with relevant technical manuals, system hardware and software, and be appropri-ately trained in safety procedures. Qualification includes:


• software training for the programming tool GA safeEdit for maintenance and diag-nostics

• instruction in project specific safety concept • training in use of appropriate safety equipment • training in first aid

8.2 Maintenance procedures Regular maintenance is planned in detail as component of the safety concept. The planned tasks are performed in specified service intervals, including:

• Proof-Test interval • checking and changing air filters • checking for fouling or contamination • control of system diagnostics like: diagnostic visualisation in DCS, alarms, LED

display on hardware components, extended diagnostic information on engineering station using GA safeEdit

Unscheduled maintenance becomes necessary when regular maintenance shows irregularities. It is generically considered in the safety concept and includes the activities:

• identification and repair of i/o signal failures • identification and repair/exchange of PES system components (i/o cards, fan, power

supply, ...) • identification and repair of network communication failures

Unscheduled maintenance requires:

• Unequivocal identification of error messages and cause for error: i.e. high system temperature may have several causes: fouled air filter, cooling fan failure, control panel air conditioning failure.

• Cross-check of detected error or message with all available tools: DCS visualisa-tion, hardware check (optical, LEDs, ...), extended diagnostics on engineering sta-tion.

• Impact analysis of error/failure consequences on safety and availability. • Planning of maintenance tasks, procedures and responsible personnel. • Planning of appropriate safety and emergency measures.

8.3 Exchange of components Exchange of components is possible during normal operation, details are specified in: GA TMR-S racks technical description


Exchange of programmable system components, MCxxx-S cards and ICU cards requires spe-cial attention:

• Exchange of MCxxx-S or ICU cards requires use of engineering station with GA safeEdit.

• The PES system is switched to maintenance mode. • Password protection of GA safeEdit requires use of valid password. • Error and cause of error is identified, analysed and documented. • The failed card is removed, see relevant technical documentation. • Hardware settings (jumper, switches) of spare card are compared and adjusted with

failed card, see relevant technical descriptions. • Spare card is inserted into the system rack. • Configuration of spare card is checked and modified as required. Correct detection

and configuration is displayed in GA safeEdit. • Replacing i/o cards:

o The application program is checked. Usually the current program must be downloaded to the spare card.

o signal cable from field assembly module to connector is plugged in and fixed. o Correct state of i/o signals and internally calculated states is compared with

redundant cards of other TMR-S units. • The complete system is checked, running with the new card. • The system is returned to “Running” operation mode.

The relevant technical description of each card shows details on card exchange and configu-ration. Additional information on configuration and programming is available in GA safeEdit user manual.

8.4 Maintenance, check list Checks for regular maintenance, including proof-test intervals, uses project specific check lists. No. Description Check

1 Unequivocal identification of problem: corresponding diagnostics in visu-alisation, engineering station and LEDs on card?

2 Process for exchanging cards clearly understood? 3 Appropriate safety and emergency measures prepared? 4 New card configured and correctly detected by the system? 5 Correct application program on new card? 6 External signals and internal card states agree with cards on redundant

units?

7 All i/o signals working? 8 System returned to safe operating state after finishing maintenance work?

Table 9: check list maintenance, exchanging cards


9 Access authorisation

9.1 User login

Figure 13: user login

Before using GA safeEdit to access GA TMR-S systems a user authorisation is required. In “Account login” select a user name from the list of authorised users. Enter the corresponding password below. The list always has at least the user “Admin”, other user names depend on system configura-tion. The user may work within the scope of his access permissions. Modification of user authori-sation and permissions is available for “Admin” only. Users with highest priority may fully access diagnostics, configuration and programming of i/o processor cards and ICU communi-cation processor. Access beyond diagnostics, affecting the PES system, additionally requires activation of “Maintenance” mode with the hardware key switch. “Running” mode allows only diagnostics. User configuration and access rights are explained in GA safeEdit user manual.

9.2 Key switch for operating mode

Figure 14: key switch Running/Maintenance

The hardware key switch selects between “Running” and “Maintenance” operating mode, i.e. normal safety operating mode and unsafe maintenance mode. Maintenance mode allows hardware access that may interfere with safety functions, including forcing of i/o signals, programming of control processors and system configuration. When using appropriate safety and emergency measures, maintenance mode can be used with the machine/process running. Ordinary, day-to-day operation of the machine is not allowed in maintenance mode. Running mode is the safe operating mode. GA TMR-S safety manual Rev01.03 11102005.doc page 33 of 40

After successful commissioning or maintenance all forced i/o signals are released, than the key switch is turned to “Running” position and the key removed. This mode protects the PES system from external interference by the engineering station. Diagnostics on engineering sta-tion and communication to DCS remain available. Signals forced to specific states in maintenance mode, analog or digital, remain at the forced state when the system changes to running mode. A warning message informs of this unsafe condition.

10 Diagnostic information

10.1 Diagnostic data Self test statistics Authorised users can access self test statistics, stored on each MCxxx-S card. The informa-tion is stored in card-internal flash memory. Access via GA safeEdit, see user manual. Log-book of system messages The engineering station logs all system messages (information, warnings, errors). All mes-sages are displayed on screen and written to a log-book file. Each message includes time stamp and informational text. See chapter Analysing error messages on page 35. Additionally all messages of the TMR units A, B and C are stored in flash memory on their respective ICU card and can be accessed from the engineering station. Visualisation system Via communication extensive diagnostic information on all i/o signals is accessible at the DCS: cable failure, short cut, signal forced, forced-state for digital signals. Life-bit diagnostic may be programmed for each i/o card to continually check communication and functionality. System temperatures and voltages of ICU communication controllers are also accessible. Storage or logging of this data is available according to capabilities of the visualisation sys-tem.

10.2 Process data All process data is continually available to the DCS system, using communication via ICU communication controller. Display and logging of data is available according to capabilities of that system. Online data may also be accessed from the engineering station, using the graphical trend ana-lyzer in GA safeEdit, see user manual. Real-time data logging of all i/o signals, including time synchronisation between several con-trollers, is optionally available on the ICU controllers.


10.3 Analysing error messages The programming tool GA safeEdit shows extensive diagnostic information. If unusual sys-tem behaviour occurs appropriate diagnostic messages are displayed and logged to file. The example shows a typical error message: Fr, 16 Sep 2005 15:57:52 : MCU-S 192.168.100.183 (1): (2,13,0) Card Timeout (ID:116): unit:0, slot:6, timestamp:0xe377, time:0xe44f The first part shows date and time information about the error: Friday, 16th September 2005 at 15:57 and 52 seconds. The next part is type of processor sending the message, followed by the TCP/IP address of the ICU sending this error, and the network number in redundant network: MCU-S, an i/o card with MCU processors on address 192.168.100.183 in network number (1). TMR-S systems may use three redundant networks (1), (2) and (3). The next part is card position in the TMR-S system, identified by unit number (0 = unit A, 1 = unit B, 2 = unit C), card slot number (1 ... 16) and processor number (0 = MCU-A, 1 = MCU-B): (2,13,0) identifies a card in unit C, slot 13, processor MCU-A The next part is the actual error message, followed by an identification number. The number is used as reference to detailed error information in technical description of the respective card, explaining causes and procedures for responding to the error: Card Timeout is the actual error, (ID:116) the ID in technical description. To get de-tailed information on error 116 check the card type in slot 13 (MCDIN-S, MCAD-S or MCDOT-S) and read the technical description for this card type. The last part is internal time information. Internal time stamps use a system-relative time count in milliseconds. Timestamp specifies the internal time when the error occurred, time is the current time when the error was reported. Time stamps are used to analyse a sequence of events if multiple errors occur.


11 Common technical data power supply nominal operating voltage 100 ... 240 VAC, 50 ... 60 Hz maximum operating voltage 85 ... 264 VAC, 47 ... 63 Hz max. power TMR/10-S 450 W max. power TMR SMART-S 300 W digital inputs, MCDIN-S input current according to NAMUR “high level” current > 2,1 mA “low level” current < 1,2 mA analog inputs MCAD-S input current 0 ... 25mA frequency input 100 Hz ...15 kHz digital outputs MCDOT-S / TFAB output voltage 24 VDC, 230 VAC output current, per channel (max.) 0 ... 6A environmental conditions storage temperature -25°C ... +70 °C operating temperature +0°C ... +55°C relative humidity 10% ... 90%, non condensing protection class IEC 525 IP 20 operating altitude max. 2000m pollution degree 2 power supply IEC 536 safety class 1, with PE field connections safety class III dimensions TMR/10-S ( 10HE / 84 TE) TMR SMART-S ( 4HE / 84 TE)

482,6 x 457,5 x 391 mm [W x H x D] 482,6 x 191 x 391 mm [W x H x D]

For more details see technical description of components.


12 Safety specific data

12.1 Equations for probability of failure In systems with 2-out-of-3 signal handling the probability of failure PFD and PFH is calcu-lated as:

( ) ⎟⎠⎞

⎜⎝⎛ +⋅⋅+⋅⋅+⋅⋅⋅−+⋅−⋅= MTTRTMTTRttPFD DUDDDGECEDUDDDG 2

)1()1(6 12 λβλβλβλβ

( ) DUDDDCEDUDDDG tPFH λβλβλβλβ ⋅+⋅+⋅⋅−+⋅−⋅= 2)1()1(6

with:

MTTRMTTRTtD

DD

D

DUCE ⋅+⎟

⎠⎞

⎜⎝⎛ +⋅=

λλ

λλ

21

MTTRMTTRTtD

DD

D

DUGE ⋅+⎟

⎠⎞

⎜⎝⎛ +⋅=

λλ

λλ

31

The safe failure fraction SFF is calculated as:

DUDDS

DDSSFFλλλ

λλ++

+=

The diagnostic coverage is calculated as:

∑∑=

D

DDDCλλ

used values: Symbol Description β weighting factor for dangerous undetected common cause failures βD weighting factor for dangerous detected common cause failures λ failure rate (per hour) of one channel in one sub-system λD dangerous failure rate (per hour) of one channel in one sub-system (D = dan-

gerous) λDD detected dangerous failure rate (per hour) (DD = dangerous, detected) λDU undetected dangerous failure rate (per hour) (DU = dangerous, undetected) λS safe failure rate (per hour) of one channel in one sub-system (S = safe) T1 proof test interval (in hours) MTTR Mean Time To Repair (in hours) DC diagnostic coverage SFF safe failure fration PFDG average probability of failure on demand in system with majority voter PFHG average probability of failure per hour in system with majority voter tCE average channel-related failure time (in hours) tGE average system-related failure time (in hours)


12.2 Example A typical, triple redundant system with redundant input cards, redundant output cards and a common, 2-out-of-3 majority voter TFAB-DIGIO-2oo3 is used as an example. The example assumes non-redundant sensors and actuators (per TMR unit).

Figure 15: Reliability diagram for 2-out-of-3

This configuration can read up to 24 digital input signals (times 3, for redundancy). The pro-cessors on MCDOT-S cards can combine these input signals for safety function programming and can use up to 10 digital output signals to control the EUC (equipment under control).


Calculation for this system results in:

99,21%99,9058%

107,784

105,9249

7

==

⋅=

⋅=

⋅=⋅=⋅=⋅=⋅=⋅=⋅=⋅=

=⋅=

−

−

+

+

−

−

−

−

−

−

+

DCSFF

PFH

PFD

G

G

1

1

9

7

7

6

2

2

31

101167,3102800,4100135,6105193,7105795,7106240,5100000,1100000,2

0,8year) (1 107600,8

GE

CE

DU

DD

D

S

D

tt

MTTRT

λλλλβ

β

Experience in practical use show a distribution of failure rates to 35 % of failures for sensor + transmitter, 15% failure for control system and 50 % failure for actuator. Considering this distribution the IEC 61508 table for failure probability shows a rating for the GA TMR-S system:

SIL PFD PFH 1 ≥ 10-2 to < 10-1 ≥ 10-6 to < 10-5

2 ≥ 10-3 to < 10-2 ≥ 10-7 to < 10-6

3 ≥ 10-4 to < 10-3 ≥ 10-8 to < 10-7

4 ≥ 10-5 to < 10-4 ≥ 10-9 to < 10-8

Table 10: SIL rating for low and high demand modes The IEC 61508 table for safety integrity of hardware subsystems, type B, shows a rating for the GA TMR-S system:

Hardware Fault Tolerance (HFT) SFF 0 1 2 < 60 % nicht erlaubt SIL 1 SIL 2

60 % to < 90 % SIL 1 SIL 2 SIL 3 90 % to < 99 % SIL 2 SIL 3 SIL 4

≥ 99 % SIL 3 SIL 4 SIL 4

Table 11: Safety integrity of hardware subsystems, type B The required values for SIL 3 according to IEC 61508 are easily met or surpassed.


13 Index BITs........................................................ 14 calculation

SFF ............................................... 37, 39 calculations

diagnostic coverage ...................... 14, 37 failure rate .......................................... 37 HFT .................................................... 39 MTTR................................................. 37 PFD............................................... 37, 39 PFH............................................... 37, 39 probability of failure........................... 37

cards DSPVCU ............................................ 17 FPR............................................... 13, 17 i/o................................ 15, 21, 22, 31, 32 ICU....................... 13, 16, 32, 33, 34, 35 MCAD-S ................................ 13, 35, 36 MCDIN-S ..................................... 13, 35 MCDOT-S13, 19, 21, 22, 23, 24, 30, 35,

36, 38 MCxxx-S .............. 14, 15, 16, 17, 32, 34

certificate.................................................. 7 common cause ........................................ 37 communication12, 13, 16, 17, 19, 21, 22,

24, 28, 29, 30, 31, 33, 34 DCS .................... 12, 21, 23, 24, 28, 31, 34 diagnostic test ......................................... 19

Engineering Hardware...................................... 21, 22 software.................................. 21, 22, 24 station ............. 12, 21, 23, 28, 31, 32, 34

failure rate .............................................. 39 GA safeEdit12, 22, 23, 25, 28, 29, 31, 32,

33, 34, 35 GA TMR-S7, 8, 9, 12, 13, 14, 17, 18, 19,

25, 33, 39 IEC 61508 .................................... 7, 10, 39 key switch ............................ 12, 30, 33, 34 lifecycle ............................................ 10, 11 maintenance8, 10, 12, 23, 24, 27, 28, 31,

32, 33, 34 PES system10, 11, 12, 19, 20, 21, 22, 23,

24, 27, 28, 31, 32, 33, 34 process data ............................................ 34 program cycle time................................. 19 proof test .......................................... 20, 37 running ........................... 12, 24, 28, 32, 33 self test ................................................... 34 system reaction time19, 21, 22, 23, 24, 29,

30 time synchronisation .............................. 34 TMR-S ................................................... 12 trend analyzer ......................................... 34 visualisation system ................... 12, 29, 34


GA TMR-S Safety Manual - Certipedia · 2020. 8. 7. · Title GA TMR-S safety manual File GA TMR-S...

Documents

Transcript of GA TMR-S Safety Manual - Certipedia · 2020. 8. 7. · Title GA TMR-S safety manual File GA TMR-S...