Chapter 6

Programmable Safety Systems

Contents
6.0 Concept
6.1 Method
6.2 Hardware
6.2.1 Test pulses
6.2.2 Input modules
6.2.2.1 Typical connection
6.2.3 Output modules
6.2.3.1 Typical connection
6.2.4 Input/output module with test pulse
6.2.4.1 Typical connection
6.2.5 Dual-pole input/output module
6.2.5.1 Typical connection
145
6.3 Software

Programmable Safety Systems

6.3.1 MBS System: Transfer lines
6.3.2 MBS System: Eccentric presses
6.3.3 MBS System: Hydraulic presses
6.3.4 MBS System: Tank farm installations
6.3.5 MBS System: Burner management
6.4 Security
6.5 Certification
6.6 Reliability and availability
6.7 Typical failsafe program
146
Programmable Safety Systems
 6.0 Concept

The introduction of European Directives has helped turn attention

towards the concept of machinery safety. In some cases, the
emphasis placed on the suitability and integrity of safety systems has
led to concern and confusion among machinery designers and users.
The safety circuits of simple, stand-alone machines generally use
relatively basic safety-related controls, designed with high-integrity
hard-wired components. When these simple machines grow into
production lines or are incorporated into larger, complex machines, the
safety-related control systems may need to be more complex to suit.

Complex hard-wired systems can be unreliable and have poor

diagnostic capabilities, especially those that have a requirement for
extensive interlocking for functions such as setting or teaching. In a
well-designed system, any unreliability or failure will lead to a safe
2 state, but will still have an adverse effect on production. When such 147
unreliability causes a loss of revenue, the production department

Programmable Safety Systems

normally wins the day and short cuts are taken. This is when most
accidents occur.

In 1992 Pilz decided to examine how a programmable safety system

could be produced for application in a high-integrity system. Figs. 49
and 50 outline the thinking of the design team. Fig. 49 shows a
traditional design, in which the machine or process is controlled by a
conventional PLC, while the safety section is overseen by a separate
hard-wired system. Clearly, if it were possible to incorporate these
two sections into a single unit, as in Fig. 50, costs could be reduced
and reliability increased.
 Standard PLC PSS 3000 Safety System

External
Safety
Hardware

Process Process

Fig. 49: Safety functions controlled by Fig. 50: Safety functions controlled
separate hardware through one system

148 When complex relay-based systems were the only choice for 3
controls, overall reliability was poor and fault-finding was often
Programmable Safety Systems

difficult and time consuming. Engineers had to work their way through
the cascaded circuits, following the control philosophy until the fault
was located. During the 1970s programmable controllers were
introduced and engineers began to use these extensively to replace
relay circuits.

This simplified the implementation process, although initially there

was no noticeable improvement in reliability. Arguably the most
significant advantage was the level of diagnostics that could be
achieved. Problem areas could be identified and located quickly,
making repair work quicker and easier. Once the reliability of the
hardware and software improved as development progressed, the
control engineer had a powerful tool for the majority of control
applications.
 However, safety was one area where these devices could not be
sanctioned for use. Modern PLCs are very reliable, but on failure
they can, and do, fail into an unsafe mode. The normal failure mode
for a semiconductor device is short circuit, and as the PLC outputs
are either semiconductors or relays controlled by semiconductors,
these outputs often fail in the “on” position. Alongside potential
hardware failures, there is also the possibility of unseen software
problems, such as a glitch in the processor operating system or
program compilers. It is accepted that software systems will always
contain undetected (systematic) faults that will only show up under
certain circumstances. These circumstances may not arise during
testing, but could arise during the lifetime of the system, with
dangerous consequences for health and safety. The aim of the PSS
design team was to bring the flexibility and powerful diagnostics of a
PLC into a safety controller, coupled with the integrity of a hard-wired
system.
4 149

Programmable Safety Systems

 6.1 Method

The only way to build a programmable system with the desired level of
integrity was to take a leaf out of the petrochemical control engineers’
book. Programmable safety control has been used in the petrochemical
industry for many years, guided by advice given in publications such as
“PES - Programmable electronic systems in safety-related
applications”, published by the HSE, and “Fundamental Safety Aspects
to be Considered for Measurement and Control Equipment” (DIN
19250). The ideas from these and other documents are being
combined into the international standard IEC 61508 (Functional safety.
Safety-related systems). The advice is mainly based on the
requirement for diverse processors used in a voting format.

Standard PLC Standard PLC Standard PLC

150 5
Programmable Safety Systems

PSS 3000

Fig. 51: Three controllers in one system

 Fig. 51 shows the basis of the PSS-range of programmable safety
systems. Effectively, the system is made up of three separate
controllers, which are all different. If the processors or software are
all the same, systematic faults may lead to common cause failures.
To remove this possibility, the internal processors are all from different
manufacturers and have totally different operating systems. To make
doubly sure that a systematic failure is unlikely to occur, the compilers
for each system are written by different companies. Data is
processed in parallel via the three controllers, as shown in Fig. 52.

