GA MCU SafetyCore safety manual - TÜV Rheinland Group

GEBHARDT Automation GmbH
GA MCU SafetyCore
safety systems
Safety Manual

Title GA MCU SafetyCore safety manual
File GA MCU SafetyCore - safety manual Rev00.00 23072009.doc
Document
number
Revision index Description
G0.HA.0003.031.41.088.00.00.E.E.O
document history
Author
Review
Release
00.00 first release A = StS
R = MK
Re = UG
Involved at GEBHARDT Automation GmbH: Ulrich Gebhardt (UG), Wolfgang Paulicks (WP),
Markus König (MK), Stephan Schild (StS), Dr. Peter Dellwig (PD)
Relevant documents:
/1/ GA safeEdit 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 MCU SafetyCore checklists
Date
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 2 of 45
23.07.2009

Contents
1 INTRODUCTION ...................................................................................................................................... 6
1.1 CONTACT INFORMATION...................................................................................................................... 6
1.2 DOCUMENT SCOPE, APPLIED STANDARDS ............................................................................................ 7
1.3 GENERAL STATEMENTS........................................................................................................................ 8
1.4 DOCUMENT MAP .................................................................................................................................. 9
2 SAFETY LIFECYCLE ............................................................................................................................ 10
3 PRODUCT OVERVIEW......................................................................................................................... 12
3.1 GA MCU SAFETYCORE CONCEPT ..................................................................................................... 12
3.2 SYSTEM INTEGRATION ....................................................................................................................... 15
3.3 HARDWARE COMPONENTS ................................................................................................................. 16
3.4 DIAGNOSTIC COVERAGE .................................................................................................................... 16
3.5 ERROR RESPONSE............................................................................................................................... 16
3.6 FUNCTIONAL AND DISPLAY ELEMENTS OF HARDWARE COMPONENTS ................................................ 18
3.6.1 Elements of MCxxx-S cards.......................................................................................................... 18
3.6.2 Elements of ICU cards ................................................................................................................. 19
3.6.3 Elements of DSPVCU cards......................................................................................................... 20
3.6.4 Elements of cooling fan................................................................................................................ 20
3.6.5 Elements of the safety relay GA SR-01-42-24-00......................................................................... 21
3.6.6 Elements of DFAB-1oo2D external hardware voter .................................................................... 21
3.6.7 Elements of TFAB DIGIO 2oo3 ................................................................................................... 22
3.7 SAFETY TIME AND REACTION TIME .................................................................................................... 22
3.7.1 System reaction time .................................................................................................................... 22
3.7.2 Diagnostic test interval ................................................................................................................ 23
3.7.3 Process safety time....................................................................................................................... 23
3.7.4 Proof test interval......................................................................................................................... 23
4 PES SYSTEM ENGINEERING.............................................................................................................. 24
4.1 HARDWARE ENGINEERING................................................................................................................. 24
4.1.1 Specification of safety requirements............................................................................................. 24
4.1.2 Hardware design and validation planning................................................................................... 24
4.1.3 System integration........................................................................................................................ 24
4.1.4 Hardware engineering, check list ................................................................................................25
4.2 SOFTWARE ENGINEERING .................................................................................................................. 25
4.2.1 Specification of safety requirements............................................................................................. 25
4.2.2 Software design and validation planning..................................................................................... 25
4.2.3 SIL3-approved function blocks..................................................................................................... 26
4.2.4 Integration of PES hardware and software.................................................................................. 26
4.2.5 Software validation ...................................................................................................................... 26
4.2.6 Software engineering, check list................................................................................................... 27
5 ASSEMBLY AND INSTALLATION..................................................................................................... 28
5.1 QUALIFIED PERSONNEL...................................................................................................................... 28
5.2 SAFETY-RELEVANT RESTRICTIONS OF USE ......................................................................................... 28
5.3 MOUNTING AND CONNECTING ........................................................................................................... 28
5.4 ASSEMBLY AND INSTALLATION, CHECK LIST ..................................................................................... 29
6 FORCING I/O SIGNALS........................................................................................................................ 30
6.1 PROCEDURE ....................................................................................................................................... 30
6.2 FORCING I/O SIGNALS, CHECK LIST .................................................................................................... 30
7 COMMISSIONING ................................................................................................................................. 31
7.1 QUALIFIED PERSONNEL...................................................................................................................... 31
7.2 COMMISSIONING PROCEDURES .......................................................................................................... 31
7.3 APPLICATION SOFTWARE MODIFICATION........................................................................................... 32
7.3.1 Program modifications................................................................................................................. 32
7.3.2 Parameter modification................................................................................................................ 32
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 3 of 45

