GA BlueLine safety manual - TUV Cooperation - Functional Safety

GEBHARDT Automation GmbH 

GA BlueLine 

safety systems 

Safety Manual

Title GA BlueLine safety systems - safety manual 

File GA BlueLine safety systems - safety manual Rev00.01 24.01.2011.doc 

Document 

number 

Revision index Description 

G0.HA.0003.031.41.088.00.01.E.E.O 

document history 

Author 

Review 

Release 

00.00 first release A = StS 

00.01 update for MPU-M1 processor card, GA BlueEdit programming 

tool, SCM1 current monitoring module 

R = MK 

Re = UG 

A = StS 

R = MK 

Re = UG 

Involved at GEBHARDT Automation GmbH: Ulrich Gebhardt (UG), Wolfgang Paulicks (WP), 

Markus König (MK), Stephan Schild (StS), Oliver Bäsken (OB) 

Relevant documents: 

/1/ GA BlueEdit user manual 

/2/ GA MCAD-S mod 1 technical description 

/3/ GA MCADA-S mod 1 technical description 

/4/ GA MCDIN-S mod 1 technical description 

/5/ GA MCDOT-S mod 1 technical description 

/6/ GA MPU-M1 technical description 

/7/ GA SR-01-42-24-00 technical description 

/8/ GA SCM1 technical description 

/9/ GA BlueLine safety system checklists 

Date 

GA BlueLine safety systems - safety manual Rev00.01 24.01.2011.doc page 2 of 50 

23.07.2009 

24.01.2011

Contents 

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

1.1 CONTACT INFORMATION...................................................................................................................... 6 

1.2 DOCUMENT SCOPE, APPLIED STANDARDS ............................................................................................ 7 

1.3 GENERAL STATEMENTS........................................................................................................................ 9 

1.4 DOCUMENT MAP ................................................................................................................................10 

1.4.1 Essential documents..................................................................................................................... 10 

1.4.2 Software documents ..................................................................................................................... 10 

1.4.3 Hardware documents ................................................................................................................... 10 

2 SAFETY LIFECYCLE ............................................................................................................................ 11 

3 PRODUCT OVERVIEW......................................................................................................................... 13 

3.1 GA BLUELINE SAFETY SYSTEMS, CONCEPT ....................................................................................... 13 

3.1.1 GA MCU processor concept ........................................................................................................13 

3.1.2 GA BlueLine safety concept ......................................................................................................... 14 

3.1.3 Field signal handling ................................................................................................................... 16 

3.2 SYSTEM INTEGRATION ....................................................................................................................... 18 

3.3 HARDWARE COMPONENTS ................................................................................................................. 19 

3.4 DIAGNOSTIC COVERAGE .................................................................................................................... 19 

3.5 ERROR RESPONSE............................................................................................................................... 19 

3.6 FUNCTIONAL AND DISPLAY ELEMENTS OF HARDWARE COMPONENTS ................................................ 21 

3.6.1 Elements of MCxxx-S cards.......................................................................................................... 21 

3.6.2 Elements of ICU and MPU-M1 cards .......................................................................................... 22 

3.6.3 Elements of DSPVCU cards......................................................................................................... 23 

3.6.4 Elements of cooling fan................................................................................................................ 23 

3.6.5 Elements of the safety relay GA SR-01-42-24-00......................................................................... 24 

3.6.6 Elements of DFAB-1oo2D external hardware voter .................................................................... 24 

3.6.7 Elements of TFAB DIGIO 2oo3 ................................................................................................... 25 

3.6.8 Elements of the GA SCM1 current measurement module ............................................................ 26 

3.7 SAFETY TIME AND REACTION TIME .................................................................................................... 26 

3.7.1 System reaction time .................................................................................................................... 26 

3.7.2 Diagnostic test interval ................................................................................................................ 27 

3.7.3 Process safety time....................................................................................................................... 27 

3.7.4 Proof test interval......................................................................................................................... 27 

4 PES SYSTEM ENGINEERING.............................................................................................................. 28 

4.1 HARDWARE ENGINEERING................................................................................................................. 28 

4.1.1 Specification of safety requirements............................................................................................. 28 

4.1.2 Hardware design and validation planning................................................................................... 28 

4.1.3 System integration........................................................................................................................ 28 

4.1.4 Hardware engineering, check list ................................................................................................29 

4.2 SOFTWARE ENGINEERING .................................................................................................................. 29 

4.2.1 Specification of safety requirements............................................................................................. 29 

4.2.2 Software design and validation planning..................................................................................... 29 

4.2.3 SIL3-approved function blocks..................................................................................................... 30 

4.2.4 Integration of PES hardware and software.................................................................................. 30 

4.2.5 Software validation ...................................................................................................................... 30 

4.2.6 Software engineering, check list................................................................................................... 31 

5 ASSEMBLY AND INSTALLATION..................................................................................................... 32 

5.1 QUALIFIED PERSONNEL...................................................................................................................... 32 

5.2 SAFETY-RELEVANT RESTRICTIONS OF USE ......................................................................................... 32 

5.3 MOUNTING AND CONNECTING ........................................................................................................... 32 

5.4 ASSEMBLY AND INSTALLATION, CHECK LIST ..................................................................................... 33 

6 FORCING I/O SIGNALS........................................................................................................................ 34 

6.1 PROCEDURE ....................................................................................................................................... 34 

6.2 FORCING I/O SIGNALS, CHECK LIST .................................................................................................... 34 

GA BlueLine safety systems - safety manual Rev00.01 24.01.2011.doc page 3 of 50

7 COMMISSIONING ................................................................................................................................. 35 


7.2 COMMISSIONING PROCEDURES .......................................................................................................... 35 

7.3 APPLICATION SOFTWARE MODIFICATION........................................................................................... 36 

7.3.1 Program modifications................................................................................................................. 36 

7.3.2 Parameter modification................................................................................................................ 36 

7.3.3 Online modification...................................................................................................................... 36 

7.4 COMMISSIONING, CHECK LIST............................................................................................................ 37 

8 MAINTENANCE ..................................................................................................................................... 38 


8.2 MAINTENANCE PROCEDURES............................................................................................................. 38 

8.3 REPLACEMENT OF COMPONENTS........................................................................................................ 39 

8.4 MAINTENANCE, CHECK LIST .............................................................................................................. 39 

9 ACCESS AUTHORIZATION................................................................................................................. 41 

9.1 USER LOGIN....................................................................................................................................... 41 

9.2 KEY SWITCH FOR OPERATING MODE .................................................................................................. 41 

10 DIAGNOSTIC INFORMATION............................................................................................................ 43 

10.1 DIAGNOSTIC DATA............................................................................................................................. 43 

10.2 PROCESS DATA................................................................................................................................... 43 

10.3 ANALYZING ERROR MESSAGES .......................................................................................................... 44 

11 COMMON TECHNICAL DATA ...........................................................................................................45 

12 SAFETY SPECIFIC DATA .................................................................................................................... 46 

12.1 SYMBOLS AND ABBREVIATIONS......................................................................................................... 46 

12.2 CHARACTERISTIC SAFETY VALUES..................................................................................................... 47 

12.2.1 GA BlueLine: Probability of Failure data............................................................................... 47 

12.2.2 SIL example GA DUPLEX-S ................................................................................................... 48 

12.2.3 SIL example GA DualCore-S................................................................................................... 49 

13 INDEX ....................................................................................................................................................... 50 

List of warnings 

Warning 1.................................................................................................................................. 9 

Warning 2.................................................................................................................................. 9 

Warning 3................................................................................................................................ 32 

Warning 4................................................................................................................................ 34 

Warning 5................................................................................................................................ 36 

Warning 6................................................................................................................................ 36 

Warning 7................................................................................................................................ 39 

Warning 8................................................................................................................................ 41 

Warning 9................................................................................................................................ 42 


List of figures 

Figure 1: overall safety lifecycle............................................................................................. 11 

Figure 2: hardware safety lifecycle ......................................................................................... 12 