I/Register 1 I/Register 2 I/Register 3

6 DPR DPR
151
Processor Processor Processor

Programmable Safety Systems

A B C

DPR
O/Register 1 O/Register 2 O/Register 3

&

Fig. 52: Three-channel structure of the PSS system

 Each processor has its own input and output register. The output
register in each device is compared in an “AND” gate. An output will
only be enabled when all three agree. This is the case for all “bit”
and “word” functions. In other words, the PSS operates as a 3 out of
3 (3oo3) voting system.

In order to achieve the requirements for a safety controller and

standard PLC in a single unit, the PSS was designed with 2 working
buses, one for the triple-voting failsafe (FS) section and the other for
the standard (ST) section. All three processors are used in the FS
section, but only processor “A” is used in the ST section. This
processor also controls the synchronisation of the overall system.

Users have to write the FS program once only. When the program is
finished it can be downloaded to the controller. The runtime version
of the program is loaded via the three independent compilers. Each
version of the program has its own check sum and these are
152 7
compared in all three systems. Provided that the program was
Programmable Safety Systems

correctly written at the start, the triple checking during use will ensure
failsafe operation. The ST program is written as for the majority of
conventional PLCs.
 6.2 Hardware

PSS safety systems are available in two designs: compact and

modular. Compact systems contain the CPU, power supply and I/Os
within a single housing. These systems can communicate with other
types of controller but are not individually configurable and cannot be
expanded. Compact systems have no standard I/Os but have 32, 56
or 60 failsafe I/Os, depending on the individual version.

Modular systems are built up individually within module racks. A

single base module rack has a maximum configuration of 288 I/Os, all
of which can be used as failsafe I/Os. Expansion racks can be added
to give a maximum configuration of 768 I/Os. However, a maximum
of 256 of these can be used as failsafe I/Os (failsafe modules cannot
be used on an expansion rack). New developments in safe bus
technology have raised the maximum number into thousands of I/Os.
8 SafetyBus p (see Chapter 7) can support 64 nodes, each of which 153
can either be an active PSS system or a simple I/O module.

Programmable Safety Systems

6.2.1 Test pulses
Continuous signal input devices (constant signals such as those from
an E-Stop button) can supply an unchanging signal over a long

Test pulses: Outputs on the

PSS DIOT Test period
T0 = Ax.16
T1 = Ax.17
T2 = Ax.18
=
T15 = Ax.31

Fig. 53: Simplified diagram of the test pulses

 period of time. During this time, the integrity of the periphery units
can only be monitored to a limited extent. Errors that arise may
remain undetected and will therefore accumulate. To avoid this, test
pulses should be used to check continuous signal input devices as
part of each cycle.

The PSS system supplies up to 16 staggered signals (short “off”

pulses) at a defined point in each cycle. The number of test pulses
and their allocation to PSS inputs are configured using the PSS
programming software.

6.2.2 Input modules

Each input on a digital input module has a single-channel structure as
far as the optocoupler. Only after the optocoupler is the input signal
processed in three channels. The three-channel section of the input
module is automatically tested by the PSS operating system. Digital
input modules can be used for single, dual or multi-channel input
154
devices, with or without test pulses. They can also be used to
Programmable Safety Systems

generate process alarms.

6.2.2.1 Typical connection
The example shows safety gates wired in a number of different ways.
The categories (in accordance with EN 954-1) arise from the different
wiring methods.

Safety Gates

Safety
category Low Higher Highest

T0 Test signal T0 T1

I 00
I 01
I 02
I 03
I 04
I 05
I 06
I 07
0V
0V

I 08
I 09
155
I 10
I 11

Programmable Safety Systems

I 12
I 13
I 14
I 15
0V
0V

I 16
E x 17 I 17
E x 18 I 18
E x 19 I 19
I 20
I 21 I 00
I 22 I 01
I 23 I 02
0V I 03
0V I 04
I 05
E x 06 I 06
E x 24 E x I07
24 I 07
E x 25 I 25 0V
E x 26 I 26 0V
E x 27 I 27
I 28
I 29 I 08
I 30 I 09
I 31 I 10
0V I 11
0V I 12
I 13
I 14
PSS DI
I 15

24V
0V

Fig. 54: Typical safety gate connections with Pilz PSS DI module
 6.2.3 Output modules
Each output on a digital output module has a monitoring input, which
is evaluated by the operating system.

6.2.3.1 Typical connection

Relay

Safety Low Higher Highest

category

O Feedback loop
O
00 to PSS DI
O
01
A x 03 O
02
A x 04 O
03
O
04
O
05
O
06
07
24V
0V