7.3.3 Online modification...................................................................................................................... 32
7.4 COMMISSIONING, CHECK LIST............................................................................................................ 33
8 MAINTENANCE ..................................................................................................................................... 34
8.1 QUALIFIED PERSONNEL...................................................................................................................... 34
8.2 MAINTENANCE PROCEDURES............................................................................................................. 34
8.3 EXCHANGE OF COMPONENTS ............................................................................................................. 35
8.4 MAINTENANCE, CHECK LIST .............................................................................................................. 35
9 ACCESS AUTHORIZATION................................................................................................................. 36
9.1 USER LOGIN....................................................................................................................................... 36
9.2 KEY SWITCH FOR OPERATING MODE .................................................................................................. 36
10 DIAGNOSTIC INFORMATION............................................................................................................ 38
10.1 DIAGNOSTIC DATA............................................................................................................................. 38
10.2 PROCESS DATA................................................................................................................................... 38
10.3 ANALYZING ERROR MESSAGES .......................................................................................................... 39
11 COMMON TECHNICAL DATA ...........................................................................................................40
12 SAFETY SPECIFIC DATA .................................................................................................................... 41
12.1 SYMBOLS AND ABBREVIATIONS......................................................................................................... 41
12.2 CHARACTERISTIC SAFETY VALUES..................................................................................................... 42
12.2.1 GA MCU SafetyCore: Probability of Failure data.................................................................. 42
12.2.2 SIL example GA DUPLEX-S ................................................................................................... 43
12.2.3 SIL example GA DualCore-S................................................................................................... 44
13 INDEX ....................................................................................................................................................... 45
List of warnings
Warning 1.................................................................................................................................. 8
Warning 2.................................................................................................................................. 8
Warning 3................................................................................................................................ 28
Warning 4................................................................................................................................ 30
Warning 5................................................................................................................................ 32
Warning 6................................................................................................................................ 32
Warning 7................................................................................................................................ 34
Warning 8................................................................................................................................ 36
Warning 9................................................................................................................................ 37
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 4 of 45

List of figures
Figure 1: document map............................................................................................................ 9
Figure 2: overall safety lifecycle............................................................................................. 10
Figure 3: hardware safety lifecycle ......................................................................................... 11
Figure 4: software safety lifecycle .......................................................................................... 11
Figure 5: GA MCU SafetyCore concept, DualCore-S configuration ..................................... 12
Figure 6: GA MCU SafetyCore concept, DUPLEX-S configuration ..................................... 13
Figure 7: GA BlueLine system schematic............................................................................... 14
Figure 8: Example for network integration............................................................................. 15
Figure 9: front panel and elements of MCxxx-S cards ........................................................... 18
Figure 10: front panel and elements of ICU cards .................................................................. 19
Figure 11: front panel and elements of DSPVCU card........................................................... 20
Figure 12: front panel and elements of cooling fan ................................................................ 20
Figure 13: GA SR-01-42-24-00 relay voter, 1oo2 .................................................................. 21
Figure 14: DFAB-1oo2D majority voter................................................................................. 21
Figure 15: TFAB DIGIO 2oo3 majority voter........................................................................ 22
Figure 16: user login ............................................................................................................... 36
Figure 17: key switch Running/Maintenance.......................................................................... 36
Figure 18: Reliability block diagram, 1-out-of-2D example................................................... 43
Figure 19: Reliability block diagram, GA DualCore-S........................................................... 44
List of tables
Table 1: check list hardware engineering................................................................................ 25
Table 2: check list software engineering, system integration ................................................. 27
Table 3: check list software engineering, programming......................................................... 27
Table 4: check list software engineering, validation............................................................... 27
Table 5: check list assembly and installation.......................................................................... 29
Table 6: check list forcing i/o signals...................................................................................... 30
Table 7: check list commissioning.......................................................................................... 33
Table 8: check list commissioning, program modification..................................................... 33
Table 9: check list maintenance, exchanging cards ................................................................ 35
Table 10: Probability of failure, externally redundant i/o cards ............................................. 42
Table 11: Probability of failure, internally redundant i/o cards .............................................. 42
Table 12: Probability of failure, external hardware voter ....................................................... 42
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 5 of 45