Figure 3: software safety lifecycle .......................................................................................... 12 

Figure 4: MCU processor concept, with single-card configuration........................................ 13 

Figure 5: GA BlueLine concept, with single-card configuration............................................ 14 

Figure 6: GA BlueLine concept, DUPLEX-S configuration .................................................. 15 

Figure 7: GA BlueLine system schematic............................................................................... 16 

Figure 8: software voting, GA DUPLEX-S example.............................................................. 17 

Figure 9: Example for network integration............................................................................. 18 

Figure 10: front panel and elements of MCxxx-S cards ......................................................... 21 

Figure 11: front panel and elements of ICU and MPU-M1 cards........................................... 22 

Figure 12: front panel and elements of DSPVCU card........................................................... 23 

Figure 13: front panel and elements of cooling fan ................................................................ 23 

Figure 14: GA SR-01-42-24-00 relay voter, 1oo2 .................................................................. 24 

Figure 15: DFAB-1oo2D majority voter................................................................................. 24 

Figure 16: TFAB DIGIO 2oo3 majority voter........................................................................ 25 

Figure 17: GA SCM1 output current monitoring module....................................................... 26 

Figure 18: user login ............................................................................................................... 41 

Figure 19: key switch Running/Maintenance.......................................................................... 41 

Figure 20: Reliability block diagram, 1-out-of-2D example................................................... 48 

Figure 21: Reliability block diagram, GA DualCore-S........................................................... 49 

List of tables 

Table 1: check list hardware engineering................................................................................ 29 

Table 2: check list software engineering, system integration ................................................. 31 

Table 3: check list software engineering, programming......................................................... 31 

Table 4: check list software engineering, validation............................................................... 31 

Table 5: check list assembly and installation.......................................................................... 33 

Table 6: check list forcing i/o signals...................................................................................... 34 

Table 7: check list commissioning.......................................................................................... 37 

Table 8: check list commissioning, program modification..................................................... 37 

Table 9: check list maintenance, exchanging cards ................................................................ 40 

Table 10: Probability of failure, externally redundant cards................................................... 47 

Table 11: Probability of failure, internally redundant cards ................................................... 47 

Table 12: Probability of failure, external hardware voter ....................................................... 47 


1 Introduction 

1.1 Contact information 

GEBHARDT Automation GmbH 

Thüngenfeld 3 

D- 58256 Ennepetal 

Germany 

Tel.: +49 2333 7908 - 0 

available during working hours, Mo to Fr, from 8 00 to 17 00 (5 pm) 

central european time (CET, GMT+1). 

FAX: +49 2333 7908 - 24 

Web: www.gebhardt-automation.de 

Support support@gebhardt-automation.de 

Information info@gebhardt-automation.de 


1.2 Document scope, applied standards 

This document applies to the following products: 

• components based on the GA BlueLine concept 

• systems build with GA BlueLine components 

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 

Certificate and test report No. 968/EZ 351.01/11 

Programmable electronic safety systems 

GA BlueLine safety system 

GEBHARDT Automation GmbH is entitled to use the above mark of conformity for “Functional 

Safety” with its SIL3 certified safety systems. 

The systems are designed in accordance with following standards. All important, safety relevant 

features are tested according to: 

• IEC 61508 Part 1 – 7: 2010 

Functional safety of programmable electronic systems 

• EN 50156-1: 2004 

Electrical Equipment for Furnaces 

• IEC 61511-1: 2004 

Functional safety - Safety instrumented systems for the process industry sector 

• NFPA 72: 2010 

National Fire Alarm Code Handbook 

• NFPA 85: 2007 

Boiler and Combustion Systems Hazards Code 

• NFPA 86: 2007 

Standard for Ovens and Furnaces 

• EN 54-2: 1997 + AC: 1999 +A1: 2006 

Fire Detection and Fire Alarm Systems Control and Indicating Equipment 

• EN 298: 2003 

Automatic gas burner control systems for gas burners and gas burning appliances 

with or without fans 

• EN 62061: 2005 /Corrigendum 1: 2005 / Corrigendum 2: 2008 

Safety of machinery – Functional safety of safety-related electrical, electronic and 

programmable electronic control systems 


• EN ISO 13849-1: 2008 + AC: 2009 

Safety of machinery, Safety-related parts of control systems, 

Part 1: General principles for design 

• DIN EN 954-1: 1996 

Safety of Machinery, Safety related parts of control systems 

Part 1: General principles for design 

• EN 60204-1: 2006 (in extracts) 

Safety of machinery – Electrical equipment of machines, 

Part 1: general requirements 

• IEC 61131-2: 2007 

Programmable controllers, Part 2: Equipment requirements and tests 

• IEC 61326-3-1: 2008 

Electrical equipment for measurement, control and laboratory use – EMC requirements 

Part 3-1: Immunity requirements for safety-related systems and for equipment intended 

to perform safety-related functions (functional safety) – General industrial 

applications 

• DIN EN 50155: 2008 

Railway applications - Electronic equipment used in rolling stock 

German version EN 50155: 2007 

• DIN EN 61373: 1998-1 

Railway applications – Rolling stock equipment – Shock and vibration tests 

• DIN EN 50178: 1998 

Electronic equipment for use in power installations 


1.3 General statements 

All technical data and information in this document were compiled and controlled with utmost 

care. Nevertheless errors can not completely be excluded. GEBHARDT Automation 

GmbH assumes no liability for consequences due to incorrect information. 

The systems based on the GA BlueLine concept are designed, manufactured and tested according 

to applicable safety standards. They must be used only as specified in technical descriptions 

and be connected only to approved external devices. The permissible ambient conditions 

must be adhered to. 

Modification is strictly prohibited. Use only approved replacement parts for repair and maintenance. 

Warning 1 

Accurate implementation of all safety instructions by qualified personnel is required 

for every phase of the life cycle, especially installation, commissioning, operating 

and maintenance of GA BlueLine systems. 

Disregard of the safety manual and referenced documents may compromise the performance 

of safety functions and cause the loss of a required safety integrity level (SIL or PL). It may 

lead to severe damage to property or environment and death of personnel. 

Warning 2 

Unqualified use or handling of the systems may impair the performance of safety 

functions and may lead to severe damage to property or environment and death of 

personnel. GEBHARDT Automation shall have neither liability nor responsibility 

for improper use of equipment. 

It is strictly prohibited to reproduce the software for GA BlueLine systems except for the 

purpose of backup. 

Any reverse engineering, such as reverse compilation or disassembling of the software is 

strictly prohibited. 

The GEBHARDT Automation products mentioned in this document may be registered 

trademarks. 

All other company and product names mentioned in this document are trademarks or registered 

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, without 

notice or obligation. 

All rights reserved. 


1.4 Document map 

1.4.1 Essential documents 

- GA BlueLine safety systems – safety manual 

- GA BlueLine safety systems – installation manual 

- TÜV Revision Release List 

1.4.2 Software documents 

- GA BlueEdit – user manual: manual for engineering tool 

- GA BlueEdit – Online Help 

1.4.3 Hardware documents 

I/O modules 

- GA MCAD-S mod. 1 – technical description 

- GA MCDIN-S mod. 1 – technical description 

- GA MCDOT-S mod. 1 – technical description 

- GA MCADA-S mod. 1 – technical description 

CPU and Communication modules 

- GA ICU mod. 1 – technical description 

- GA ICU mod. 2 – technical description 

- GA MPU-M1 – technical description 

Other rack-internal modules 

- GA FPR mod. 3 – technical description 

- GA DSPVCU – technical description 

Field output modules 

- GA SR-01-42-24-00 – technical description 

- GA DFAB-1oo2D – technical description 

- GA TFAB-DIGIO-2oo3 – technical description 

- GA SCM1 – technical description 

Safety system racks 

- GA DualCore-S racks – technical description 

- GA COMPACT-FS1 rack – technical description 

- GA DUPLEX-S racks – technical description 

- GA TMR-S racks – technical description 


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. 