A x 08 O
A x 09 O
08
O
09
O
10
O
11
O
12
O
13
O
156 14
150V
0V
Programmable Safety Systems

O
O
16
O
17
O
18
O
19
O
20
O
21
O
22
23
24V
0V

O
O
24
O
25
O
26
O
27
O
28
O
29
O
30
31
24V
0V

PSS DO With continuous signals, this wire must

be connected to a test output (test
signal). The N/C contact is best
suited for this (zero signal principle)

24V
0V

Fig. 55: Typical relay connections with Pilz PSS DO module

The example shows various actuators (relays and valves), with and
without redundancy. This accounts for the different categories in
accordance with EN 954-1. One output is required per actuator. If
redundancy is not built into the actuators (e.g. by connecting the relay
contacts in series), category 2 will be the highest category achievable
under EN 954-1). Even if redundancy is built into the actuators,
category 4 cannot be achieved as the module has no additional
shutdown route, should both transistors at the output be defective.

6.2.4 Input/output module with test pulse

This I/O module (DIO T) can be used to supply test pulses. It has 16
inputs and 16 push-pull outputs, which can either be used to generate
test pulses or as outputs to control actuators.

157

Programmable Safety Systems

 6.2.4.1 Typical connection

E - STOP Redundant relay

(with feedback loop)

I 00
I 01
I 02
I 03
I 04
I 05
E x 06 I 06
E x 07 I 07
0V
0V

I 08
I 09
I 10
I 11
I 12
I 13
I 14
I 15
0V
0V

I 16
I 17
I 18
I 19
I 20
I 21
I 22
I 00
I 01
E-Stop
I 23 I 02
0V I 03
0V I 04
I 05
E x 06 I 06
E x I07
24 I 07
I 25 0V
I 26 0V
I 27
I 28
I 29 I 08
I 30 I 09
E x 31 I 31 I 10
158 0V
0V
I 11
I 12
I 13
I 14
PSS DI
I 15
Programmable Safety Systems

0V
0V

T0 O16
T1 O
O
17
O
18
O
19
O
20
O
21
O
22
23
24V
0V

A x 24 O
A x 25 O
24
A x 26 O
25
O
26
O
27
O
28
O
29
O
30
31
24V
0V

PSS DIOT

24V
0V

Only possible with a pulsed signal!

Fig. 56: Typical E-Stop connection with Pilz PSS DIO T module
E-stop buttons are always continuous input devices. This means that
the correct operation of the PSS can only be tested using test pulses.
This is required in order to achieve category 4. The PSS will check
for a short circuit to 24 V (stuck at “1”), short circuit to 0 V (stuck at
“0”), short across the input contacts and any malfunction of a PSS
input module.

6.2.5 Dual-pole input/output module

Dual-pole outputs have a second shutdown route, thereby providing
the highest level of safety. In simple terms you could imagine that
each output has two switches, one switching positive voltage and the
other switching negative voltage. Dual-pole output modules have two
load terminals per channel. The PSS operating system tests the
outputs as part of each cycle. This test will detect interruptions to the
load, short circuits and shorts across the output contacts.

1
159

Programmable Safety Systems

 6.2.5.1 Typical connection
Press
safety valve
I 00
I 01
I 02
I 03
I 04
I 05
I 06
I 07
0V
0V

E x 08 I 08
E x 09 I 09
E x 10 I 10
E x 11 I 11
I 12
I 13
I 14
I 15 T0
0V
0V

I 16
I 17
T1
I 18
I 19
I 20
I 21 I 00
I 22 I 01
I 23 I 02
0V I 03
0V I 04
I 05
E x 06 I 06
E xI0724 I 07
I 25 0V
I 26 0V
I 27
I 28
160 I 29
I 30
I 31
I 08
I 09
I 10
PSV
0V I 11
0V I 12
Programmable Safety Systems

I 13
I 14
PSS DI
I 15
0V
0V

A x 16
O16
A x 17 O 17
O 18
O 19
24V
24V

O 20
O 21
O 22
O 23
0V
0V

PSS DIO Z

24V
0V

Fig. 57: Typical press safety valve connection with Pilz PSS DIO Z module
The example in Fig. 57 requires 4 PLC inputs, whose correct
operation must be monitored through the PSS user program. Short
circuits, shorts across the input contacts and any breaks in the relay
coils of the press safety valve (PSV) will be detected. The feasibility
check for the PSV is performed through the user program.

1
161

Programmable Safety Systems

 6.3 Software

When it came to preparing the software for the programmable safety

system, it was decided that the less the user had to program, the less
margin there was for error. For this reason, all common safety
functions, such as emergency stop, two-hand control and gate
monitoring, have their own pre-written function blocks which have
been checked and approved by BG or TÜV. Once approved, all blocks
are sealed to prevent alteration. The user can only address the blocks
in order to configure the operating mode and assign inputs and outputs.

In addition to the common functions mentioned above, more

