White Paper

Timing considerations on a safety PLC

1 The problem: Process Safety Time PES Time Settings ........... 2

2 Definitions ....................................................................................... 2
3 Relevant boundary conditions ....................................................... 4
3.1.1 Delays caused by logic .................................................................................................. 4
3.1.2 Probability of safety demand from the process (initiating event) ............................. 4
3.1.3 Probability of a fault, detected by the PES .................................................................. 4
3.1.4 Probability that the maximum cycle time occurs........................................................ 4

4 The options ..................................................................................... 5

4.1 Conservative approach to slow processes and any demand mode .................. 5
4.2 Approach to faster processes in low demand mode .......................................... 6
4.2.1 Justification for this approach ...................................................................................... 7
4.3 Approach to very fast processes in low demand mode ..................................... 8
4.3.1 Justification for this approach ...................................................................................... 8

5 Conclusions - Summary ............................................................... 10

5.1 1. Approach: Process Safety Time <> PES Safety Time ................................... 10
5.2 2. Approach: Process Safety Time <> PES Watchdog Time ............................ 10
5.3 3. Approach: Process Safety Time <> PES Response Time ............................ 10

Timing consideration on a safety PLC.docx Page 1/11

Copyright, HIMA Paul Hildebrandt GmbH. Any copy, even in extracts, are prohibited unless by permission from HIMA.
 1 The problem: Process Safety Time PES Time Settings

The end-user executes a risk analysis for his process and depending on that he writes a
Safety Requirement Specification (SRS).
Part of the description of safety functions in the SRS is the required Process Safety Time.

The Software Requirement Specification for a specific controller shall contain clear
statements about the expected timing in order to fulfill the SRS.

But very often this is leading to a difficult question: What is really the correct consideration?

PES Safety Time

Process Safety Time > PES Watchdog Time

PES Response Time

?
The answer is not easy and actually depending on certain circumstances and boundary
conditions!
Answering the question correctly could be essential for the decision whether the
safety PES can meet the timing specification or not or in other words whether the
safety PES can really make the job!

2 Definitions

Process Safety Time

Process Safety Time according IEC61511 is defined as:

Time period between a failure occurring in the process or the basic process control
system (with the potential to give rise to a hazardous event) and the occurrence of the
hazardous event if the SIF is not performed.

HIMA Safety Manual quotes:

The process safety time is a property of the process and describes the time interval during
which the process allows faulty signals to exist before the system state becomes dangerous.
A safety-related response of the HIMax PES including all delays due to sensors,
actuators, input and output modules must occur within the process safety time.

Summary:
The Process Safety Time is a process related parameter and must be determined by the
end-user.

Page 2/11 Timing consideration on a safety PLC.docx

Copyright, HIMA Paul Hildebrandt GmbH. Any copy, even in extracts, are prohibited unless by permission from HIMA.
PES (Controller) Safety Time

HIMA Safety Manual quotes:

The safety time of the resource is the maximum permissible time within which the resource
must react to a demand. The requirements are:
- Changes in process input signals from process.
- Faults occurring in the resource.

The HIMax system responds to faults that may result in a safety-critical operating state
within the configured safety time of the resource. It triggers predefined fault reactions that
bring the faulty parts to the safe state.

The requisites are:

- Delays caused by hardware, such as AI-modules or DI-modules, must be considered
additionally
- No input signal delay caused by delay elements configured in the input modules
(TON,TOF).
- No delay within the user program.
- The user program responds within one cycle of the PES
- No output noise blanking

Safety Time is also depending on the maximum expected cycle time in the controller.
The basic rules are:
Safety Time > 2 x Watchdog Time (satisfies safety only)
Safety Time > 3 x Watchdog Time (satisfies safety & availability)

In some systems, e.g. HIMax and HIquad, the reaction on a detected fault can be delayed
(suppressed) by installed Noise Blanking. This is basically a feature improving the
availability but safety must not be compromised.
The maximum delay (suppressing) time is the PES Safety Time.

Summary:
The PES Safety Time is the guaranteed reaction time of a safety PES in case of a demand
from the process comes along with an internal (detected) fault and along with a maximum
cycle time (= Watchdog Time).