Overall 

operation and 

maintenance 

planning 

Overall planning 

Overall 

safety 

validation 

planning 

6 7 8 

Overall 

installation and 

commissioning 

planning 

1 

2 

3 

4 

5 

12 

13 

Concept 

Overall scope 

definition 

Hazard and risk 

analysis 

Overall safety 

requirements 

Safety requirements 

allocation 

Overall installation 

and commissioning 

Overall safety 

validation 

Overall operation, 

14 maintenance and repairr 

16 

9 

Safety-related 

Systems: 

E/E/PES 

Realisation 

(see E/E/PES 

safety 

lifecycle) 

Decommissioning 

or disposal 

10 

Figure 1: overall safety lifecycle 

Safety-related 

systems: 

other technology 

15 

Realisation 

Overall modification 

and retrofit 

11 

External risk 

reduction 

facilities 

Realisation 

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 facilities, 

i.e. escape routes or protective barriers) are not relevant for the scope of this document. 


9.2 

E/E/PES safety 

validation planning 

9.1 

9.1.1 

Safety functions 

requirements 

specification 

9.3 

9.4 

9.6 

E/E/PES safety requirements 

specification 

9.1.2 

E/E/PES design 

and development 

E/E/PES integration 

E/E/PES 

safety validation 

Safety integrity 

requirements 

specification 

to box 12 in 

overall safety lifecycle 

9.5 

Figure 2: hardware safety lifecycle 

E/E/PES operation and 

maintenance 

procedures 

to box 14 in 


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.2 

Software safety 

validation planning 

9.1 

9.1.1 

Safety functions 

requirements 

specification 

9.3 

9.4 

9.6 


requirements specification 

9.1.2 

Software design 

and development 

PE integration 

(hardware/software) 


validation 

Safety integrity 

requirements 

specification 

to box 12 in 


9.5 

Figure 3: software safety lifecycle 

Software operation and 

modification procedures 

to box 14 in 


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 GA BlueLine safety systems, concept 

Basically the GA BlueLine safety systems support two very similar working concepts: 

1. the GA MCU processor concept, using smart i/o cards without a dedicated processor 

card 

2. the GA BlueLine concept, with dedicated processor card and safe Ethernet communication. 

Both concepts use identical components and achieve SIL3 safety integrity. The BlueLine 

concept is an extension of the previously certified “GA MCU SafetyCore” concept, introducing 

the dedicated, internally redundant MPU-M1 processor and communication card (Multi 

Processor Unit). 

In addition to safety functions the systems can also handle regular control functions. For 

functions not safety-related the systems support regular i/o cards that are certified not to interfere 

in safety functions. See the list of certified components. 

3.1.1 GA MCU processor concept 

The GA MCU processor concept is based on MCU-S (Micro Controller Unit for Safety) 

cards: 

“smart” i/o cards with integrated micro controller units. The system architecture of each card 

is consistently dual redundant with hardware fault tolerance HFT = 1. Redundant micro controllers 

– MCU-A and MCU-B – access the card’s i/o signals, handle signal diagnostics, continuously 

monitor each other for correct operation and run the application software. 

The MCU-S cards are passively connected to the data bus. A communication controller card 

(ICU) actively reads data packages from each MCU-S input card (type MCAD-S and 

MCADA-S for analog, MCDIN-S for digital input) and sends them to the output cards (type 

MCADA-S for analog input and output, MCDOT-S for digital output). The output cards use 

the input data to calculate their field output signals according to the application software. 

For SIL3 output signals an external hardware voter module may be used to create the combined 

field output signal. 

Figure 4: MCU processor concept, with single-card configuration 


Figure 4 shows the minimal system configuration GA DualCore-S, a SIL3 application with a 

hardware fault tolerance of HFT = 1. 

• Two MCU processors on one input card read input signals from redundant sensors 

A and B. Depending on card type each MCU can typically read up to 12 input signals. 

• Field signal diagnostics and card-internal diagnostics verify the signal quality. 

• The input signals are transmitted via data bus, consisting of the physical bus connection 

and a communication controller card, ICU. 

• The data is received by one output card, also with redundant MCU processors. 

Each MCU processes both sensor signals according to the application software, 

compares its result with the other MCU and separately sets its output signal(s) to 

the required ON/OFF state. 

• An external hardware voter – basically two relays in serial – combines the output 

signals into one 1oo2 field signal. Forcibly guided read-back contacts of the relays 

allow separate error diagnostics for each relay. 

To improve process availability, redundant input and/or output cards may be used. In that 

case two or three i/o cards are used instead of the single, internally-redundant card shown in 

Figure 4. In multi-card configuration the systems use 1oo2D or 2oo3 voting, so in case of 

failure the failed component may be replaced, without a shut-down of the process. The system 

can safely operate with failed components, because even if any card completely fails the 

remaining card still has an internal hardware fault tolerance of HFT = 1. See Figure 6 as an 

example for multi-card configuration. 

For less SIL-demanding applications the input signals may be used non-redundant. Then all 

(typically 24) input signals will be available for field signals. See technical manuals of i/o 

cards for more information. 

3.1.2 GA BlueLine safety concept 

The GA BlueLine safety concept uses almost the same components. Only the ICU communication 

card is replaced by the MPU-M1 processor and communication card. 

Figure 5: GA BlueLine concept, with single-card configuration 

The application software runs directly on the MPU-M1 processor card, allowing faster and 

larger applications. The i/o cards only handle the signal diagnostics and internal diagnostics. 

The MPU-M1 cards also support safe Ethernet communication for exchange of safety-related 

data. 


A GA DualCore-S system as shown in Figure 5 meets SIL3 requirements, using its internal 

redundancy. By combining multiple units in on rack (GA DUPLEX-S or GA TMR-S) the 

fault tolerance and availability may be improved. 

When using the GA DualCore-S or GA COMPACT-FS1 racks, multiple racks can be combined 

into a redundant system via Ethernet communication. This allows up to quadruple redundancy 

Figure 6: GA BlueLine concept, DUPLEX-S configuration 

Figure 6 shows a dual-redundant configuration, either in a GA DUPLEX-S rack or in two 

separate racks via Ethernet. The main difference is the complete card redundancy. Basically 

two identical systems, unit A and unit B, are combined via redundant data bus into a duplex 

redundant system. The card-internal redundant handling of input signals as in DualCore-S 

configuration is not required, since the complete cards are redundant. The internal signal handling 

and processing of application software is quadruple redundant, by two micro controllers 

MCU-A and MCU-B on each unit A and B. 

The external voter combines the separate output signals into field outputs. Because four 

MCUs control each output signal and do signal diagnostics, even at detected failure of one 

output the system may continue operation. This results in a 1-out-of-2-D voting, where a 

failed component may be replaced while the system continues working. 1oo2D voting requires 

voter hardware specifically designed to support extended diagnostics. Simple 1oo2 

voting is possible with standard relay outputs. 

For triple redundancy, GA TMR-S, three identical systems (unit A, B and C) are combined, 

typically with an external hardware 2oo3 voter. Each relevant component exists in triplicate; 

internal signal processing actually is six-times redundant. The 2oo3 output selection allows 

replacing of any component while the system continues working. 


3.1.3 Field signal handling 

Figure 7: GA BlueLine system schematic 

Voting on input signals: 

To increase system availability regarding input signals, it is recommended to activate input 

voting. This will take redundant input signals and combine them into one common signal for 

use on all output cards. With detected error at one input signal the common signal will be 

degraded (e.g. 2oo3 degrades to 1oo2D, 1oo2D degrades to 1oo1D), but the same common 

signal will still be available to all output cards. 

Without input voting each unit works with its own input signal only, so if input channel 1 

fails on unit A, the output card in unit A would see the failed signal only and would set the 

output signal to the safe state OFF. 

The settings for input signal voting depend on the system architecture, see GA BlueEdit user 

manual for more information). 

Voting will also allow deviation detection for analog input signals. The tolerable deviation is 