1 Introduction
1.1 Contact information
GEBHARDT Automation GmbH
Oelkinghauser Str. 12 a
D- 58256 Ennepetal
Germany
Tel.: +49 2333 7908 - 0
available during working hours, Mo to Fr, from 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
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 6 of 45

1.2 Document scope, applied standards
This document applies to the following products:
• components based on GA MCU SafetyCore
• systems build with GA MCU SafetyCore 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.00/09
Programmable electronic safety systems
GA MCU SafetyCore
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:
Functional safety of programmable electronic systems
• DIN EN 954-1: 1996
Safety of Machinery, Safety related parts of control systems
Part 1: General principles for design
• EN ISO 13849-1: 2006
Safety of machinery, Safety-related parts of control systems,
Part 1: General principles for design
• IEC 61511-1: 2003
Functional safety - Safety instrumented systems for the process industry sector
• DIN EN 50178: 1998
Electronic equipment for use in power installations
• IEC 61131-2: 2003
Programmable controllers, Part 2: Equipment requirements and tests
• EN 60204-1: 2006
Safety of machinery - Electrical equipment of machines
Part 1: General requirements
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 7 of 45

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 MCU SafetyCore 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 MCU SafetyCore 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 MCU SafetyCore systems except for
the purpose of backup.
Any reverse engineering, such as reverse compilation or dis-assembling of the software is
strictly prohibited.
The GEBHARDT Automation products mentioned in this document may be registered
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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 8 of 45

1.4 Document map
GA MCAD-S mod 1
technical
description
GA DualCore-S racks
technical
description
GA SR-01-42-24-00
technical
description
GA ICU mod 1
technical
description
Flyer
GA BlueLine
systems
GA MCU SafetyCore
safety manual
GA safeEdit
user manual
GA MCDIN-S mod 1
technical
description
GA DUPLEX-S racks
technical
description
GA DFAB-1oo2D
technical
description
GA ICU mod 2
technical
description
Flyer
Safety &
Availability
central manuals
GA MCU SafetyCore
installation
manual
software
hardware
information
GA safeEdit
online help
GA MCDOT-S mod 1
technical
description
GA TMR-S racks
technical
description
GA TFAB-DIGIO-2oo3
technical
description
GA FPR mod 3
technical
description
Flyer
i/o cards
Figure 1: document map
TÜV
Revision
Release List
GA MCADA-S mod 1
technical
description
GA DSPVCU
technical
description
Flyer
Non-SIL3 systems
Figure 1 shows documents relevant to GA MCU SafetyCore systems. This manual will reference
to the appropriate documents as required.
Informative documents show an overview of their respective topic but are not safety relevant.
They are not referenced in this safety manual.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 9 of 45

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 2: 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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 10 of 45

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 3: hardware safety lifecycle
E/E/PES operation and
maintenance
procedures
to box 14 in
overall safety lifecycle
The hardware safety lifecycle must be considered during planning and design of the E/E/PES
system. This document defines activities and procedures for each phase.
9.2
Software safety
validation planning
9.1
9.1.1
Safety functions
requirements
specification
9.3
9.4
9.6
Software safety
requirements specification
9.1.2
Software design
and development
PE integration
(hardware/software)
Software safety
validation
Safety integrity
requirements
specification
to box 12 in
overall safety lifecycle
9.5
Figure 4: software safety lifecycle
Software operation and
modification procedures
to box 14 in
overall safety lifecycle
The software safety lifecycle must be considered during planning and design of software for
the E/E/PES system. This document defines activities and procedures for each phase.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 11 of 45