specialised blocks have also been developed and are available as
packages for use on specific types of machinery. The Pilz Modular
Block System (MBS) has specialist packages available for transfer
lines, eccentric/hydraulic presses, tank farm installations and burner
162 management. By using pre-programmed function blocks, the busy
engineer can save valuable time and effort while reducing costs and
Programmable Safety Systems

the potential for error. All safety-related blocks carry approvals to

related standards, either from BG or TÜV.

6.3.1 MBS System: Transfer lines

The package designed for transfer lines includes dedicated blocks for
monitoring and muting electrosensitive protective equipment (ESPE)
and optoelectronic protective devices (AOPDs), as well as the more
general blocks for emergency stopping, gate monitoring, etc.

6.3.2 MBS System: Eccentric presses

The package designed for eccentric presses includes dedicated
blocks for controlling the sequence of the press, and for monitoring
and muting ESPE and AOPDs. Press safety valves, broken
shearpins, enable switches and cams can also be monitored using
these blocks.
 6.3.3 MBS System: Hydraulic presses
The package designed for hydraulic presses includes dedicated
blocks for monitoring and muting ESPE and AOPDs as well as blocks
for driving and monitoring single/dual hydraulic valves.

6.3.4 MBS System: Tank farm installations

The package designed for tank farm installations includes dedicated
blocks for monitoring grip-sensitive switches, the concentration of
escaping gas and the level of gas tanks, as well as for controlling and
monitoring the position of valves.

6.3.5 MBS System: Burner management

The package designed for burner management includes specific
blocks for controlling the operational sequence, monitoring the flame,
controlling the burner start-up, driving and monitoring the position of
flaps and valves, pre-purge and ignition control.
163

Programmable Safety Systems

 6.4 Security

Security is vital on any safety system, but in general it is this factor

that is most ignored. The usual way to affect the performance of a
hard-wired system is to link out the functions either inside or outside
the control panels. Generally speaking, the only reason for doing this
is to override a system, illegally, to make production easier but less
safe, or to overcome persistent fault conditions. These faults are often
the result of over-complex hard-wired circuits. A programmable
safety system will overcome the second of these problems and in
some situations can monitor for the first. In both respects, the
application of a Pilz PSS will offer improved safety options.

The security of the software, however, is still a problem. Linking a

hard-wired system leaves physical evidence, but changes in software
can remain invisible and undetected. The solution is to prevent
164 unauthorised access to the FS section of the program, and this is
achieved in three ways. Firstly, the PSS software has to be used to
Programmable Safety Systems

make the changes. Secondly, access to the FS section is password

controlled. The final control lies in the program source codes. As
stated earlier, the program loaded into the controller is a runtime
version. To edit this, the source codes need to be resident in the
programming device.

These three levels of security should be sufficient. If one or

preferably all of these control measures are in place, it will not be
possible to make changes to the software. An encryption package
can also be used to add a further level of security. Once the program
has been finalised and verified it can be sealed as read-only,
permitting access to the diagnostics but not allowing changes. If
necessary, it is also possible to lock the program completely so that
not even the monitoring functions can be accessed. In some cases
this may be the preferred solution to prevent unauthorised changes.
 Failsafe Section

Flash-EPROM in the CPU

CPU 1 CPU 2 CPU 3

PB040 PB040 PB040

OB101 OB101 OB101

FB005 FB005 FB005

2B225 2B225 2B225

Fig. 58: PSS memory

Fig. 58 shows the layout of the memory in the FS section. Each

processor has its own independent Flash-EPROM. The program
blocks are compiled and loaded into each memory chip. These
memory chips are soldered on to the CPU card and cannot be
changed. The standard (ST) section of the program is stored in a
removable memory cartridge. This program does not need the 1
165
security expected for the FS section. The ST section operates in the

Programmable Safety Systems

same way as a conventional PLC, allowing the user to make changes
“on-line”. The user has full control over the security of the safety
software program. During operation, a system check sequence
continuously tests the internal system software control as well as the
control of the hardware functions.

Processor A:
IR IR System
(FS) FS User Program (FS) FS-User Program (OB001) Syn OR management Syn

Processor B:
IR System
(FS) FS User Program Syn OR management Syn

Processor C:
IR System
(FS) FS User Program Syn OR management Syn

1 PLC cycle

Fig. 59: Time characteristics of the processors

 Fig. 59 shows the relationship between the three processors.
Processor A is the key. It controls its share of the FS requirements,
runs the ST section and is also in charge of synchronising each
system scan. When the system is running, the contents of the output
registers (OR) are compared after initial synchronisation. The system
management check sequence is then carried out before final
synchronisation. This is the case for each scan.

The system management check effectively has two areas, as shown

in Fig. 60.

Processor

Flash-EPROM
Self test
ST-RUN
RAM
FS-RUN
DPR
166
Stop
Programmable Safety Systems