configured separately for each signal. See GA BlueEdit user manual, AIN function, for more 

information). 

Analog output signals 

MCADA-S cards have access to all signals generated by input cards, field signals and preprocessed 

signals. Two MCUs on every card execute the application software, working redundantly 

to determine the output signals to hardware. Every MCU sets its output signals to 

the field. For each output channel there is a channel to read-back the signal information from 

the field. In case of a read-back failure the relevant output or all outputs (depending on the 

fault reaction) are set to the safe state 0.0 mA. There are independent shut-down paths for the 

current generation and the connection to the field. Via these shut-down paths a MCADA-S 

can always set the outputs to the safe power-off state. 

If MCADA-S cards are configured in multiple-card redundancy, i.e. in GA DUPLEX-S systems, 

only one card is active at any time. The other card(s) are hot-standby. 

Voting on digital output signals, using external hardware voter relays: 

Each output card does redundant signal processing, using micro-controllers MCU-A and 

MCU-B. The separate output signals of both MCUs are compared as 1-out-of-2, to guarantee 

correct working of the output card. At failure the card diagnostics will detect a card failure. 


The signal and relay states can be read back as analog signals to allow output diagnostics. In 

case of relay failure (for example: relay is “stuck at one”) a secondary, independent shutdown 

path allows de-energizing to the safe state. 

Voting on digital output signals, using software voting: 

A flexible alternative to voting with external hardware voting relays is software voting. Via 

data bus communication (internal data bus or Ethernet safety communication) the application 

software handles M-out-of-N voting. The desired result is available on all output cards configured 

as a redundant group (multi-card configuration, or a single MCDOT-S output card). 

The two MCU processors on one output card set the “field output” signals and a “system active” 

signal. All other cards of the output group are hot-standby, their “field outputs” and 

“system active” is “off”. 

If one of the two processors on the active card detects a read-back failure the card will deactivate 

and a standby card takes over immediately (less than 5 msec switch-over). 

Figure 8: software voting, GA DUPLEX-S example 

This consistent software voting concept is available for all GA BlueLine systems. It achieves 

SIL3 safety integrity with a single output card. Additional cards improve the system availability 

with hot-standby functionality. A failed card can be replaced without stopping the 

system. 


3.2 System integration 

Figure 9: Example for network integration 

A safety project usually consists of at least one PES system (GA COMPACT-FS1, GA DualCore-S, 

GA DUPLEX-S or GA TMR-S), one engineering station and one visualization 

system (DCS, distributed control system). The PES system autonomously handles the safetyrelevant 

functions. During normal operation, in “running mode”, no unsafe system (regular 

control, Engineering, DCS) can interfere with 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 safety systems is available via redundant 

Ethernet communication with SIL3 integrity, using the SIL3 certified MPU-M1 communication 

and processor card. 

Engineering system is a PC, running Windows (2000 or XP) and the integrated development 

tool GA BlueEdit. After the activation of maintenance mode this system may be used for 

commissioning and maintenance of GA safety 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 visualization system (DCS) accesses i/o data and system information via read access 

using open communication protocols. Write access from DCS to the PES system must not 

interfere with safety functions, e.g. interlocking a safe shut-down function with a DCS command 

is not allowed. In addition to process values the DCS communication also allows access 

to diagnostic information, for visualization, data logging and trending. 

Figure 9 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 visualization 

may be designed dual or triple redundant, depending on the communication capabilities 

of the safety system. In case of network failure this guarantees undisturbed communication 

to the remaining components. Engineering system and DCS must be configured with 

independent network cards. 

The right figure shows a simple, non-redundant, network. All systems use the same network. 

In case of network failure the complete communication may be lost. 


Safety functions and safety integrity are not influenced by a single network failure. Even at 

complete network failure the systems will continue normal operation, if no safety-related 

communication is required. 

Networks according to Figure 9 may be extended with further systems of all types (PES, control, 

DCS, Engineering). The same network may also include other, not safety-related systems. 

3.3 Hardware components 

Only hardware components registered in the revision-list of tested and certified components 

shall be used in GA BlueLine safety systems. 

See Revision Release List. 

3.4 Diagnostic coverage 

Multiple build in tests (BITs) implemented in the card firmware allow very high diagnostic 

coverage. BITs include power-on tests (run once during start up), cyclic tests (run repeatedly 

at fixed time intervals during normal operation) and dynamic tests (i.e. field signal tests or 

internal communication). BITs monitor the micro-controllers, the acquisition of field signals, 

internal and external memory, the safety application software and communication between 

modules and units. See GA safeEdit user manual and GA technical description. 

Safety related configuration of diagnostic coverage 

Activation/de-activation of input signal monitoring: 

Used signals – digital and analog – are monitored for signal range to detect failures of sensor, 

transmitter or cable. This failure detection also allows 1oo2D signal handling, continued operation 

with one detected failure on two redundant input signals. 

Signal diagnostics on spare input signals should be de-activated. Unused signals will have a 

fail-safe state (“low” for digital, 0.0 mA for analog, see GA technical description MCxxx-S ). 

Test interval for field signal tests: 

Execution and time interval of field signal tests can be configured during project engineering 

only by GEBHARDT Automation GmbH. These settings influence safety integrity (i.e. repair 

time MTTR) and are password protected. See GA technical description MCxxx-S for details. 

If there is no specific agreement with the customer, default settings will be used. 

Analog input diagnostics on MCAD-S card: 

The thresholds for over-range and under-range of current and frequency input signals are 

configurable. At each signal access these ranges are checked for failure. 

3.5 Error response 

Detected errors are displayed using the front side diagnostic LEDs on every MCxxx-S card. 

See technical description for the specific cards. 

Detected errors on input cards will set the state of affected signals to “faulty”. Only after repair 

and acknowledge the state will return to “okay”. The optional software input signal voting 

will be degraded, e.g. from 1oo2D to 1oo1D, until the repair is finished and acknowledged. 


Detected errors on MCDOT-S output cards will immediately turn off the affected card or 

signal (de-energize to trip). Repairs can usually be performed by experienced personnel in a 

relatively short time (see MTTR, mean time to repair), while the system continues running 

with reduced hardware fault tolerance. 

In DualCore-S systems a detected error on a MCDOT-S output card will cause a shut-down if 

the card is configured for single-card operation. In multiple-card operation a redundant card 

will take over and the failed card can be replaced while the system keeps working. 

When redundant units reach different states without being able to assign any error, all outputs 

of the affected MCDOT-S cards will turn to “low” and the corresponding field contacts will 

open. 

Detected errors on outputs of the MCADA-S input/output cards will immediately turn off the 

affected signal or card (0 mA to trip), depending on the fault reaction. If a redundant card is 

available the system will continue operation and the failed card can be replaced. 

Detected errors on inputs of the MCADA-S output cards will set the state of affected signals 

to “faulty”. The status of input and output signals will return to “okay” either manually after 

repair and acknowledge of the failure or automatically, according to the card configuration. 


3.6 Functional and display elements of hardware components 

3.6.1 Elements of MCxxx-S cards 

All i/o cards use identical functional elements and display LEDs at the front panel. Figure 10 

shows diagnostic LEDs and ejection lever. 

Figure 10: 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 interference 

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.6.2 Elements of ICU and MPU-M1 cards 

The mechanical parts with ejection lever, module rail and guiding pin are identical to 

MCxxx-S cards. See Figure 10 and description. 

Figure 11: front panel and elements of ICU and MPU-M1 cards 

There are two models of ICU card available: ICU model 1 and ICU model 2. Model 1 comes 

with optional extensions for additional communication ports. Model 2 uses a high speed 

processor, has redundant Ethernet ports and a larger FLASH memory capacity for process 

data logging. 

The front plates of all ICU variants use LEDs to display status information. 

• Ethernet Link/Act: LED shows physical connection and network activity. 

Normal state: flashing 

• Ethernet 100 or Spd: indicates speed of communication, 10/100 or 100/1000 MBit. 