3 Product overview
3.1 GA MCU SafetyCore concept
The GA MCU SafetyCore 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 is used to create the combined
field output signal.
Figure 5: GA MCU SafetyCore concept, DualCore-S configuration
Figure 5 shows the minimal system configuration GA DualCore-S, a SIL3 application with
hardware fault tolerance 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.
• 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 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
state ON/OFF.
• 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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 12 of 45

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.
Figure 6: GA MCU SafetyCore concept, DUPLEX-S configuration
Figure 6 shows a dual-redundant configuration. 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
with a 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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 13 of 45

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 safeEdit 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 safeEdit user manual, AIN function, for more
information).
Voting on digital output signals:
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-energization to the safe state.
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.
Figure 7: GA BlueLine system schematic
GA MCU SafetyCore components may be combined with selected components for regular,
non safety-related control functions in GA BlueLine systems. These components are certified
not to interfere with safety functions. See list of certified components.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 14 of 45

3.2 System integration
Figure 8: Example for network integration
A safety project usually consists of at least one PES system (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 safety-relevant 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 hardwired i/o
signals. The MPU-M1 card, currently beeing SIL3 certified, will allow redundant ethernet
communication with SIL3 integrity.
Engineering system is a PC, running Windows (2000 or XP) and the integrated development
tool GA safeEdit. After activating maintenance mode this system may be used for 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 8 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 network failures.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 15 of 45

Networks according to Figure 8 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 MCU SafetyCore 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 MCxxx-S.
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
short time, while the system continues running with reduced hardware fault tolerance.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 16 of 45

In DualCore-S configuration a detected error on a MCDOT-S output card will cause a shutdown.
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 output cards will immediately turn off the affected
signal or card (0 mA to trip), depending on the fault reaction.
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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 17 of 45

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 9
shows diagnostic LEDs and ejection lever.
Figure 9: 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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 18 of 45

3.6.2 Elements of ICU cards
The mechanical parts with ejection lever, module rail and guiding pin are identical to
MCxxx-S cards. See Figure 9 and description.
Figure 10: front panel and elements of ICU 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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 19 of 45

3.6.3 Elements of DSPVCU cards
Figure 11: 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 12: 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 system architecture, 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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 20 of 45

3.6.5 Elements of the safety relay GA SR-01-42-24-00
Figure 13: 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 14: 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 de-
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 21 of 45

coupled 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 15: 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.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 MCDOT-S or MCADA-S processor card. For details on program
cycle time see GA safeEdit user manual.
Usually the doubled program cycle time plus 15 msec for relay switching may be used as
system reaction time.
Exceptions from this time may occur when:
• safety 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
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 22 of 45

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 MCU SafetyCore 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 can 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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 23 of 45

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 2: overall safety lifecycle on page 10.
Figure 3: hardware and Figure 4: software show detailed phases for engineering and specify
required activities and procedures.
4.1 Hardware Engineering
4.1.1 Specification of safety requirements
A detailed list with all safety requirements for the project is compiled. This is the basis for all
decisions on hardware and software design of the PES system.
4.1.2 Hardware design and validation planning
Hardware design takes the list of requirements and decides on the necessary hardware to
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.
• 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 MCU-S i/o processor cards
must be documented and considered for validation and software engineering.
4.1.3 System integration
System integration designs the integration of the PES systems in the project’s safety concept.
The following measures need to be considered:
• Integration of PES systems in the control panel, including external hardware.
• Integration of multiple PES systems, with special attention on 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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 24 of 45

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 i/o processor 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 appropriate communication extensions (ICU model 1 card) for process
requirements and available space in system rack?
10 Network layout: distance, cable length, cable type (copper, optical),
switches, routers, redundancy, addressing
Table 1: check list hardware engineering
See also GA MCU SafetyCore 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 24 is extended with signal information on i/o signals. For each digital signal the contact
mode (normally open, normally closed) if specified, for analog signals the physical range is
defined.
For each safety function the required safety time is specified.
For each safety function the working principle is defined.
4.2.2 Software design and validation planning
The distribution of safety functions to PES hardware components is implemented as 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 safeEdit is used as programming tool, see GA safeEdit user manual.
Software design considers the following measures:
• Application programming for specific safety functions on MCDOT-S 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 safeEdit user manual). Documentation
and validation planning for each signal.
• Analysis of switch-over between operating modes in safety functions. Validation
planning for all operating modes with special attention on the moment of switchover.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 25 of 45