FS-STOP
to Periphery Test
FS-RUN

Run
0000
ST-RUN

OS: FS-RUN
eg.:Read in IR

FS-
User program:
Cyclical
Program
ST-
User program:

OS:
eg.:Output OR

Fig. 60: System management check

On power up, the PSS runs an internal check of all its functions,
testing the internal system software, firmware and hardware. The
check sums of the three memories are compared, together with the
status of the internal and external power supplies. This is also where
the dual-pole outputs are tested for operation. This pre-start check
takes approximately 40 seconds. During this time the CPU display
has all its segments lit and the system is in “stop”. If everything is
correct, the FS section is allowed to run and the display will show a
line of zeros. The periphery devices are then checked. The system
will shut down and the specific error code will be displayed if any of
the following problems are found during the check of the I/O status:

If an output is on and should not be on

If a dual-pole output cannot be switched on and off
If there is a test pulse fault.

The power supplies are then checked and the program block runtime 1
167
is monitored. These are both failsafe functions and any deviations

Programmable Safety Systems

from normal will result in a shutdown. All these pre-start checks are
active once the system is running. The I/O status checks, power
supply and block runtime are inspected at the end of each scan. The
40 second pre-start check is effectively running in the background, as
shown in Fig. 61. The initial check is split up into about 40,000 test
slices of about 1 ms each. This whole check is completed on power
up, but a number of these test slices are also performed during
operation in conjunction with the normal end of scan test.
 1 ms
Processor

Flash-EPROM

Self Test
RAM approx. 40 000
Test Slices
DPR

Periphery Test
eg.: 3 Test Slices

Cyclical Program Processing

Run

OS:
eg.:Read in IR

FS-
User program:

ST-
User program:
168 OS:
eg.:Output OR
Programmable Safety Systems

3 Test Slices

Fig. 61: Test slices on the PSS

The number of test slices to be included in the end of scan test is set
when the user configures the system software. The number chosen
will depend on the level of system integrity required by the application.
The more test slices selected, the sooner an internal system fault can
be detected. For example, if the program cycle time is 50 ms and two
test slices are processed in each cycle, it will take 20,000 cycles to
process all 40,000 test slices. With this setting, the full test will take
1,000 seconds. If the number of test slices is increased to 10 per
cycle, the cycle time will increase to 60 ms, but the tests will be
completed in 4,000 cycles, or approximately 240 seconds.
This critical testing regime lies behind the decision to design a 3oo3
controller as opposed to a 2oo2, with its lower complexity. Should a
fault occur within one of the processor sections during operation, and
it is not a fault that can be detected by the end of scan test, it will be
detected by the relevant test slice. During this fault period, the PSS
still operates as a failsafe device as it still has two of its systems
operable, i.e. it is now operating as a 2oo3 system.

A conventional 2oo2 controller needs to carry out a greater number of

test slices at the end of each scan, because if a fault does occur, the
system will operate as a 1oo2 system (i.e. not failsafe) until the fault
is detected. Clearly this time must be kept to a minimum in order to
achieve the required integrity. The PSS method allows for much
faster scan times than would be required for a less complex 2oo2
system, as fewer test slices need to be run.

169

Programmable Safety Systems

 6.5 Certification

For many years, control systems engineers working on machinery

applications have been told that safety systems must be hard-wired
and must not rely on electronic logic or software. Indeed, the
standards that such engineers rely on for advice suggest that:

“in the present state of the art, single electronic devices

do not have the necessary integrity for use in safety circuits”.

This may (or may not) have been true when the standards were
written, but it is important to remember that standards are intended to
be adaptable and are expected to evolve alongside technology.
Future versions of any standard are subject to discussion in
committee before publication. It is vital that committees are aware of
the advances in technology relating to the standard being discussed,
170 so that any relevant changes can be included. There are times when
the “state of the art” may move faster than the meetings of the
Programmable Safety Systems

Standards Committee, with the result that some clauses in the

standards may be open to debate.

As far as machinery is concerned, the legal requirement is to comply

with The Supply of Machinery (Safety) Regulations. The regulations
state that the best way to show compliance is to demonstrate that
both the design and construction follow the advice given in the
harmonised standards. The important thing to remember is that the
harmonised standards are a means to an end (i.e. safe machinery),
not an end in themselves. The standards are advisory documents, so
manufacturers may deviate from the methods described in the
standards and attempt to achieve the ends by a different route.
However, the alternative method must be at least as effective as the
one described in the standard. If required (for example, if there is a
reportable incident), it may be necessary to validate the chosen
alternative and demonstrate how it exceeded the requirements of the
standard. In the case of the PSS system, this validation was achieved
by submitting the product to independent test houses.

EN 954-1 (Safety of machinery. Safety-related parts of control

systems. General principles for design) is the standard that has to be
met. Most design engineers involved with control circuits are aware
of the information on risk assessments given in this standard.