Normal state: static ON for high speed 

• MA: green LED indicates correct functionality of ICU as bus master. During system 

start up the LED is off. 

Normal state: static green 

• WDG: red LED indicates Watchdog error. 

Normal state: always off 

For details see technical description of the specific ICU model. 

The MPU-M1 card allows 2 Ethernet connections for each processor A and B, using standard 

RJ45 Ethernet connectors. The fifth connector is used for redundant serial RS-232 communication, 

one port to each processor. A special adapter plug is required. 

The front plate uses LEDs to display status information: 

• Ethernet Link/Act: LED shows physical connection and network activity. 

Normal state: flashing 


• RUN CPU A/B: green LED indicates correct functionality of each processor. 


• ERR CPU A/B: red LED indicates processor error. 

Normal state: always off 

• DSP BUS ON: green LED indicates correct functionality as bus master. 


For details see technical description of the MPU-M1 card. 

3.6.3 Elements of DSPVCU cards 

Figure 12: front panel and elements of DSPVCU card 

The DSPVCU voltage control cards are independent control cards for monitoring the secondary 

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 operation. 

See technical description for further details. 

3.6.4 Elements of cooling fan 

Figure 13: front panel and elements of cooling fan 


LEDs in the front panel show the operating mode. Normal state is green LED on and red 

(alarm) LED off. A fan malfunction, e.g. mechanical jamming, activates the red “alarm” 

LED. Pressing the reset button after correcting the problem acknowledges the fan alarm and 

turns the LED off. 

The central area indicates the rack type, here “GA DualCore-S” . 

Loosening of two retaining screws in the front panel allows removal and replacement of the 

cooling fan during normal operation. 

Fan malfunction has no direct impact on the safety system. It may lead to over-temperature of 

the complete system or individual components. 

3.6.5 Elements of the safety relay GA SR-01-42-24-00 

Figure 14: GA SR-01-42-24-00 relay voter, 1oo2 

The GA SR-01-42-24-00 safety relay module is designed for safe shut-down of control circuits. 

It is based on two different safety relays, by different manufacturers for diversity. Each 

relay switches four closing contacts for field signals in an internal 1-out-of-2 selection and 

additional opening contacts for messaging and diagnostics. All contacts are forcibly guided. 

Each closing contact circuit is protected by a build-in fuse, to prevent welding due to overcurrent. 

The fuses are accessible at the front, for easy replacement. 

Two LEDs, K1 and K2, at the front plate show the individual state of both safety relays. 

3.6.6 Elements of DFAB-1oo2D external hardware voter 

Figure 15: DFAB-1oo2D majority voter 


The duplex field assembly board DFAB-1oo2D uses three LEDs to indicate the state of the 

redundant external power supplies. Two fuses at the upper left corner must be in the “pushed 

in” position. The LED below each fuse shows the state of that supply voltage. The central 

LED, between connector plugs and relays, shows that at least one supply voltage is available 

and the board is working. 

Four relays per signal create the 1oo2D field signals. Usually all relays are in the same position 

(ON/OFF). The two “worker” relays from system A and B and the “diagnostic” relays 

should always have the same position. In case of a detected failure the “diagnostic” relay is 

used to de-couple systems A and B. During self-tests (walking change) one system is decoupled 

and tested (position changed to the opposite state), while the remaining system holds 

the field signal. 

The DFAB is designed with forcibly guided safety relays, using the “de-energize to trip” 

principle. 

3.6.7 Elements of TFAB DIGIO 2oo3 

Figure 16: 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. Usually 

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 forcibly guided safety relays, using the “de-energize to trip” principle. 


3.6.8 Elements of the GA SCM1 current measurement module 

Figure 17: GA SCM1 output current monitoring module 

The SCM1 (Safety Current Measurement) module measures the current flowing to field elements 

and converts it into two redundant, proportional 4…20 mA current signals. These signals 

can be read with analogue input cards and are used to compare the actual field current to 

the expected value. 

In case of component failure the SCM1 module can not create dangerous field currents. 

Two green LEDs “Power okay 1” and “Power okay 2” show the operating state of both measurements. 

Two yellow LEDs “Open 1” and “Open2” indicate open cable on the secondary 

side, between SCM1 module and analog input module. 

3.7 Safety time and reaction time 

3.7.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 control 

functions handled by one MPU-M1, MCDOT-S or MCADA-S processor card. 

For details on program cycle time see GA BlueEdit user manual. 

The reaction time is calculated as: cycle time of processor card + i/o cycle time + internal 

communication time + 15 msec relay switching. 

Exceptions from this time may occur when: 

• safety functions are distributed over multiple MCDOT-S or MCADA-S output cards 

• communication between GA safety racks is used for the safety function 

• frequency signals at low frequency: see MCAD-S technical description 


3.7.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 failure 

below or equal to the target failure measure defined in safety integrity specifications. 

All systems based on GA BlueLine components use a consistent hardware fault tolerance of 

at least HFT = 1, so the diagnostic test interval doesn’t significantly affect the system reaction 

time. It is specified in system firmware and should not be modified by the user. 

3.7.3 Process safety time 