• 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 safeEdit function blocks are approved for use in SIL3 safety functions. They may
be used without restriction for application programming. The GA safeEdit 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 MCDOT-S and MCADA-S output processor
cards, and comparing with required system reaction time. Consider adequate reserve
for software changes during commissioning.
• Memory utilization of MCDOT-S and MCADA-S processor cards acceptable, including
adequate reserve for software changes during commissioning.
• All relevant diagnostic information of PES systems should be displayed on regular
process 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 safeEdit and the following methods:
• Syntax check and parameter check, offline. On engineering station or PC.
• Offline simulation on engineering station or PC, without PES hardware.
• Online debug on PES hardware, with forced i/o signals, no field signals
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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 26 of 45

4.2.6 Software engineering, check list
No. Description Check
1 Hardware and software configuration corresponding
2 Network configuration correct in hardware and software
3 System reaction time of each MCDOT-S and MCADA-S card acceptable
as compared to required safety times
4 Memory utilization of 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
No. Description Check
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
No. Description Check
1 Syntax check and parameter check: no errors, no warnings?
2 Simulation offline on PC: functionality as specified?
3 Online debug on PES system, without field signals, forced signals in
maintenance mode: functionality as specified?
4 Online debug on PES system, with simulated field signals (test equipment,
panel acceptance test), in running mode: functionality as specified?
Table 4: check list software engineering, validation
See also GA MCU SafetyCore checklists for additional information.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 27 of 45

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 safeEdit 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 in normal environments only. 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 separately 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 electro-static discharge. Discharges
by touching components must be avoided by using appropriate measures (touching
of or connection to electrically grounded metal parts, ...).
Protective measures are always required when changing components.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 28 of 45

5.4 Assembly and installation, check list
No. Description Check
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
See also GA MCU SafetyCore checklists for additional information.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 29 of 45

6 Forcing i/o signals
6.1 Procedure
With forcing all input and output signals of a PES system may be set to any specific value,
independent of field inputs or PES control outputs. This will override safety functions, restricting
or disabling them, so forcing may be used only during commissioning and maintenance,
under specified operating conditions.
The GA safeEdit user manual explains procedures for forcing all types of i/o signals.
The following items must be considered concerning forcing:
• Impact analysis: the impact on PES system and process must be 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
See also GA MCU SafetyCore checklists for additional information.
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!
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 30 of 45