Watchdog Time

HIMA Safety Manual quotes:

Watchdog Time is the maximum permissible duration of a RUN cycle (cycle time). If the
cycle time exceeds the preset watchdog time, the processor module enters the ERROR
STOP state.

Response Time

Assuming that no delay results from the configuration or the user program logic, the
response time of HIMax controllers running in cycles is twice the system cycle time +
module hardware delay.
The response time may not be greater than the process safety time.

Response Time calculation presumes normal load conditions (constant cycle time) and error
free system (no active noise blanking).

Timing consideration on a safety PLC.docx Page 3/11

Copyright, HIMA Paul Hildebrandt GmbH. Any copy, even in extracts, are prohibited unless by permission from HIMA.
Cycle Time

The CPU is processing several tasks, such as self-test, reading hardware inputs, reading
communication inputs, logic, writing hardware outputs, writing communication outputs.
The execution time for all tasks is called Cycle Time.

3 Relevant boundary conditions

3.1.1 Delays caused by logic

Logic must not cause unexpected delays. A typical source for such unexpected delay can be
bad read/write sequence of variables. The programmer must ensure that interconnecting
variables are written first in the cycle before the read function is executed. Otherwise
unexpectedly the value from the previous cycle is processed (= delay!).
Intentionally programmed delays, e.g. for surge suppression, increase the response time
additionally. This must be also taken into account.

All described approaches in this whitepaper basically exclude delays caused by logic!
.
3.1.2 Probability of safety demand from the process (initiating event)
Its always important to know the demand mode of the SIF.
High demand and continuous mode lead to a much higher probability of the initiating event
than low demand mode, which is typical in process industry.
Low demand mode in IEC 61508 is defined: the frequency of demands is not greater than
one per year

3.1.3 Probability of a fault, detected by the PES

In a thoroughly elaborated and maintained safety PES the probability of occurring faults is
very low.
Assuming also a thoroughly elaborated alarming concept exists, the end-user is supposed to
react on any reported fault very quickly and repair the safety system subsequently.
Because of existing Noise Blanking not every temporally fault is automatically leading to the
safe reaction of the PES, but frequently triggered Noise Blanking is always a clear sign that
something is wrong in the system and unexpected faults occur.
Assuming in a fault free safety system Noise Blanking are likely to not happen frequently
and shall be ignored!

3.1.4 Probability that the maximum cycle time occurs

Normally the cycle time in a safety controller is very constant, but several asynchronous
events could lead to unexpected load peaks:
- Logic (e.g. using loop-functionalities, C-Code, ST, EN-IN, etc.)
(impact on cycle time can be limited by parameter Max Duration for Each Cycle)
- Communication (safeethernet, Modbus etc.)
(Impact on cycle time can be limited by parameter Com.Time Slice)
- Reload
- Synchronization of a newly inserted CPU
- Ethernet interfaces affected by network problems

Page 4/11 Timing consideration on a safety PLC.docx

Copyright, HIMA Paul Hildebrandt GmbH. Any copy, even in extracts, are prohibited unless by permission from HIMA.
 Example: Load peak caused by synchronization

Probability estimation:

Synchronization in a running system means inserting a new (defective, exchanged) CPU.

This happens very rarely and the probability for that is insignificantly low.

Reload in a running safety system should also remain an exception.

In fact, a normal user cannot know the timing behavior during Reload. Basically it cannot be
excluded that Reload even causes several load peaks (close to the Watchdog Time limit)
one after another:

Therefore Reload must not be executed frequently during normal operation if the
expected response time does not consider minimum 2 x Watchdog Time.
See approach 4.2 and approach 4.3

4 The options
4.1 Conservative approach to slow processes and any demand mode

Process Safety Time > PES Safety Time

As a conservative (worst case) approach the Process Safety Time directly determines the
needed PES Safety Time. Therefore the known reaction times for the sensor, actuator and
I/O module must be considered and leading to the calculation:

PST minus delay sensor minus delay actuator minus I/O modules hardware delay
> PES Safety Time

This approach is even suitable if the following events all happen in parallel:

- Safety demand from the process +

- Fault detected by the PES +
- Maximum cycle time

Timing consideration on a safety PLC.docx Page 5/11

Copyright, HIMA Paul Hildebrandt GmbH. Any copy, even in extracts, are prohibited unless by permission from HIMA.
Therefore this is the appropriate approach if one or more of the following conditions cannot
be excluded or are basically unknown:

- Any demand mode, even high demand or continuous mode

- Faults often occur and cannot be avoided.

Bad diagnose (no, or late reaction in case of a fault).
(e.g. Nose Blanking is triggered often but ignored or not recognized)

- Cycle time is not constant. Frequent load peaks cannot be avoided or are not limited.

Since the PES Safety Time is the guaranteed response time of the PES under all
circumstances, the probability it fails time-wise is insignificant.

The lowest possible PES Safety Time mainly depends on the real existing load conditions in
the PES, in particular on the calculated Watchdog Time (remember factor 3!)
Because of this factor the (by the system) required value for PES Safety Time is often getting
relatively high (several seconds), even in fast safety systems such as HIMax.
As long as the above executed calculation leads to an acceptable result, this shall be the
preferred approach!

4.2 Approach to faster processes in low demand mode

Process Safety Time > 2 x PES Watchdog Time

In this popular approach the Process Safety Time directly determines the needed PES
Watchdog Time. Therefore the known reaction times for the sensor, actuator and I/O
module must be considered and leading to the calculation:

PST minus delay sensor minus delay actuator minus I/O modules hardware delay
> 2 x PES Watchdog Time

This approach is only suitable if the following preconditions are fulfilled:

- Low demand mode of the initiating event.

(Typical SIF in process industry have an expected demand rate of several years).

- Detected faults in the PES occur very seldom.

Thoroughly elaborated diagnose and well working alarming concepts makes sure that
the maintenance people are informed quickly and repair the safety system
subsequently.
Frequent fault indications, such as Noise Blanking, are not ignored.

- Any cycle time up to the maximum cycle time (= Watchdog Time) may occur.
Load peaks (single cycle), caused e.g. by Reload or Synchronization, are acceptable.
If 2 x Watchdog Time calculated also permanent high load conditions are acceptable.
See 3.1.4 Probability estimation

Practical hint for satisfying this precondition:

Dont execute frequent Reloads during normal operation!
Make sure logic cannot cause unexpected load peaks and all time budgets are
calculated, carefully set and taken into account.
Page 6/11 Timing consideration on a safety PLC.docx
Copyright, HIMA Paul Hildebrandt GmbH. Any copy, even in extracts, are prohibited unless by permission from HIMA.
 4.2.1 Justification for this approach
The relevant safety standards (e.g. IEC61511, IEC 61508) require a probabilistic calculation
of the SIF: Probability of failure on demand (PFD) for low demand mode.
This value expresses the probability a safety functions fails on demand and must be
sufficiently low. Target PFDavg according the standards:

There exists certain probability that the above mentioned preconditions are not fulfilled.
The SIF fails time-wise (means the response is taking longer than the assumed Watchdog
Time) if the process demand comes in parallel with a detected fault (triggering Noise
Blanking, which is limited by the Safety Time).
In this whitepaper this probability is called: PTF : Probability of Timing Failure

1. Example:
- PES cycle time is 40ms.
- Watchdog Time is 400ms
- Achieved Process Safety Time is 800ms + Sensor-/ Actuator-/ IO module hardware- delay
- The PES Safety Time is 3000ms
- One demand/year.
- One fault/year means one time in a year the response time on a demand can be up to
3000ms.
The probability for that is: 3000ms/31536000000ms(one year) = 9,51E-8 = PTFt
Normally this value must be added to the PFD(logic solver) but this particular value is again
insignificant because very low.

2. Example:
- PES cycle time is 40ms
- Watchdog Time is 400ms
- Achieved Process Safety Time is 800ms + Sensor-, Actuator-, IO module hardware - delay
- The PES Safety Time is 3000ms
- One demand/year.
- Noise Blanking is triggered 5 times/day 1825 times/year (disturbances, noise etc.)
Now 1825 times in a year the response time on a demand can be up to 3000ms.
The probability for that is: 1825x3000ms/31536000000ms(one year) = 1,73E-4 (PTF), which
is already 17% of SIL3!
This value cannot be ignored anymore!