The process safety time is the interval between occurrence of a disorder (at machine or process, 

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 compliance. 

The diagnostic test interval is doesn’t significantly affect the calculation, see above. 

3.7.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 default time interval between proof tests is 10 years. 

Shortening the test interval will improve the probability of system failure. Typical intervals 

are 5 years or 3 years. The proof test interval may also be extended, up to 20 years. 

When frequency signals are used for safety functions, the calibration of frequency inputs 

must be considered to determine the proof test interval, see MCAD-S technical description. 


4 PES system engineering 

Planning, design and realization of the PES system are implemented according to box 9 

“safety-related systems: E/E/PES” in Figure 1: overall safety lifecycle on page 11. 

Figure 2: hardware and Figure 3: 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 

handle these requirements. The number and type of PES systems, including system architecture 

and 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 loop (input signals, control 

and output signals) is designed. All input signals should be accessed by cards in 

the same system, all outputs should be handled on the same output card MCDOT-S 

or MCADA-S. 

Segmentation of safety loops to multiple PES systems is admissible, but should be 

avoided when possible. Affected loops require special attention in validation planning, 

specifically considering system reaction time. 

• If no dedicated processor card MPU-M1 is used, every output 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 specified 

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 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 communication. 

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

visualization (DCS) 

• Network layout for engineering and visualization, including redundancy and address 

configuration. 


4.1.4 Hardware engineering, check list 

No. Description Check 

1 Correct system architecture selected to meet requirements regarding process 

safety and process availability? 

2 Number of i/o cards according to safety functions, including spare signals? 

3 Slot position of i/o cards according to system design specification? 

4 Analog frequency inputs with correct cut-off frequency? 

5 Appropriate distribution of safety functions over MCDOT-S and 

MCADA-S cards with regard to output signals? 

6 correct external voter hardware for safety and availability requirements? 

7 safety-relevant communication between PES systems: acceptable system 

reaction time? 

8 Connecting cables: correct cable type and length? 

9 Network layout: distance, cable length, cable type (copper, optical), 

switches, routers, redundancy, addressing 

Table 1: check list hardware engineering 

See also GA BlueLine safety system checklists for additional information. 

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 28 is extended with signal information on i/o signals. For each digital signal the contact 

mode (normally open, normally closed) is 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 application 

software, considering software safety specifications. For each safety function the PESinternal 

safety loop of input signal, application program and output signal is considered. 

GA BlueEdit is used as programming tool, see GA BlueEdit user manual. 

Software design considers the following measures: 

• Application programming for specific safety functions on MPU-M1, MCDOT-S or 

MCADA-S cards according to hardware design specifications. 

• Error response for signal failure specified for every input signal in every safety 

function: Mid-of-3, 1oo2, available/error, (see GA BlueEdit 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 moment of switchover. 

• 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 controller-internal 

range, with hysteresis. Documentation and validation planning. 

• Power-on behavior for safety functions, including validation. 

• Signal tracking for software functions with internal memory function (e.g. RS flip 

flop), including validation. 

4.2.3 SIL3-approved function blocks 

Most GA BlueEdit function blocks are approved for use in SIL3 safety functions. They may 

be used without restriction for application programming. The GA BlueEdit user manual supplies 

the current list of approved function blocks. 

Function blocks not listed are not approved for safety functions. They may be used for functions 

that are not safety relevant, the use in safety functions is not allowed. 

4.2.4 Integration of PES hardware and software 

PES system integration gives special attention to dependencies between hardware and software. 

An important factor is also the integration into the overall system concept, including 

PES diagnostics in regular process visualization (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, deactivation 

for spare signals, correct software configuration for the implemented hardware 

architecture (DualCore-S, DUPLEX-S, TMR-S). 

• Estimation of system reaction time of all cards running application software (MPU- 

M1, MCDOT-S and MCADA-S) and comparison to required system reaction time. 

Consider adequate reserve for software changes during commissioning. 

• Memory utilization of MPU-M1, MCDOT-S and MCADA-S cards acceptable, including 

adequate reserve for software changes during commissioning. 

• All relevant diagnostic information of PES systems should be displayed on regular 

process visualization, to inform about critical states or system degradation and allow 

sufficient time for corrective maintenance. 

4.2.5 Software validation 

Software validation uses the programming tool GA BlueEdit 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 

or 

Online debug on PES hardware, with field signals simulated by test equipment 

(usually 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.6 Software engineering, check list 


1 Hardware and software configuration corresponding 

2 Network configuration correct in hardware and software 

3 System reaction time of each MCDOT-S, MCADA-S and MPU-M1 card 

acceptable as compared to required safety times 

4 Memory utilization of MPU-M1, MCDOT-S and MCADA-S cards acceptable, 

with enough free memory for modifications during commissioning 

5 Signal error detection cable failure/short cut active for used signals, inactive 

for spare signals 

6 Access to all necessary diagnostic information specified and/or programmed 

for process visualization (DCS) 

7 System configuration according to project requirements 

(time-outs, time settings, internal communication, ...) 

Table 2: check list software engineering, system integration 


1 Signal states and ranges for each signal programmed according to specification? 

2 Signal behavior (Mo3, 1oo2, ...) for each signal in every safety function 

defined according to specification? 

3 Analog thresholds programmed according to specification, including scaling 

and hysteresis? 

4 Interdependencies between safety functions according to specification? 

5 Power-on behavior of safety functions according to specification? 

6 Signal tracking for software functions with internal memory (RSF, ...) 

implemented according to specification? 

7 Only SIL3-approved function blocks used in programming of safety functions? 

Table 3: check list software engineering, programming 


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 equipment, 

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 appropriately 

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 safety components 

• training in i/o signal diagnostics with programming tool GA BlueEdit may be required 

• instruction in project specific safety concept 

• training in use of appropriate safety equipment 

• training in first aid 

Warning 3 

Mistakes during assembly and installation may impair the performance of safety 

functions and cause the loss of a required safety integrity level (SIL or PL). They 

may lead to severe damage to property or environment and death of personnel. 

5.2 Safety-relevant restrictions of use 

The systems must be used only in normal environments, according to specification. They 

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 components 

and installation manuals for the specific type of system. 

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, 

keeping sufficient distance from other components. 

• Signal lines must be kept separate from power lines. All lines require tidy wiring 

and appropriate labeling. 

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 

connection to protective ground. 

• Most components include devices sensitive to electrostatic 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 replacing components. 


5.4 Assembly and installation, check list 


1 Optical check: no damage, proper mounting, proper and tidy wiring, component 

labeling 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, sometimes called maintenance override, 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 override safety functions, restricting or disabling them, so forcing may be used only 

during commissioning and maintenance, under specified operating conditions. 

The GA BlueEdit 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 analyzed 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 maintenance. 

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 system architecture (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 access to 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 analyzed and clearly understood? 

2 Are system and process requirements (e.g. operating conditions) established? 

3 Is the procedure for forcing the desired state clearly understood, including 

the system architecture and type of redundancy of affected i/o signals? 

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 


Warning 4 

Forcing of i/o signals will override the working of safety functions, endangering 

personnel, environment and property. Appropriate measures to achieve the required 

safety by other means need to be implemented! 


7 Commissioning 


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 appropriately 





• software training for the programming tool GA BlueEdit for commissioning of SIL3 

safety systems 


• instruction in project specific application software 

• experience in integration of control systems with control panel 

• instruction in machinery and processes to be controlled 



7.2 Commissioning procedures 

Commissioning uses the programming tool GA BlueEdit for programming, system configuration 

and diagnostic of hardware and software. A visualization 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 often run in maintenance mode. The commissioning 

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 partially. 

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 BlueEdit diagnostic display and in visualization. 

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 


Warning 5 

During commissioning safety functions are not or only partially available, endangering 

personnel, environment and property. Appropriate measures to achieve the 

required safety by other means need to be observed! 

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 BlueEdit. 

• Print and save new program. 

• Check for interconnections between modified safety functions and other functions, 

using graphical program editor. 

• Analyze 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 graphical 

program editor. 

• Analyze affected safety functions, including interconnected functions: 

only desired effects, no side-effects? 

• When changing range or scaling of i/o signals the communication to visualization 

system may be affected. 

• Test the new version. 

• All changes must be documented and backed-up. 

7.3.3 Online modification 

Warning 6 

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 compromise safety functions. 

Modifications with the machine running are possible but need special attention: 

• Impact analysis just like analysis for normal changes. 

• Additional impact analysis for power-on behavior. 

• Additional impact analysis of different signal states on the separate units in a redundant 

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 34. 

• During modification the safety functions are compromised. Appropriate emergency 

measures must be prepared. 

7.4 Commissioning, check list 


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, machine running. 

7a When required: program modification, see additional check list below. 

8 Check system reaction time, for each i/o and MPU-M1 card. Compare 

with process safety time. 

9 Set safe operating state: system locked, no i/o forcing active. 

Key handed over to: 

10 Data back-up of complete software and system configuration. 

date: 

copy handed over to: 

Table 7: check list commissioning 


1 Back-up old version. 

2 Modification with machine stopped or running? 

3 Planning of modifications and impact analysis, with consideration of the 

list of SIL3-approved function blocks. 

4 Appropriate safety measures and emergency measures prepared? 

5 Implementation and test of new software 

6 Check system reaction time, for each affected card. Compare with process 

safety time. 

7 Documentation of successful changes. 

8 Back-up new version. 

Table 8: check list commissioning, program modification 



8 Maintenance 


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 appropriately 





• software training for the programming tool GA BlueEdit for maintenance and diagnostics 




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 visualization in DCS, alarms, LED 

display on hardware components, extended diagnostic information on engineering 

station using GA BlueEdit 

Unscheduled maintenance becomes necessary when the safety system 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 visualization, 

hardware check (optical, LEDs, ...), extended diagnostics on engineering station. 

• 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. 


Warning 7 

Unqualified maintenance may cause the loss of a required safety integrity level 

(SIL, PL) and may compromise the performance of safety functions, leading to severe 

damage to property or environment and death of personnel. 

8.3 Replacement of components 

Replacement of components is possible during normal operation. Details are specified in 

technical descriptions of the components and systems. 

Replacement of programmable system components, MCxxx-S cards, MPU-M1 processor 

cards and ICU communication cards requires special attention: 

• Replacement of MCxxx-S, MPU-M1 or ICU cards requires use of engineering station 

with GA BlueEdit. 

• 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, analyzed 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 BlueEdit. 

• Replacing i/o cards and MPU-M1 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 checked, in systems 

with redundancy i/o signals are compared with redundant cards of other 

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 configuration. 

Additional information on configuration and programming is available in GA BlueEdit 

user manual. 

8.4 Maintenance, check list 

Checks for regular maintenance, including proof-test intervals, use project specific check 

lists. 


1 Unequivocal identification of problem: corresponding diagnostics in visualization, 

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 authorization 

9.1 User login 

Figure 18: user login 

Before using GA BlueEdit to access GA safety systems a user authorization is required. In 

“Account login” select a user name from the list of authorized users. Enter the corresponding 

password below. 

The list always has at least the user “Admin”, other user names depend on system configuration. 

The user may work within the scope of his access permissions. Modification of user authorization 

and permissions is available for “Admin” only. Users with highest priority may fully 

access diagnostics, configuration and programming of i/o cards, ICU communication cards or 

MPU-M1 processor and communication cards. 

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 BlueEdit manual. 

9.2 Key switch for operating mode 

Figure 19: 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. 

Warning 8 

Maintenance mode allows hardware access that may compromise safety functions, 

including forcing of i/o signals, programming of control processors and system configuration. 

When using appropriate safety and emergency measures, maintenance 

mode may be allowed 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. 

After successful commissioning or maintenance all forced i/o signals have to be 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 

station and communication to DCS remain available. 

Warning 9 

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. 

Affected safety functions will be compromised, endangering personnel, environment and 

property. 

Appropriate measures to achieve the required safety by other means need to be implemented! 


10 Diagnostic information 

10.1 Diagnostic data 

Self test statistics 

Authorized users can access self test statistics, stored on each MPU-M1 and MCxxx-S card. 

The information is stored in card-internal flash memory. Access via GA BlueEdit, see GA 

BlueEdit user manual. 

Log-book of system messages 

The engineering station logs all system messages (information, warnings, errors). All messages 

are displayed on screen and written to a log-book file. Each message includes time 

stamp and informational text. See chapter Analyzing error messages on page 44. 

Additionally all messages are stored in flash memory on their respective ICU card and can be 

accessed from the engineering station. 

Visualization system 

Via communication extensive diagnostic information on all i/o signals is accessible for 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 MPU-M1 processor cards and ICU communication 

cards are also accessible. 

Storage or logging of this data is available according to capabilities of the visualization system. 

10.2 Process data 

All process data is continually available to the DCS system, using communication via ICU 

communication controller or MPU-M1 processor card. 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 analyzer 

in GA BlueEdit, see GA BlueEdit user manual. 

Real-time data logging of all i/o signals, including time synchronization between several controllers, 

is optionally available on the ICU cards. 


10.3 Analyzing error messages 

The programming tool GA BlueEdit shows extensive diagnostic information. If unusual system 

behavior 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): (1,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, 16 th September 2005 at 15:57 and 52 seconds. 

The next part is the 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). DUPLEX-S systems may use two redundant networks (1) and (2), TMR-S systems may 

use three separate networks. 

The next part is the card position in the system, identified by unit number (0 = unit A, 1 = 

unit B), card slot number (1 ... 16) and processor number (0 = MCU-A, 1 = MCU-B): 

(1,13,0) identifies a card in unit B, 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 detailed 

information on error 116 check the card type in slot 13 (MCDIN-S, MCAD-S, 

MCADA-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 analyze 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, largest system 

max. power DUPLEX SMART-S, DualCore-S 300 W 

max. power COMPACT-FS1 60 W 

digital inputs, MCDIN-S 

type 0, NAMUR input 

input current according to NAMUR 

“high level” current > 2,1 mA 

“low level” current < 1,2 mA 

type 1: 24 V active or passive input 

input voltage 24 V 

high level voltage, default > 15 V, IEC61131-2 

low level voltage, default < 5 V, IEC61131-2 

type 2: 24 V passive input 

input voltage 24 V 

high level voltage, default > 11 V, IEC61131-2 

low level voltage, default < 5 V, IEC61131-2 

analog inputs, MCAD-S 

input current 0 ... 25mA 

frequency input 1 Hz ... 20 kHz 

analog inputs and outputs, MCADA-S 

input current 0 ... 25mA 

output current 0 ... 25mA 

digital outputs, MCDOT-S + output voter 

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 

DualCore-S/DUPLEX SMART-S/TMR SMART-S 

(4HE / 84TE) 

DUPLEX/7-S (7HE / 84 TE) 

TMR/10-S (10 HE / 84 TE) 

For more details see technical description of components. 

483 x 191 x 391 mm [W x H x D] 

483 x 324 x 391 mm [W x H x D] 

483 x 458 x 391 mm [W x H x D] 


12 Safety specific data 

12.1 Symbols and abbreviations 

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 = dangerous) 

λ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) 

proof test interval (in hours) 

T1 

MTTR Mean Time To Repair (in hours) 

MTTFd Mean Time To Failure, dangerous, in years. The value applies to dangerous 

failures of one channel, not the redundant system 

DC diagnostic coverage 

SFF safe failure fraction 

PFDavg average probability of failure on demand, in low demand mode 

PFHG average probability of failure per hour in system with majority voter, in high 

demand mode 

tCE average channel-related failure time (in hours) 

average system-related failure time (in hours) 

tGE 


12.2 Characteristic safety values 

The characteristic safety values for a complete safety loop are calculated as sum of the probability 

of failure for every component, modified according to system architecture. 

The probability of failure values of all components used for handling one safety function are 

added into the total probability for this specific safety function. This calculation has to be 

done for each safety function separately. 

The part of the logic solver is determined by adding failure probabilities for each component 

from the tables below. They already account for the system architecture, so the values of single 

components may simply be added to get the total value for the logic solver. 

12.2.1 GA BlueLine: Probability of Failure data 

for systems: DUPLEX-S, TMR-S, DualCore-S, COMPACT-FS1 in multi-card configuration 

externally redundant 

cards 

PFDavg 

T1 = 1y 

PFDavg 

T1 = 5y 

PFDavg 

T1 = 10y 

PFDavg 

T1 = 20y 

PFHG I/O 

MPU-M1 1.10E-06 5.00E-06 1.00E-05 2.00E-05 6.40E-09 n. a. 

MCAD-S 4.85E-07 2.43E-06 4.85E-06 9.70E-06 5.04E-09 24 AI 

MCDIN-S 3.50E-07 1.75E-06 3.50E-06 7.00E-06 3.80E-09 24 DI 

MCDOT-S 3.65E-07 1.83E-06 3.65E-06 7.30E-06 3.94E-09 8-10 DO 

MCADA-S 2.86E-07 1.43E-06 2.86E-06 5.72E-06 2.60E-09 8 AI, 8 AO 

MCADA-S IN 9.94E-08 4.97E-07 9.94E-07 1.99E-06 8.99E-10 8 AI 

MCADA-S OUT 2.32E-07 1.16E-06 2.32E-06 4.64E-06 2.10E-09 8 AO 

Table 10: Probability of failure, externally redundant cards 

for systems: DualCore-S and COMPACT-FS1 in single-card configuration 

internally redundant 

cards 

PFDavg 

T1 = 1y 

PFDavg 

T1 = 5y 

PFDavg 

T1 = 10y 

PFDavg 

T1 = 20y 

PFHG I/O 

MPU-M1 8.21E-06 3.20E-05 6.18E-05 1.22E-04 8.34E-09 n. a. 

MCAD-S 6.41E-07 3.21E-06 6.41E-06 1.28E-05 6.61E-09 12 AI 

MCDIN-S 4.64E-07 2.32E-06 4.64E-06 9.27E-06 5.01E-09 12 DI 

MCDOT-S 4.83E-07 2.41E-06 4.83E-06 9.66E-06 5.18E-09 8 DO 

MCADA-S 3.80E-07 1.90E-06 3.80E-06 7.60E-06 3.43E-09 4 AI, 4 AO 

MCADA-S IN 1.98E-07 9.92E-07 1.98E-06 3.97E-06 1.79E-09 4 AI 

MCADA-S OUT 4.62E-07 2.31E-06 4.62E-06 9.25E-06 4.18E-09 4 AO 

Table 11: Probability of failure, internally redundant cards 

external hard- PFDavg PFDavg PFDavg PFDavg PFHG I/O 

ware voter T1 = 1y T1 = 5y T1 = 10y T1 = 20y 

SR-01-42-24-00 5.59E-07 2.80E-06 5.59E-06 1.12E-05 5.05E-09 1 DO 

SCM1 5.40E-06 2.54E-05 5.06E-05 1.03E-04 1.64E-08 2x AI 

DFAB-1oo2D 1.73E-07 8.65E-07 1.73E-06 3.46E-06 1.17E-09 8 DO 

TFAB-2oo3 2.70E-07 1.35E-06 2.70E-06 5.40E-06 2.16E-09 10 DO 

Table 12: Probability of failure, external hardware voter 

All tables are based on a mean time to repair of MTTR = 24 hours. 

The safe failure fraction for a complete system is SFF > 99 %, with the exception of SCM1 

modules. SCM1 modules have a SFF = 97.65%. 

The diagnostic coverage is DC > 99%. 

All components except hardware voters are complex type B components with HFT = 1. 

Hardware voters are type A components, also with HFT = 1. 


Cards in DualCore-S or COMPECT-FS1 systems can be configured in single-card mode, 

with card-internal redundancy. This affects the handling of i/o signals and results in a higher 

probability of failure for those cards, as shown in Table 11. When the cards are configured in 

multiple-card mode – using two or three separate cards to achieve hardware fault tolerance – 

Table 10 is used for the PFD and PFH calculation. 

In DualCore-S or COMPACT-FS1 systems the processor card MPU-M1 can not be used in 

multiple-card mode. If redundant MPU-M1 cards are used they are always configured in single-card 

mode as hot-standby. 

I/O cards of type MCADA-S support analog input and output signals. If both signal types are 

used in the safety function, the values are selected from row “MCADA-S”. If only one type is 

used, the values are selected from row “MCADA-S IN” for analog input or “MCADA-S 

OUT” for analog output. 

The number of available digital output signals on MCDOT-S cards depends on the system 

architecture: 

• GA DualCore-S, card internal redundancy: 8 digital outputs, on SR-01 relay, 1oo2 

• GA DUPLEX-S, full redundancy: 8 digital outputs, on DFAB-1oo2D voter 

• GA TMR-S, full redundancy: 10 digital outputs, on TFAB-2oo3 voter 

See technical manuals for each card about additional information on the number of available 

i/o signals. 

12.2.2 SIL example GA DUPLEX-S 

Figure 20: Reliability block diagram, 1-out-of-2D example 

Figure 20 shows an example for a GA DUPLEX-S system. One set of redundant MCDIN-S 

input cards reads up to 24 digital input states. One set of MCDOT-S output cards sets up to 8 

digital outputs. One external voter DFAB-1oo2D combines those 8 redundant output signals 

into 8 field outputs. To calculate the probability of failure for a safety function that uses not 

more than these i/o signals, the probability of failure values from Table 10 are used: 

PFDavg, total = PFDavg, MCDIN-S + PFDavg, MCDOT-S + PFDavg, DFAB-1oo2D 

PFDavg, total = 8.88E-06, for T1 = 10 years 

PFHG, total = PFHG, MCDIN-S + PFHG, MCDOT-S + PFHG, DFAB-1oo2D 

PFHG, total = 8.91E-09 

PFDavg is proportional to the proof test interval T1, so the PFDavg value must be taken from 

the respective column. 

The logic solver according to the example above is suitable for use in SIL3 safety functions. 

The probability of failure in low demand mode – PFDavg, total = 8.88E-06 for T1 = 10 years – is 


elow the limit for SIL3. The probability in high demand mode – PFHG, total = 8.91E-09 – also 

is below the SIL3 limit. 

With hardware fault tolerance HFT = 1 and safe failure fraction SFF > 99.8% architectural 

constraints according to IEC 61508-2, table 2 and table 3, also allow SIL3. 

Note: The suitability of the complete safety function for the required SIL must be checked, 

since the logic solver is only a part of the complete safety loop! 

12.2.3 SIL example GA DualCore-S 

A safety function requires one (redundant) analog input, one (redundant) digital input, two 

independent digital output signals and shall meet SIL3 requirements. 

A GA DualCore-S system with internal card redundancy is chosen as logic solver. 

Figure 21: Reliability block diagram, GA DualCore-S 

Figure 21 shows the reliability block diagram for the chosen logic solver. The input cards 

each can handle up to 12 analog (MCAD-S) or digital (MCDIN-S) input signals. The output 

card (MCDOT-S) can set up to 8 independent, redundant digital outputs. The hardware voter 

SR-01-42-24-00 combines two redundant output signals into one field signal, so two voters 

are required. 

The safety calculation according to Table 11 and Table 12 shows: 

PFDavg, total = PFDavg, MCAD-S + PFDavg, MCDIN-S + PFDavg, MCDOT-S + 2 * PFDavg, SR-01 

PFDavg, total = 2.71E-05, for T1 = 10 years 

PFHG, total = PFHG, MCAD-S + PFHG, MCDIN-S + PFHG, MCDOT-S + 2 * PFHG, SR-01 

PFHG, total = 2.69E-08 

The probability of failure in low demand mode – PFDavg, total = 2.71E-05 for T1 = 10 years – is 

below the limit for SIL3. 

The probability in high demand mode – PFHG, total = 2.69E-08 – also is below the SIL3 limit, 

but it is higher than the 15% fraction of SIL3 that is the recommended limit for the logic 

solver. 

The logic solver may be suitable for use in SIL3 safety functions. 

With hardware fault tolerance HFT = 1 and safe failure fraction SFF > 99.8% architectural 

constraints according to IEC 61508-2, table 2 and table 3, also allow SIL3. 

Note: The suitability of the complete safety function for the required SIL must be checked, 

since the logic solver is only a part of the complete safety loop! 


13 Index 

calculations 

failure rate .......................................... 45 

MTTR................................................. 45 

cards 

DSPVCU ............................................ 22 

i/o................................ 20, 27, 28, 37, 38 

ICU............................. 21, 38, 40, 42, 43 

MCADA-S ........... 16, 27, 28, 29, 30, 43 

MCAD-S ...................................... 43, 44 

MCDIN-S........................................... 43 

MCDOT-S 25, 27, 28, 29, 30, 36, 43, 44 

MCxxx-S .................... 18, 20, 21, 38, 42 

MPU-M1 .......................... 28, 29, 30, 38 

certificate.................................................. 7 

common cause........................................ 45 

communication17, 25, 27, 28, 30, 34, 35, 

36, 37, 40, 41, 42 

DCS .............. 17, 27, 29, 30, 34, 37, 41, 42 

diagnostic test................................... 25, 26 

Engineering 

Hardware ...................................... 27, 28 

software .................................. 27, 28, 30 

station ....... 17, 27, 29, 34, 37, 38, 41, 42 

GA BlueEdit17, 28, 29, 31, 33, 34, 35, 37, 

38, 40, 42, 43 

GA DualCore-S................................ 17, 23 

GA DUPLEX-S.................... 17, 23, 25, 31 

GA safety systems.................................. 40 

GA TMR-S............................................. 17 

IEC 61508 .......................................... 7, 11 

key switch ............................ 17, 36, 40, 41 

lifecycle............................................ 11, 12 

maintenance9, 11, 17, 29, 30, 33, 34, 37, 

38, 40, 41 

PES system11, 12, 17, 25, 26, 27, 28, 29, 

30, 33, 34, 37, 38, 40, 41 

process data ............................................ 42 

program cycle time................................. 25 

proof test .......................................... 26, 45 

running ..................... 17, 30, 34, 38, 40, 41 

Selbsttest ................................................ 24 

self test ................................................... 42 

SIL3-approved functions............ 29, 30, 36 

system reaction time25, 26, 27, 28, 29, 30, 

35, 36 

time synchronisation .............................. 42 

trend analyzer......................................... 42 

visualisation system ............................... 42 

visualization system ......................... 17, 35

GA BlueLine safety manual - TUV Cooperation - Functional Safety

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?