7 Commissioning
7.1 Qualified personnel
All persons involved in commissioning must be qualified according to their duties. They
must be familiar with relevant technical manuals, system hardware and software, and be appropriately
trained in safety procedures.
Qualification includes:
• training and experience in handling of electrical equipment according to approved
codes of practice
• software training for the programming tool GA safeEdit for commissioning of SIL3
safety systems
• instruction in project specific safety concept
• instruction in project specific application software
• experience in integration of control systems with control panel
• instruction in machinery and processes to be controlled
• training in use of appropriate safety equipment
• training in first aid
7.2 Commissioning procedures
Commissioning uses the programming tool GA safeEdit for programming, system 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 mostly 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 safeEdit 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
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 31 of 45

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 safeEdit.
• 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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 32 of 45

• 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 30.
• During modification the safety functions are compromised. Appropriate emergency
measures must be prepared.
7.4 Commissioning, check list
No. Description Check
1 Is the project’s safety concept clearly understood?
2 Required key switches and passwords available?
3 System hardware configuration correct?
4 Communication check with all systems successful?
5 Loop check for all i/o signals: range and diagnostics correct?
6 Appropriate safety measures and emergency measures prepared?
7 Check of safety functions: machine stopped, machine running.
7a When required: program modification, see additional check list below.
8 Check system reaction time, for each i/o 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
No. Description Check
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 i/o card. Compare with
process safety time.
7 Documentation of successful changes.
8 Back-up new version.
Table 8: check list commissioning, program modification
See also GA MCU SafetyCore checklists for additional information.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 33 of 45

8 Maintenance
8.1 Qualified personnel
All persons involved in maintenance must be qualified according to their duties. They must
be familiar with relevant technical manuals, system hardware and software, and be appropriately
trained in safety procedures.
Qualification includes:
• training and experience in handling of electrical equipment according to approved
codes of practice
• software training for the programming tool GA safeEdit for maintenance and diagnostics
• instruction in project specific safety concept
• training in use of appropriate safety equipment
• training in first aid
8.2 Maintenance procedures
Regular maintenance is planned in detail as component of the safety concept. The planned
tasks are performed in specified service intervals, including:
• Proof-Test interval
• checking and changing air filters
• checking for fouling or contamination
• control of system diagnostics like: diagnostic visualization in DCS, alarms, LED
display on hardware components, extended diagnostic information on engineering
station using GA safeEdit
Unscheduled maintenance becomes necessary when regular maintenance shows irregularities.
It is generically considered in the safety concept and includes the activities:
• identification and repair of i/o signal failures
• identification and repair/exchange of PES system components (i/o cards, fan, power
supply, ...)
• identification and repair of network communication failures
Unscheduled maintenance requires:
• Unequivocal identification of error messages and cause for error: i.e. high system
temperature may have several causes: fouled air filter, cooling fan failure, control
panel air conditioning failure.
• Cross-check of detected error or message with all available tools: DCS 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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 34 of 45

8.3 Exchange of components
Exchange of components is possible during normal operation. Details are specified in technical
descriptions of the components and systems.
Exchange of programmable system components, MCxxx-S cards and ICU cards requires special
attention:
• Exchange of MCxxx-S or ICU cards requires use of engineering station with GA
safeEdit.
• The PES system is switched to maintenance mode.
• Password protection of GA safeEdit requires use of valid password.
• Error and cause of error is identified, 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 safeEdit.
• Replacing i/o cards:
o The application program is checked. Usually the current program must be
downloaded to the spare card.
o signal cable from field assembly module to connector is plugged in and fixed.
o Correct state of i/o signals and internally calculated states is compared with
redundant cards of other DUPLEX-S unit.
• 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 safeEdit
user manual.
8.4 Maintenance, check list
Checks for regular maintenance, including proof-test intervals, use project specific check
lists.
No. Description Check
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
See also GA MCU SafetyCore checklists for additional information.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 35 of 45

9 Access authorization
9.1 User login
Figure 16: user login
Before using GA safeEdit 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 processor cards and ICU communication
processor.
Access beyond diagnostics, affecting the PES system, additionally requires activation of
“Maintenance” mode with the hardware key switch. “Running” mode allows only diagnostics.
User configuration and access rights are explained in GA safeEdit user manual.
9.2 Key switch for operating mode
Figure 17: 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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 36 of 45

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!
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 37 of 45