Categories
B 1 2 3 4
S1
•
P1
• F1 •

S2
P2
• 171
P1
• •

Programmable Safety Systems

F2
P2
• • •

Preferred categories for reference points

• Possible categories which can require additional measures
Measures which can be overdimensioned for the relevant risk

S = Severity of injury
S1 Slight injury (normally reversible) i.e. slight cut or bruise.
S2 Serious (normally irreversible) injury including death.

F = Frequency and/or exposure time to the hazard

F1 Seldom to quite often and/or the exposure time is short.
F2 Frequent to continuous and/or the exposure time is long.

P = Possibility of avoiding the hazard

P1 Possible under specific conditions.
P2 Scarcely possible.

Fig. 62: Extract from EN 954-1: risk assessment chart

 The technique used in Fig. 62 was developed from the German
standard DIN 19250, which contained extra levels, as shown in Fig. 63.

S1

S2

S3

S4

Fig. 63: Extra risk assessment levels from DIN 19250

DIN 19250 expands on the parameter S (severity of injury). When

172 considering machinery applications, the number of people exposed to
a hazard is generally limited (normally only the operator). However, a
Programmable Safety Systems

potential fault within a petrochemical or nuclear site could expose

thousands of people, hence the addition of S3 and S4.

DIN 19250 lists 8 levels (“Anforderungsklassen”), normally shortened

to AK, e.g. AK6. IEC 61508 has seven parts and covers all aspects
of hardware/software implementation and validation. The techniques
for categorising a system draw heavily on DIN 19250 but lead to a
“Safety Integrity Level” (SIL). This standard lists 4 SILs. To get a
clear picture of all these standards and their implications it is
advisable to read them in their entirety, but the following chart gives a
representation of how the three standards fit together.
 DIN 19250 EN 954-1 IEC 61508
AK Category SIL
1/2 B -
2/3 1/2 1
4 3 2
5/6 4 3
7 - 4
8 - -
Fig. 64: “Safety levels” shown in relation to the main risk assessment standards

BG has certified the hardware of the PSS-range of programmable safety

systems to the highest level under EN 954-1. This certification was
granted using relevant parts from many standards. As mentioned earlier,
the machinery standards, particularly EN 60204-1, advise that
programmable systems are not suitable for use in safety applications.
However, tests by BG, using DIN 19250, IEC 61508, DIN 0801* and
EN 418** as reference, showed that the PSS systems at least met and 173
in some cases exceeded the requirements of EN 60204-1 and EN 954-1.

Programmable Safety Systems

BG’s interest lies primarily in machinery applications. As PSS
systems can be used outside this area, there was clearly a need to
seek more general approval from another source. The most
internationally well-known German test house is the Technischer
Überwachungs-Verein (TÜV), which offers test and approval facilities
across all industrial sectors. The PSS-range has been certified by
TÜV to AK 6, SIL 3. This means that the product carries the
necessary approvals for use in many high-integrity areas, including
offshore installations.

*DIN 0801 (Principles for Computers in Safety Related Systems)

**EN 418 (Safety of machinery. Emergency stop equipment. Functional aspects.
Principles for design)
 In addition to general use certificates, BG has also certified the range
for use in power press applications under the standards EN 692 and
prEN 693, covering both eccentric and hydraulic presses. TÜV has
also approved its use in gas burner control applications to EN 298.

Software was also considered for approval. It is not possible to

pre-approve complete user software, but function-specific blocks can
be tested and certified. Fig. 65 illustrates such a block.

SB 061
NA_1
13.03.96
15.48
4ACB

B - SSNR FG -X Approved
Block
X - EIN
X - S1_O
X - S2_O
X - QAut
X - QAut
174
Programmable Safety Systems

Fig. 65: Block header for function block SB 061

SB 061 is an approved emergency stop function block, which can

only be addressed via its inputs and outputs (marked B and X).
Inputs are shown on the left and outputs on the right. The block
header shows that the block description is SB 061 NA_1 and that the
block was created at 15.48 on 13.03.96. The Hex number 4ACB is
the check sum for this block. If any changes are attempted, this
number will differ from the standard and will not be recognised.

Once complete, it is possible to have the whole system certified by an

approved test house, but this is a costly exercise and this level of
approval is not generally considered necessary. However, for some
exceptional risk areas, the authorities may require additional approval.
6.6 Reliability and availability

Reliability is a difficult subject to both define and quantify. The only

meaningful data is that gathered from equipment in service. Clearly,
the longer a system is in service the more reliable the data will be.
For any new product, the only way to generate reliability figures that
will carry any credibility is to use tried and tested data about
components and sub-assemblies. Such data was used to calculate a
theoretical Mean Time Between Failures (MTBF) for the PSS-range.
The results are shown below.

Product Temp. 40 ºC Temp. 60 ºC Operation 265