The two examples show very well the impact of the mentioned boundary conditions.
The fault conditions in the second example are most likely not acceptable and would lead
back to the conservative approach (chapter 4.1) again.

The lowest possible Watchdog Time is mainly depending on the really existing load
conditions in the PES, in particular on the size of logic, amount of I/O modules and
communication load.

Timing consideration on a safety PLC.docx Page 7/11

Copyright, HIMA Paul Hildebrandt GmbH. Any copy, even in extracts, are prohibited unless by permission from HIMA.
Even in fast safety systems, such as HIMax, the calculated and needed Watchdog Time (see
Safety Manual) can be much higher than expected. Its not unusual that a system running a
constant cycle time of e.g. 40ms requires a Watchdog Time of e.g. 400ms.

If the above executed calculations/estimations are leading to acceptable results and

the above mentioned preconditions can be fulfilled, this approach is feasible.

4.3 Approach to very fast processes in low demand mode

Process Safety Time > PES Response Time

In this advanced approach the Process Safety Time directly determines the maximum
allowed PES Response Time. Therefore the known reaction times for the sensor, actuator
and I/O module must be considered and leading to the calculation:

PST minus delay sensor minus delay actuator minus I/O modules hardware delay
> PES Response Time (2 x PES cycle time)

This approach is only suitable if the following preconditions are fulfilled:

- Low demand mode of the initiating event.

(Typical SIF in process industry have an expected demand rate of several years).

- Detected faults in the PES occur very seldom.

Thoroughly elaborated diagnose and well working alarming concepts makes sure that
the maintenance people are informed quickly and repair the safety system directly.
Frequent fault indications, such as Noise Blanking are not ignored.

- Cycle time is on a constant level all the time.

Load peaks (single cycle), caused e.g. by Reload or Synchronization, are very, very
seldom. No permanent or more frequently high load conditions can occur.
See 3.1.4 Probability estimation

Practical hints for satisfying this precondition:

Avoid Reload during normal operation! Make sure logic cannot cause unexpected
load peaks and all time budgets are calculated, carefully set and considered.
The user must have a good knowledge about the existing timing, e.g. watching the
cycle time statistics for a longer time.

4.3.1 Justification for this approach

The SIF fails time-wise (means the real response is taking longer than the calculated
Response Time) if the process demand comes in parallel with a detected fault (triggering
Noise Blanking, which is limited by the Safety Time) and the real cycle time is much longer
than calculated for the Response Time

1. Example:
- PES cycle time is 40ms.
- Watchdog Time is 400ms
Page 8/11 Timing consideration on a safety PLC.docx
Copyright, HIMA Paul Hildebrandt GmbH. Any copy, even in extracts, are prohibited unless by permission from HIMA.
- Achieved Process Safety Time is 80ms + Sensor-/ Actuator-/ IO module hardware- delay
- The PES Safety Time is 3000ms
- One demand/year.
- One fault/year means one time in a year the response time on a demand can be up to
3000ms.
- No Reloads are executed and no Synchronization happens.
The probability for that is: 3000ms/31536000000ms(one year) = 9,51E-8 = PTF
Normally this value must be added to the PFD(logic solver) but this particular value is again
insignificant because very low.

2. Example:
- PES cycle time is 40ms.
- Watchdog Time is 400ms
- Achieved Process Safety Time is 80ms + Sensor-/ Actuator-/ IO module hardware- delay
- The PES Safety Time is 3000ms
- One demand/year.
- One fault/year means one time in a year the response time on a demand can be up to
3000ms. The probability for that is still:
3000ms/31536000000ms(one year) = 9,51E-8 (PTFfault)