10 Diagnostic information
10.1 Diagnostic data
Self test statistics
Authorized users can access self test statistics, stored on each MCxxx-S card. The information
is stored in card-internal flash memory. Access via GA safeEdit, see GA safeEdit 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 39.
Additionally all messages of the DUPLEX units A and B 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 ICU communication controllers 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. 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 safeEdit, see GA safeEdit user manual.
Real-time data logging of all i/o signals, including time synchronization between several controllers,
is optionally available on the ICU controllers.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 38 of 45

10.3 Analyzing error messages
The programming tool GA safeEdit 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.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 39 of 45

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 DUPLEX/7-S 450 W
max. power DUPLEX SMART-S 300 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 / DFAB
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]
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 40 of 45

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
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 41 of 45

12.2 Characteristic safety values
The characteristic safety values for a complete safety loop are calculated as summation of the
probability of failure for every component, modified according to system architecture.
The probability of failure 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 MCU SafetyCore: Probability of Failure data
externally redundant
cards
PFDavg
T1 = 1y
PFDavg
T1 = 5y
PFDavg
T1 = 10y
PFDavg
T1 = 20y
PFHG I/O
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 i/o cards
internally redundant
cards
PFDavg
T1 = 1y
PFDavg
T1 = 5y
PFDavg
T1 = 10y
PFDavg
T1 = 20y
PFHG I/O
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 i/o 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
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.8 %.
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 GA DualCore-S systems can be configured 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 for external redundancy – using two or
three separate cards to achieve hardware fault tolerance – Table 10 is used for the PFD and
PFH calculation.
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 42 of 45

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 18: Reliability block diagram, 1-out-of-2D example
Figure 18 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
below 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!
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 43 of 45

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 19: Reliability block diagram, GA DualCore-S
Figure 19 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 independent 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!
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 44 of 45

13 Index
calculations
failure rate .......................................... 41
MTTR................................................. 41
cards
DSPVCU ............................................ 20
i/o................................ 18, 24, 25, 34, 35
ICU............................. 19, 35, 36, 38, 39
MCADA-S ................................... 14, 39
MCAD-S ...................................... 39, 40
MCDIN-S........................................... 39
MCDOT-S 22, 24, 25, 26, 27, 33, 39, 40
MCxxx-S .................... 16, 18, 19, 35, 38
certificate.................................................. 7
common cause........................................ 41
communication15, 22, 24, 25, 27, 31, 32,
33, 34, 36, 37, 38
DCS .............. 15, 24, 26, 27, 31, 34, 37, 38
diagnostic test......................................... 23
Engineering
Hardware ...................................... 24, 25
software .................................. 24, 25, 27
station ....... 15, 24, 26, 31, 34, 35, 37, 38
GA DualCore-S...................................... 15
GA DUPLEX-S.............. 15, 20, 22, 28, 36
GA safeEdit15, 25, 26, 28, 31, 32, 34, 35,
36, 38, 39
GA TMR-S............................................. 15
IEC 61508 .......................................... 7, 10
key switch ............................ 15, 33, 36, 37
lifecycle............................................ 10, 11
maintenance8, 10, 15, 26, 27, 30, 31, 34,
35, 36, 37
PES system10, 11, 15, 22, 23, 24, 25, 26,
27, 30, 31, 34, 35, 36, 37
process data ............................................ 38
program cycle time................................. 22
proof test .......................................... 23, 41
running ..................... 15, 27, 31, 35, 36, 37
Selbsttest ................................................ 21
self test ................................................... 38
SIL3-approved functions............ 26, 27, 33
system reaction time22, 23, 24, 25, 26, 27,
32, 33
time synchronisation .............................. 38
trend analyzer......................................... 38
visualisation system ................... 15, 32, 38
GA MCU SafetyCore - safety manual Rev00.00 23072009.doc page 45 of 45