days. 16 hours
per day at 40 ºC
PSS Hours Years Hours Years Years
PS 254,000 29.0 101,000 11.5 63.5
CPU 130,000 14.8 56,000 6.4 32.4
DIOT 190,000 21.6 94,000 10.7 46.0
DIOZ 210,000 23.9 108,000 12.4 52.0 175
DIF 450,000 51.9 226,000 25.9 112.0

Programmable Safety Systems

DO 205,000 23.3 108,000 12.4 51.0
3056 52,300 6.0 25,000 2.9 13.1

Fig. 66: MTBF figures for PSS 3000 and PSS 3056

The chart shows the calculated MTBF for general system failures. As
far as safety systems are concerned these figures refer to failures
into a safe condition. The calculated figures for failures into an unsafe
condition are shown below:

Risk of failure due to simultaneous multiple faults:

4 * 10-20/h
Risk of failure due to an accumulation of undetected
faults: 3.2 * 10-13/h
 Both of these figures show the theoretical MTBF to a dangerous state
in terms of hundreds of millions of years.

The following example takes a typical safety application, required to

be in service 24 hours a day at a maximum expected temperature of
40 ˚C. The application requires a PSS 3000 with the following parts
(listed with their MTBF in years):

PSS PS 29.0
PSS CPU 14.8
3 off PSS DI 49.4
2 off PSS DO 23.3
PSS DIOT 21.6

This combination would give an expected failure at 3.4 years. This

figure is only valid for the PSS. The figure for all the connected items
must also be included to give an overall system MTBF. Compare this
176
with a safety control system based on the use of relays. To meet the
Programmable Safety Systems

I\O requirement of the PSS specification, this system would need to

contain at least 100 individual relays. You could use the following
industry data to calculate an MTBF:

Relay MTBF (typical): 46 years

Relay MTBF to danger: 570 years

A system containing 100 relays would show a typical MTBF of less

than 6 months, but more relevant is the potential to fail to danger.
Using the above figures, this could be expected every 6 years. Again
the figures for the connected items must be included to give an
overall system MTBF.
Reliability is not the only key factor. In some cases, availability can
be even more important. The key to a system with high availability is
a quick repair time. The repair time can only be reduced to a
minimum if the diagnostics are powerful enough to locate problems
when they occur. This was one of the main design criteria required
from the design team in 1992. The in-built hardware and software
diagnostics on the PSS can identify whether:

A card is at fault
A wire is open or has a short circuit or
An input/output device has failed.

Availability is normally given as a percentage of available “up-time”.

This is calculated using MTBF data and a “Time to Repair” (MTTR).
Both values are stated in hours.

The calculation comes from: 177

System MTBF

Programmable Safety Systems

100 *
System MTBF + MTTR
 Using the values already calculated for MTBF and estimating an
MTTR for the PSS-based system at 2 hours (due to the diagnostics)
and an MTTR for the relay-controlled system at 5 hours, the
availability figures are as follows:

PSS availability 3.4 * 24 * 365

100 * = 99.99328 %
3.4 * 24 * 365 + 2

Relay availability 0.5 * 24 * 365

100 * = 99.886 %
0.5 * 24 * 365 + 5

Although it is clear that theory-based calculations can only be used

as a guide, it should be remembered that the theory is based on
reliable information. The figures show that PSS is good news for
178
production staff, as both reliability and availability are better than on
Programmable Safety Systems

an equivalent relay safety system. At the time of writing, over 3,000

PSS-based systems are in operation. Initial data regarding failures is
significantly better than these calculations show, but it will be
necessary to gather information from many millions of hours of use
under all conditions before this data can be regarded as significant.
6.7 Typical failsafe program

Fig. 67 shows a small application program for the failsafe section of a

PSS system. It can be compared to a PNOZ (Pilz two-channel E-
Stop relay); it controls a relay in conjunction with an E-Stop button.

This program uses the following function blocks:

SB 061 E-Stop monitoring

SB 067 Feedback loop monitoring

Both these blocks have been approved by a number of test houses.

The CAL-command can be used to incorporate the blocks into the
program and parameters can then be set. As stated earlier, the
blocks are sealed once approved, so that users are unable even to
look at their internal structure and functionality, let alone modify them.

This application program, consisting of OB 101, only calls up 179

two blocks:

Programmable Safety Systems

CAL SB 061
CAL SB 067

Once these have been entered, the block headers for the function
blocks will appear. The following actual parameters are required:

E-Stop button = E 00.00 and E 00.01

Reset button = E 02.08
Feedback loop = E 00.02
Main relay = A 02.16

These parameters depend exclusively on the user’s planned wiring.

Other parameters will depend on the required function:
 QAnf = Start-up reset required
QAut = Automatic reset when E-Stop
button is released
FG = Enable

PROGRAM LISTING FROM OB 101