Lets assume Reloads are executed frequently.( 2 times/week). During Reload many cycles
one after another are close to the Watchdog Time limit. Lets assume this phase takes 1
Minute per Reload (which is not unusual but can even be much longer).
Now 54 minutes in a year the response time on a demand can be up to twice the Watchdog
Time much more than the expected Response Time.
The total duration of high cycle times in a year is 52x60x1000ms = 312000ms
The probability for that is:312000ms/31536000000ms(one year) = 9,89E-5 (PTFReload).
This value cannot be ignored anymore!

For the PFD(logic solver) the added value must be considered: PTFtotal = PTFfault + PTFReload

3. Example:
- PES cycle time is 40ms.
- Watchdog Time is 400ms
- Achieved Process Safety Time is 80ms + Sensor-/ Actuator-/ IO module hardware- delay
- The PES Safety Time is 3000ms
- One demand/year.
- Noise Blanking is triggered 5 times/day 1825 times/year (disturbances, noise etc.)
- Reloads are also executed frequently.( 5 times/week)

PTFfault =1,73E-4,
PTFReload = 15600000ms/31536000000ms = 4,94E-4
PTFtotal = PTFfault + PTFReload = 6,67E-4

This is already 66% of SIL3!

This value cannot be ignored anymore!

The examples show again very well the impact of the mentioned boundary conditions.
The conditions in the third example are most likely not acceptable and would lead back to the
conservative approach (chapter 4.1).

If the above executed calculations/estimations are leading to acceptable results and

the above mentioned preconditions can be fulfilled, this approach is feasible.

Timing consideration on a safety PLC.docx Page 9/11

Copyright, HIMA Paul Hildebrandt GmbH. Any copy, even in extracts, are prohibited unless by permission from HIMA.
 5 Conclusions - Summary
5.1 1. Approach: Process Safety Time <> PES Safety Time

Process Safety Time > PES Safety Time (e,g. 3000ms)

Properties, advantages and boundary conditions:

- Low demand, high demand mode or continuous mode

- Preferred approach
- Worst case consideration
- No preconditions regarding demand mode, fault condition or maximum cycle time
- Satisfied Process Safety Time is relatively high (in example 3000ms)
- Not suitable for fast processes

5.2 2. Approach: Process Safety Time <> PES Watchdog Time

Process Safety Time > 2 x PES Watchdog Time (e.g 800ms)

Properties, advantages and boundary conditions:

- Only low demand mode

- Fault free system assumed
- Fast reaction on any reported fault and subsequently repair must be guaranteed
- Well known timing behavior of the PES required
- Thoroughly elaborated timing settings required
- Satisfied Process Safety Time can be lower (in example 800ms)
- Suitable for faster processes

5.3 3. Approach: Process Safety Time <> PES Response Time

Process Safety Time > PES Response Time (e.g. 80ms)

Properties, advantages and boundary conditions:

- Only low demand mode

- Fault free system assumed
- Fast reaction on any reported fault and subsequently repair must be guaranteed
- Very good knowledge about the real existing timing in the PES required
- Professionally calculated timing settings required
- Reloads during operation are very seldom (basically not planned and only an
exception)
- Satisfied Process Safety Time can be very low (in example 80ms)
- Suitable for very faster processes

Page 10/11 Timing consideration on a safety PLC.docx

Copyright, HIMA Paul Hildebrandt GmbH. Any copy, even in extracts, are prohibited unless by permission from HIMA.
The Author

Mr. Eugen Kull is a senior technical system trainer in the Training and Customer Service
department ECTC of HIMA. He started with HIMA in the year 2000 and is meanwhile
responsible for advanced technical education of HIMA employees worldwide.
Mr. Eugen Kull is also involved in several product development projects, member of HIMA
Customer Support Team, technical consultant for nuclear customers and a system expert for
HIMA PES, especially HIMax.

Contact

HIMA Paul Hildebrandt GmbH

Eugen Kull

Albert-Bassermann-Str. 28
68782 Brhl, Germany
Tel.: +49 6202 709-428
Fax: +49 6202 709-199
e.kull@hima.com
www.hima.com

Timing consideration on a safety PLC.docx Page 11/11

Copyright, HIMA Paul Hildebrandt GmbH. Any copy, even in extracts, are prohibited unless by permission from HIMA.