I 00 E 0.00
I 01 E 0.01 E-STOP : Segment 00
I 02 E 0.02 : CAL SB 061
I 03
I 04
I 05 SB 061
I 06
I 07 NA_1
0V
0V 13.03.96
15.48
I 08
I 09 4AC8 APPROVED BLOCK
I 10
I 11
I 12
I 13
I 14 KB 001 -B- SSNR FG -X- M 070.00
I 15 E 2.08 -X- EIN
0V
0V E 0.00 -X- S1_Ö
E 0.01 -X- S2_Ö
I 16 M 110.00 .RLO_ZERO -X- QAnf
I 17
M 110.00 .RLO_ZERO -X- QAut
180 I 00
I 18

I 01
I 02
Programmable Safety Systems

I 03
I 04
I 05
I 06
I 07
0V
0V

Output relay : Segment 01

I 08 E2.08
I 09 : CAL SB 067
I 10
I 11
I 12 SB 067
I 13
I 14 DI RFK_K4
I 15
0V 04.06.96
0V
09.05
O16 + F309 APPROVED BLOCK
A2.16
O16 -
O17 +
O17 -
O18 +
O18 - KB 002 -B- SSNR FG -X- M 070.00
O19 + E 0.02 -X- RFK1 K -X- A 2.16
O19 -
24V E 0.02 -X- RFK2
0V E 2.08 -X- RSet
M 070.00 -X- EIN
O20 +
O20 -
O21 +
O21 -
O22 +
O22 -
O23 +
O23 -
24V
: BE

PSS DIOZ

Fig. 67: Typical failsafe program

Fig. 68 shows a typical program using three 2-channel E-Stops with
output feedback monitoring. The program can be written in
Statement List (as shown) or in Ladder Diagram.
OB101
zyklus
11.10.96
11.21

E - STOP : Segment 00
*********************************************************************************************************
All E-STOP buttons are monitored in this block segment
*********************************************************************************************************

: CAL SB 061

SB 061
NA_1
13.03.96
15.48
4AC8 APPROVED BLOCK

KB 001 -B- SSNR FG -X- M 070.00 . FG:E-STOP - 1

E 2.08 .Reset button -X- EIN
E 0.00 .E-STOP-1 S1_N/C -X- S1_Ö
E 0.01 .E-STOP-1 S1_N/C -X- S2_Ö
M 110.00 .RLO_ZERO -X- QAnf
M 110.00 .RLO_ZERO -X- QAut

: CAL SB 061
181
SB 061
NA_1

Programmable Safety Systems

13.03.95
15.48
4AC8 APPROVED BLOCK

KB 001 -B- SSNR FG -X- M 070.01 . FG:E-STOP - 2

E 2.08 .Reset button -X- EIN
E 2.09 .E-STOP-2 S1_N/C -X- S1_Ö
E 2.10 .E-STOP-2 S1_N/C -X- S2_Ö
M 110.00 .RLO_ZERO -X- QAnf
M 110.00 .RLO_ZERO -X- QAut

: CAL SB 061

SB 061
NA_1
13.03.96
15.48
4AC8 APPROVED BLOCK

KB 003 -B- SSNR FG -X- M 070.02 . FG:E-STOP - 3

E 2.08 .Reset button -X- EIN
E 2.11 .E-STOP-3 S1_N/C -X- S1_Ö
E 2.12 .E-STOP-3 S1_N/C -X- S2_Ö
M 110.00 .RLO_ZERO -X- QAnf
M 110.00 .RLO_ZERO -X- QAut
 E - STOP : Segment 01
*********************************************************************************************************
E-STOP buttons logically connected.
*********************************************************************************************************
:L M 070.00 .FG:E-STOP - 1
:U M 070.01 .FG:E-STOP - 2
:U M 070.02 .FG:E-STOP - 3
:= M 071.00 .FG:E-STOP - Logic
:

Output relay : Segment 02

*********************************************************************************************************
Output to relay 1K1.
*********************************************************************************************************
: CAL SB 067

SB 067
RFK_K4
04.06.96
09:05
F309 APPROVED BLOCK

KB 004 -B- SSNR FG -X- M 070.03 . FG:FL from 1K1

E 0.02 .FL from 1K1 -X- RFK1 K -X- A 2.16 . .Relay: 1k1
E 0.02 .FL from 1K1 -X- RFK2
E 2.08 .Reset button -X- RSet
M 071.00 .FG:E-STOP logic -X- Ein

MBS - Diagnostics : Segment 03

*********************************************************************************************************
The MBS block diagnostics are carried out in this block segment
182 *********************************************************************************************************
: CAL PB 001
Programmable Safety Systems

PB 001
CopyFehl
19.09.96
13.12

:A DB 15
:I DW 1015
:BE
:

Fig. 68: Typical program using three two-channel E-Stops with output feedback
monitoring