Sei sulla pagina 1di 26
Safety Performance Levels Transition from EN954-1 to EN ISO 13849-1
Safety Performance Levels Transition from EN954-1 to EN ISO 13849-1
Safety Performance Levels Transition from EN954-1 to EN ISO 13849-1
Safety Performance Levels Transition from EN954-1 to EN ISO 13849-1

Safety Performance Levels

Transition from EN954-1 to EN ISO 13849-1

Safety Performance Levels Transition from EN954-1 to EN ISO 13849-1

FUNCTIONAL SAFETY

Transition from EN 954-1 to EN ISO 13849-1

INTRODUCTION

This publication is intended to shed some light on the recent and upcoming changes in the legislation and standards that apply to the safety of machinery. It is focused on the EU requirements but, due to the increasing globalisation of machinery safety standards, much of the content is relevant worldwide.

Machinery and processes continue to become faster, more flexible and more powerful. In order to offer the continued safety of operators and technicians protective measures have, in turn, evolved to keep pace with the increasing complexity of automation. Traditionally, safety systems have been implemented separately to automation systems, operating independently and often in parallel to the automation system. There is good reason for this; the safety system must always be available. A fault or unexpected occurrence in the "normal" operation of the machine must not degrade or compromise the safety protective measures.

However it is an inescapable fact that as automation systems become more intelligent then so must the safety system. What is required for safer functionality increasingly depends on what the machine is doing or what mode it is in. This means that "safety" has, in some way, to communicate with the "normal" control system. That means that we need to reconsider how we achieve the independence and integrity of the safety system. One of the most significant manifestations of this is a new generation of standards commonly referred to as Functional Safety Standards. In this publication we will consider one of the most significant of them: EN ISO 13849-1. In addition to this, there is a new Machinery Directive in the EU that looks to keep the legislative landscape relevant to the contemporary industrial environment.

For anyone supplying machines or using them it is important to keep informed of the relevant standards and regulatory requirements. This publication is intended to assist in that task especially with regard to control system aspects. It is not a substitute for a detailed study of the specific provisions detailed in the standards and legislation. It is intended to give an overview and hopefully it will help to give some clarity on what is required.

1

and legislation. It is intended to give an overview and hopefully it will help to give
The migration from EN 954-1 to EN ISO 13849-1 For many years the most common

The migration from EN 954-1 to EN ISO 13849-1

For many years the most common way of classifying safety related systems has been to use the Categories of EN 954-1 [or its counterpart ISO 13849-1:1999]. This standard will be withdrawn. The main implications of this is that the standard will not longer be used to show conformity with the Machinery Directive.

A new standard to replace EN 954-1 has already been published. It is EN ISO

13849-1:2008. “Safety of machinery - Safety related parts of control systems". There

is also an alternative standard that can be used: EN/IEC 62061 "Safety of

machinery - Functional safety of electrical, electronic and programmable electric control systems. Either of these standards can be used to show conformity with the Machinery Directive. In this publication we will consider the relationship between the two standards where relevant. The choice of which one to use is left to the user but we will concentrate on EN ISO 13849-1:2008. It has been specifically drafted to provide a transition path for system designers who have been using Categories and therefore it is likely to become the most commonly used standard for machine safety systems. It can be used either for a complete system or for a subsystem.

Basic differences between EN 954-1 and EN ISO 13849-1

Firstly let's have look at what are the basic differences between the old EN 954-1 and the new EN ISO 13849-1. The outputs of the old standard were Categories [B,

1, 2, 3 or 4]. The outputs of the new standard are Performance Levels [PL a, b, c, d

or e]. The Category concept is retained but there are additional requirements to be satisfied before a PL can be claimed for a system.

The requirements can be listed in basic form as follows:

• The architecture of the system. Essentially this captures what we have become used to as the Categories.

• Reliability data is required for the constituent parts of the system.

• The Diagnostic Coverage [DC] of the system is required. This effectively represents the amount of fault monitoring in the system.

• Protection against common cause failure.

• Protection against systematic faults

• Where relevant, specific requirements for software.

2

FUNCTIONAL SAFETY

Transition from EN 954-1 to EN ISO 13849-1

Later we will take a closer look at these factors but before we do it will be useful to consider the basic intent and principle of the whole standard. It is clear at this stage that there are new things to learn but the detail will make more sense once we have understood what it is trying to achieve and why.

First of all why do we need the new standard? It is obvious that the technology used in machine safety systems has progressed and changed considerably over the last ten years. Until relatively recently safety systems have depended on "simple" equipment with very foreseeable and predictable failure modes. More recently we have seen an increasing use of more complex electronic and programmable devices in safety systems. This has given us advantages in terms of cost, flexibility and compatibility but it has also meant that the pre-existing standards are no longer adequate. In order to know whether a safety system is good enough we need to know more about it. This is why the new standard asks for more information. As safety systems start to use a more "black box" approach we start to rely more heavily on their conformity to standards. Therefore those standards need to be capable of properly interrogating the technology. In order to fulfil this they must speak to the basic factors of reliability, fault detection, architectural and systematic integrity. This is the intent of EN ISO 13849-1.

In order to plot a logical course through the standard it is important to realise that it has two fundamentally different user types: the designer of safety related subsystems and the designers of safety related systems. In general the subsystem designer [typically a safety component manufacturer] will be subjected to a higher level of complexity. They will need to provide the required data in order that the system designer can ensure that it is of adequate integrity for the system. This will usually require some testing, analysis and calculation. The results will be expressed in the form of the data required by the standard.

The system designer [typically a machine designer or integrator] will use this data to perform some relatively straightforward calculations to determine the overall Performance Level [PL] of the system.

In order to determine what PL is required [PLr] the standard provides risk graph into which the application factors of severity of injury, frequency of exposure and possibility of avoidance are input.

The output is the PLr. Users of the old EN 954-1 will be familiar with this approach but take note that the S1 line now subdivides whereas the old risk graph did not. Note that this means a possible reconsideration of the integrity of safety measures required at lower risk levels.

3

not. Note that this means a possible reconsideration of the integrity of safety measures required at
Start P1 a F1 P2 S1 b P1 F2 P2 P1 c F1 P2 S2

Start

P1 a F1 P2 S1 b P1 F2 P2 P1 c F1 P2 S2 P1
P1
a
F1
P2
S1
b
P1
F2
P2
P1
c
F1
P2
S2
P1
d
F2
P2
e

Risk Graph from Annex A of EN ISO 13849-1

S1

   
S1    
     
S1               P1   F1     S2    
S1               P1   F1     S2    
   

P1

 

F1

   
  F1    
  F1    

S2

 
S2  
       
       
     
     
     
 

F2 P2

       

Risk Graph from Annex B of EN 945-1

So now we can see the direct relation between the PLr of the system [from the risk graph] and the PL achieved by the system [by calculation].

There is one very important part yet to be covered however. We now know from the standard how good the system needs to be and also how to determine how good it is but we don't know what it needs to do. We need to decide what the safety function is. Clearly the safety function must be appropriate to the task so how do we provide this? How does the standard help us?

It is important to realise that the functionality required can only be determined by considering the characteristics prevailing at the actual application. This can be regarded the safety concept design stage. It cannot be completely covered by the standard because the standard does not know about all the characteristics of a specific application. This also often applies to the machine builder who produces the machine but does not necessarily know the exact conditions under which it will be used.

The standard does provide some help by listing out many of the commonly used safety functions and giving some normally associated requirements. Other standards such as EN ISO 12100: Basic design principles and EN ISO 14121:

Risk assessment, are highly recommended for use at this stage. Also there is a large range of machine specific standards that will provide solutions for specific machines. Within the European EN standards they are termed C type standards, most of them have exact equivalents in ISO standards.

So we can now see that the safety concept design stage is dependent on the type of machine and also on the characteristics of the application and environment in which it is used. The machine builder will anticipate these factors in order to be able to design the safety concept. The intended [i.e. anticipated] conditions of use should

4

FUNCTIONAL SAFETY

Transition from EN 954-1 to EN ISO 13849-1

be given in the user manual. The user of the machine needs to check that they match the actual usage conditions.

So now we have a description of the safety functionality. From annex A of the standard we also have the required performance level [PLr] for the safety related parts of the control system [SRP/CS] that will be used to implement this functionality. We now need to design the system and make sure that it complies with the PLr.

One of significant factors in the decision of which standard to use [EN ISO 13849-1 or EN/IEC 62061] is the complexity of the safety function. In most cases, for machinery, the safety function will be relatively simple and EN ISO 13849-1 will be the most suitable route. In order to asses the PL it uses the factors already mentioned; reliability data, diagnostic coverage [DC], the system architecture [Category] and where relevant, requirements for software.

This is a simplified description meant only to give an overview. It is important to understand that all the provisions given in the body of the standard must be applied. However, help is at hand. There is an excellent software tool available to help us with the calculation aspects. It is called SISTEMA. It is produced by the BGIA in Germany. It is available free for use and download details can be found at:

www.dguv.de/bgia/en/pra/softwa/sistema

At time of going to print of this publication it is available in German and English, with other languages being released in the near future. This tool is not commercially produced. BGIA, the developer of SISTEMA, is a well-respected research and testing institution based in Germany. It is particularly involved in solving scientific and technical problems relating to safety in the context of statutory accident insurance and prevention in Germany. It works in cooperation with occupational health and safety agencies from over twenty countries. Specialists from BGIA, along with their BG colleagues had significant participation in the drafting of both EN ISO 13849-1 and IEC/EN 62061.

Rockwell Automation ® data for use with SISTEMA

A Rockwell Automation “library” of its safety devices is available for use with the SISTEMA Performance Level calculation tool. To obtain this library please logon to:

www.discoverrockwellautomation.com/safety

Whichever way the calculation of the PL is done it is important to start of from the right foundation. We need to view our system in the same way as the standard so let's start with that.

5

of from the right foundation. We need to view our system in the same way as
SYSTEM STRUCTURE Input Logic Output Subsystem Subsystem Subsystem Any system can be split into basic

SYSTEM STRUCTURE

Input

Logic

Output

Subsystem

Subsystem

Subsystem

Any system can be split into basic system components or "subsystems". Each subsystem has its own discrete function. Most systems can be split into three basic functions; input, logic solving and actuation [some simple systems may not have logic solving]. The component groups that implement these functions are the subsystems.

Input

Subsystem

Output

Subsystem

Limit Switch Safety Contactor
Limit Switch Safety Contactor
Limit Switch Safety Contactor

Limit Switch

Safety Contactor

Interlock switch and safety contactor

A simple single channel electrical system example is shown above. It comprises only input and output subsystems.

Input

Subsystem

Logic

Subsystem

Output

Subsystem

Limit Switch

Limit Switch

Limit Switch  
Limit Switch  
 
Limit Switch  
Limit Switch  
     
   

Outputto other

to otherOutput Output

SmartGuard 600

systems

Safety Contactor

Interlock switch, safety controller and safety contactor

The system is a little more complex because some logic is also required. The safety controller itself will be fault tolerant (e.g. dual channel) internally but the overall system is still limited to single channel status because of the single limit switch and single contactor.

6

FUNCTIONAL SAFETY

Transition from EN 954-1 to EN ISO 13849-1

Input

Subsystem

Logic

Subsystem

Output

Subsystem

Limit Switch

Limit Switch

Limit Switch
Limit Switch
Limit Switch
Limit Switch
Limit Switch
Limit Switch SmartGuard 600 Safety Contactor

SmartGuard 600

Safety Contactor

Safety Contactor

Dual channel safety system

Taking the basic architecture of the previous diagram, there are also some other things to consider. Firstly how many "channels" does the system have? A single channel system will fail if one of its subsystems fails. A two channel [also called redundant] system would need to have two failures, one in each channel before the system fails. Because it has two channels it can tolerate a single fault and still keep working. The diagram above shows a two channel system.

Clearly a dual channel system is less likely to fail to a dangerous condition than a single channel system. But we can make it even more reliable [in terms of its safety function] if we include diagnostic measures for fault detection. Of course, having detected the fault we also need to react to it and put the system into a safe state. The following diagram shows the inclusion of diagnostic measures achieved by monitoring techniques.

Input

Subsystem

Logic

Subsystem

Output

Subsystem

Monitoring Monitoring Monitoring Limit Switch SmartGuard 600 Safety Contactor
Monitoring
Monitoring
Monitoring
Limit Switch
SmartGuard 600
Safety Contactor

Diagnostics with a dual channel safety system

7

Monitoring Monitoring Limit Switch SmartGuard 600 Safety Contactor Diagnostics with a dual channel safety system 7
It is usually [but not always] the case that the system comprises two channels in

It is usually [but not always] the case that the system comprises two channels in all its subsystems. Therefore we can see that, in this case each subsystem has two "sub channels". The standard describes these as "blocks". A two channel subsystem will have a minimum of two blocks and a single channel subsystem will have a minimum of one block. It is possible that some systems will comprise a combination of dual channel and single channel blocks.

If we want to investigate the system in more depth we need to look at the components parts of the blocks. The SISTEMA tool uses the term "elements" for these component parts.

Input Logic Output Element Element Subsystem Subsystem Subsystem Block Monitoring Linkage Contacts Linkage
Input
Logic
Output
Element
Element
Subsystem
Subsystem
Subsystem
Block
Monitoring
Linkage
Contacts
Linkage
Contacts
Block
Monitoring
Limit Switch
SmartGuard 600
Safety Contactor
Element
Element
Diagnostics
Diagnostics
Subdivided system with diagnostics with a dual channel safety system
CHANNEL 1CHANNEL
2
Monitoring

The limit switches subsystem is shown subdivided down to its element level. The output contactor subsystem is subdivided down to its block level and the logic subsystem is not subdivided at all. The monitoring function for both the limit switches and the contactors is performed at the logic controller. Therefore the boxes representing the limit switch and contactor subsystems have a small overlap with the logic subsystem box.

This principle of system subdivision can be recognised in the methodology given in EN ISO 13849-1 and in the basic system structure principle for the SISTEMA tool. However it is important to note that there are some subtle differences. The standard is not restrictive in its methodology but for the simplified method for estimating the PL the usual first step is to break the system structure into channels and the blocks within each channel. With SISTEMA the system is usually first divided into subsystems. The standard does not explicitly describe a subsystem concept but its

8

FUNCTIONAL SAFETY

Transition from EN 954-1 to EN ISO 13849-1

use as given in SISTEMA provides a more understandable and intuitive approach. Of course there is no effect on the final calculation. SISTEMA and the standard both use the same principles and formulae. It is also interesting to note that the subsystem approach is also used in EN/IEC 62061.

The system we have been using as an example is just one of the five basic types of system architectures that the standard designates. Anyone familiar with the Categories system will recognise our example as representative of either Category 3 or 4.

The standard uses the original EN 954-1 Categories as its five basic types of designated system architectures. It calls them Designated Architecture Categories. The requirements for the Categories are almost [but not quite] identical to those given in EN 954-1. The Designated Architecture Categories are represented by the following figures. It is important to note that they can be applied either to a complete system or a subsystem. The diagrams should not be taken purely as a physical structure, they are intended more as a graphical representation of conceptual requirements.

Input Logic Output Device Device Designated Architecture Category B
Input
Logic
Output
Device
Device
Designated Architecture Category B

Designated Architecture Category B must use basic safety principles [see annex of EN ISO 13849-2]. The system or subsystem can fail in the event of a single fault. See EN ISO 13849-1 for full requirements.

Input Logic Output Device Device Designated Architecture Category 1
Input
Logic
Output
Device
Device
Designated Architecture Category 1

Designated Architecture Category 1 has the same structure as Category B and can still fail in the event of a single fault. But because it must also use well tried safety principles [see annex of EN ISO 13849-2] this is less likely than for Category B. See EN ISO 13849-1 for full requirements.

9

[see annex of EN ISO 13849-2] this is less likely than for Category B. See EN
Input Wiring Logic Wiring Device     Test Output Device Monitoring Test Output

Input

Wiring

Input Wiring Logic Wiring

Logic

Wiring

Device

   
Input Wiring Logic Wiring Device    
Input Wiring Logic Wiring Device    
Wiring Logic Wiring Device     Test Output Device Monitoring Test Output Designated

Test

Output Device
Output
Device

Monitoring

Test

Output

Designated Architecture Category 2

Designated Architecture Category 2 must use basic safety principles [see annex of EN ISO 13849-2]. There must also be diagnostic monitoring via a functional test of the system or subsystem. This must occur at start up and then periodically with a frequency that equates to at least one hundred tests to every demand on the safety function. The system or subsystem can still fail if a single fault occurs between the functional tests but this is usually less likely than for Category 1. See EN ISO 13849-1 for full requirements.

Wiring Wiring Input Logic Output Device Device Monitoring Cross Monitoring Wiring Wiring Input Logic Output
Wiring
Wiring
Input
Logic
Output
Device
Device
Monitoring
Cross
Monitoring
Wiring
Wiring
Input
Logic
Output
Device
Device
Monitoring

Designated Architecture Category 3

Designated Architecture Category 3 must use basic safety principles [see annex of EN ISO 13849-2]. There is also a requirement that the system / subsystem must not fail in the event of a single fault. This means that the system needs to have single fault tolerance with regard to its safety function. The most common way of achieving this requirement it to employ a dual channel architecture as shown above. In addition to this it is also required that, wherever practicable, the single fault should be detected. This requirement is the same as the original requirement for Category

10

FUNCTIONAL SAFETY

Transition from EN 954-1 to EN ISO 13849-1

3 from EN 954-1. In that context the meaning of the phrase "wherever practicable" proved somewhat problematic. It meant that Category 3 could cover everything from a system with redundancy but no fault detection [often descriptively and appropriately termed "stupid redundancy"] to a redundant system where all single faults are detected. This issue is addressed in EN ISO 13849-1 by the requirement to estimate the quality of the Diagnostic Coverage [DC]. We can see that the greater the reliability [MTTFd] of the system, the less the DC we need. However it is also clear that the DC needs to be at least 60% for Category 3 Architecture.

Wiring Wiring Input Logic Output Device Device Monitoring Cross Monitoring Wiring Wiring Input Logic Output
Wiring
Wiring
Input
Logic
Output
Device
Device
Monitoring
Cross
Monitoring
Wiring
Wiring
Input
Logic
Output
Device
Device
Monitoring

Designated Architecture Category 4

Designated Architecture Category 4 must use basic safety principles [see annex of EN ISO 13849-2]. It has a similar requirements diagram to Category 3 but it demands greater monitoring i.e. higher Diagnostic Coverage. This is shown by the heavier dotted lines representing the monitoring functions. In essence the difference between Categories 3 and 4 is that for Category 3 most faults must be detected but for Category 4 all single faults must be detected. The DC needs to be at least 99%. Even combinations of faults must not cause a dangerous failure.

RELIABILITY DATA

EN ISO 13849-1 uses quantitative reliability data as part of the calculation of the PL achieved by the safety related parts of a control system. This is a significant departure from EN 954-1. The first question this raises is "where do we get this data from?" It is possible to use data from recognised reliability handbooks but the standard makes it clear that the preferred source is the manufacturer. To this end, Rockwell Automation is making the relevant information available in the form of a data library for SISTEMA. In due course it will also publish the data in other forms. Before we go any further we should consider what types of data are required and also gain an understanding of how it is produced.

11

go any further we should consider what types of data are required and also gain an
The ultimate type of data required as part of the PL determination in the standard

The ultimate type of data required as part of the PL determination in the standard [and SISTEMA] is the PFH [the probability of dangerous failure per hour]. This is the same data as represented by the PFHd abbreviation used in IEC/EN 62061.

PL

PFHD (Probability of dangerous failure per hour)

SIL

(Performance Level)

(Safety Integrity

Level)

A

≥10 5 to <10 4

None

B

≥3 x 10 6 to <10 5

1

C

≥10 6 to <3 x 10 6

1

D

≥10 7 to <10 6

2

E

≥10 8 to <10 7

3

The table above shows the relationship between PFH and PL and SIL. For some subsystems the PFH may be available from the manufacturer. This makes life easier for the calculation. The manufacturer will usually have to perform some relatively complex calculation and/or testing on their subsystem in order to provide it. In the event that it is not available, EN ISO13849-1 gives us an alternative simplified approach based on the average MTTFd [mean time to a dangerous failure] of a single channel. The PL [and therefore the PFH] of a system or subsystem can then be calculated using the methodology and formulae in the standard. It can be done even more conveniently using SISTEMA.

MTTFd

This represents the average mean time before the occurrence of a failure that could lead to the failure of the safety function. It is expressed in years. It is an average value of the MTTFd's of the "blocks" of each channel and can be applied to either a system or a subsystem. The standard gives the following formula which is used to calculate the average of all the MTTFd's of each element used in a single channel or subsystem.

At this stage the value of SISTEMA becomes apparent. Users are spared time consuming consultation of tables and calculation of formulae since these tasks are performed by the software. The final results can be printed out in the form of a multiple page report.

12

FUNCTIONAL SAFETY

Transition from EN 954-1 to EN ISO 13849-1

1

=

MTTF d

where

Ñ

Σ

i=1

1

MTTF di

Ñ

= Σ

j=1

nj

MTTF dj

(D.1)

MTTFd is for the complete channel;

MTTFdi, MTTFdj is the MTTFd of each component which has a contribution to the safety function.

The first sum is over each component separately; the second sum is an equivalent, simplified from where all nj identical components with the same MTTFdi are grouped together.

In most dual channel systems both channel are identical therefore the result of the formula represents either channel. If the system/subsystem channels are different the standard provides a formula to cater for this.

MTTF

d

2

= 3

MTTF +MTTF

dC1

dC2

1 1 1 + MTTF dC1 MTTF dC2
1
1
1
+
MTTF dC1 MTTF dC2

(D.2)

where MTTFdC1 and MTTFdC2 are the values for two different redundant channels.

This, in effect, averages the two averages. In the cause of simplification it is also allowable to just use the worst case channel value.

The standard groups the MTTFd into three ranges as follows:-

3 to <10 years = low

10

to <30 years = medium

30

to 100 years = high

As we will see later, the achieved range of MTTFd average is then combined with the designated architecture Category and the diagnostic coverage [DC] to provide a preliminary PL rating. The term preliminary is used here because other requirements including systematic integrity and measures against common cause failure still have to be met where relevant.

13

including systematic integrity and measures against common cause failure still have to be met where relevant.
Methods of Data Determination We now need to delve one stage deeper into how a

Methods of Data Determination

We now need to delve one stage deeper into how a manufacturer determines the data either in the form of PFHd or MTTFd. An understanding of this is essential when dealing with manufacturers data. Components can be grouped into three basic types:

• Mechanistic (Electro-mechanical, mechanical, pneumatic, hydraulic etc)

• Electronic (i.e. solid state)

• Software

There is a fundamental difference between the common failure mechanisms of these three technology types. In basic form it can be summarised as follows:-

MECHANISTIC TECHNOLOGY -

Failure is proportional to both the inherent reliability and the usage rate. The greater the usage rate, the more likely that one of the component parts may be degraded and fail. Note that this is not the only failure cause, but unless we limit the operation time/cycles it will be the predominant one. It is self evident that a contactor that has switching cycle of once per ten seconds will operate reliably for a far shorter time than an identical contactor that operates one per day. Mechanistic technology devices generally comprise components that are individually designed for their specific use. The components are shaped, moulded, cast, machined etc. They are combined with linkages, springs, magnets, electrical windings etc to form a mechanism. Because the component parts do not, in general, have any history of use in other applications, we cannot find any pre-existing reliability data for them. The estimation of the PFHd or MTTFd for the mechanism is normally based on testing. Both EN/IEC 62061 and EN ISO 13849-1 advocate a test process known as B10d Testing.

In the B10d test a number of device samples [usually at least ten] are tested under suitably representative conditions. The mean number of operating cycles achieved before 10% of the samples fail to the dangerous condition is known as the B10d value. In practice it is often the case that all of the samples will fail to a safe state but in that case it is clarified in that standard the B10d[dangerous] value can be taken as twice the B10[safe] value.

14

FUNCTIONAL SAFETY

Transition from EN 954-1 to EN ISO 13849-1

ELECTRONIC TECHNOLOGY -

There are no physical wear related moving parts. Given an operating environment commensurate with the specified electrical, temperature [etc] characteristics, the predominant failure of an electronic circuit is proportional to the inherent reliability of its constituent components [or lack off it]. There are many reasons for individual component failure; imperfection introduced during manufacture, excessive power surges, mechanical connection problems etc. In general, faults in electronic components are difficult to predict by analysis and they appear to be random in nature. Therefore testing of an electronic device in test laboratory conditions will not necessarily reveal typical long term failure patterns.

In order to determine the reliability of electronic devices it is usual to use analysis and calculation. We can find good data for the individual components in reliability data handbooks. We can use analysis to determine which component failure modes are dangerous. It is acceptable and usual to average out the component failure modes as 50% safe and 50% dangerous. This normally results in relatively conservative data.

IEC 61508 provides formulae that can be used to calculate the overall probability of dangerous failure [PFH or PFD] of the device i.e. the subsystem. The formulae are quite complex and take into account [where applicable] component reliability, potential for common cause failure [beta factor], diagnostic coverage [DC], functional test interval and proof test interval. The good news is that this complex calculation will normally be done by the device manufacturer. Both EN/IEC 62061 and EN ISO 13849-1 accept a subsystem calculated in this way to IEC 61508. The resulting PFHd can be used directly into either Annex K of EN ISO 13849-1 or the SISTEMA calculation tool.

SOFTWARE -

Failures of software are inherently systematic in nature. Any failures are caused by the way it is conceived, written or compiled. Therefore all failures are caused by the system under which it is produced, not by its use. Therefore in order to control the failures we must control that system. Both IEC 61508 and EN ISO 13849-1 provide requirements and methodologies for this. We do not need to go into detail here other than to say they use the classic V model.

15

and methodologies for this. We do not need to go into detail here other than to
Safety-related Safety Validated software Validation Validation functions software specification specification
Safety-related Safety Validated software Validation Validation functions software specification specification
Safety-related
Safety
Validated
software
Validation
Validation
functions
software
specification
specification
System
Integration
design
testing
Module
Module
design
testing
Result
Coding
Verification
V model for software development

Embedded software is an issue for the designer of the device. The usual approach is to develop embedded software in accordance with the formal methods layed out in IEC 61508 part 3. When it comes to application code, the software that a user interfaces with, most programmable safety devices are provided with "certified" function blocks or routines. This simplifies the validation task for application code but it must be remembered that the completed application program still needs to be validated. The way the blocks are linked and parameterised must be proved correct and valid for the intended task. EN ISO 13849-1 and IEC/EN 62061 Both provide guidelines for this process.

16

FUNCTIONAL SAFETY

Transition from EN 954-1 to EN ISO 13849-1

Diagnostic Coverage

We have already touched on this subject when we considered the Designated

Architecture Categories 2, 3 and 4. Those Categories require some form of diagnostic testing to check whether the safety function is still working. The term "diagnostic coverage" [usually abbreviated to DC] is used to characterise the

effectiveness of this testing. It is important to realise that DC is not based just on

the number of components that can fail dangerously. It takes account of the total

dangerous failure rate. The symbol λ is used for "failure rate". DC expresses the relationship of the rates of occurrence of the two following types of dangerous failure;

Dangerous detected failure [λdd] i.e. Those failures that would cause, or could lead to, a loss of the safety function, but which are detected. After detection, a fault reaction function causes the device or system to go to safe state.

Dangerous failure [λd] i.e. All those failures that could potentially cause, or lead to, a loss of the safety function. This includes both the failures that are detected

and

those that are not. Of course the failures that are that are truly dangerous

are

the dangerous undetected ones [termed λdu]

DC is expressed by the formula;

DC = λdd/λd expressed as a percentage.

This meaning of the term DC is common to EN ISO 13849-1 and EN/IEC 62061. However the way that it is derived differs. The latter standard proposes the use of calculation based on failure mode analysis but EN ISO 13849-1 provides a simplified method in the form of look-up tables. Various typical diagnostic techniques

are listed together with the DC percentage that their use is deemed to achieve. In

some cases rational judgment is still required, for example in some techniques the achieved DC is proportional to how often the test is performed. It is sometimes argued that this approach is too vague. However the estimation of DC can depend on many different variables and whichever technique is used the result can usually only truly be described as approximate.

17

many different variables and whichever technique is used the result can usually only truly be described
It is also important to understand that the tables in EN ISO 13849-1 are based

It is also important to understand that the tables in EN ISO 13849-1 are based on extensive research conducted by the BGIA into the results achieved by known actual diagnostic techniques used in real applications. In the interest of simplification the standard divides DC into four basic ranges.

<60% = none

60% to <90% = low

90% to <99% = medium

≥99% = high

This approach of dealing with ranges instead of individual percentage values also can be considered to be more realistic in terms of achievable accuracy. The SISTEMA tool uses the same look-up tables as the standard. As the use of complex electronics increases in safety related devices, DC becomes a more important factor. It is likely that future work on the standards will look further into clarification of this issue. In the meantime the use of engineering judgment and common sense should be sufficient to lead to the correct choice of DC range.

Common Cause Failure

In most dual channel [i.e. single fault tolerant] systems or subsystems the diagnostic principle is based on the premise that there will not be dangerous failures of both channels at the same time. The term "at the same time" is more accurately expressed as "within the diagnostic test interval". If the diagnostic test interval is reasonably short [e.g. less than eight hours] it is a reasonable assumption that two separate and unrelated faults are highly unlikely to occur within that time. However the standard makes it clear that we need to think carefully about whether the fault possibilities really are separate and unrelated. For example, if a fault in one component can foreseeably lead to failures of other components then the resulting totality of faults are deemed to be a single failure.

It is also possible that an event that causes one component to fail may also cause the failure of other components. This is termed "common cause failure", normally abbreviated as CCF. The degree of propensity for CCF is normally described as the beta (ß) factor. It is very important that subsystem and system designers are aware of the possibilities of CCF. There are many different types of CCF and, correspondingly, many different ways of avoiding it. EN ISO 13849-1 plots a rational course between the extremes of complexity and over simplification. In common with EN/IEC 62061 it adopts an approach that is essentially qualitative. It provides a list

18

FUNCTIONAL SAFETY

Transition from EN 954-1 to EN ISO 13849-1

of measures known to be effective in avoiding CCF. A sufficient number of these measures must be implemented in the design of a system or subsystem. It could be claimed, with some justification, that the use of this list alone may not be adequate to prevent all possibility of CCF. However, if the intent of the list is properly considered it becomes clear that the spirit of its requirement is to make the designer analyse the possibilities for CCF and to implement appropriate avoidance measures based on the type of technology and the characteristics of the intended application. Use of the list enforces consideration of some of the most fundamental and effective techniques such as diversity of failure modes and design competencies. The BGIA SISTEMA tool also requires the implementation of the standard's CCF look up tables and makes them available in a convenient form.

Systematic Faults

We have already discussed quantified safety reliability data in the form of MTTFd and the probability of dangerous failure. However this is not the whole story. When we referred to those terms we were really thinking about failures that appear to be random in nature. Indeed IEC/EN 62061 specifically refers to the abbreviation of PFHd as the probability of random hardware failure. But there are some types of failures collectively known as "systematic failure" that can be attributed to errors committed in the design or manufacturing process. The classic example of this is an error in software code. The standard provides measures in Annex G to avoid these errors [and therefore the failures]. These measures include provisions such as the use of suitable materials and manufacturing techniques, reviews, analysis and computer simulation. There are also foreseeable events and characteristics that can occur in the operating environment that could cause failure unless their effect is controlled. Annex G also provides measures for this. For example it is easily foreseeable that there may be occasional losses of power. Therefore the de- energisation of components must result in a safe state for the system. These measures may seem to be just common sense, and indeed they are, but they are nevertheless essential. All the rest of the requirements of the standard will be meaningless unless due consideration is given to the control and avoidance of systematic failure. This will also sometimes require the same types of measures used for the control of random hardware failure [in order to achieve the required PFHd] such as automatic diagnostic test and redundant hardware.

19

hardware failure [in order to achieve the required PFHd] such as automatic diagnostic test and redundant
Rockwell Automation Machinery safety affects companies in different ways. Machinery manufacturers / suppliers, typically

Rockwell Automation

Machinery safety affects companies in different ways. Machinery manufacturers / suppliers, typically referred to as OEMs (Original Equipment Manufacturers) are required to conform to relevant machinery safety legislation (eg: in Europe the Machinery Directive), but they also want to improve the throughput of the machine whilst delivering value to their customers. The end users of those machines want to increase the overall equipment effectiveness. Reducing mean time to repair, lowering waste material and avoiding unnecessary stoppages can help achieve these goals, leading to a safer more productive workplace whilst making sure safety regulations are met.

It is common knowledge that legislation is there to make sure manufacturing operates within safer environments and working to standards such as EN ISO 13849-1 is a good method to show compliance to legislation. But achieving compliance can raise challenges you didn’t expect…

• Does it effect the performance of your equipment Stopping when it shouldn’t stop? Nuisance tripping?

• Is it costing you too much? Are you implementing too much safety? Are you implementing a safety solution incorrectly that causes issues Managing additional safety suppliers costs your company

• Is safety limiting your ability to:

run your machine productively and efficiently? carry out maintenance tasks quickly and easily? get your machines to your customer quickly?

• Have incidents increased in your plant? Are your safety measures applied correctly? Are personnel accident payments and disability payments significant

Many of these issues are not considered when applying safety to machines. However now with Functional Safety standards such as EN ISO 13849-1 and IEC 62061, methodology of safety application is being guided towards looking at the whole operating characteristics of your machine in all its operating modes (production, maintenance, startup, decommissioning etc) and applying the right level of safe automation to enable maximum OEE (overall equipment effectiveness).

20

FUNCTIONAL SAFETY

Transition from EN 954-1 to EN ISO 13849-1

This raises a question about the capability of a safety supplier. Historically safety is applied to safeguard a machine by stopping the machine, thus removing the hazard. A methodology that has allowed manufacturing to achieve legislation conformance. But what about productivity and efficiency?

This is where Rockwell Automation’s experience in automation and safety differentiates it from many companies supplying just safety solutions. As a leading automation supplier who integrates safety into its overall automation solution, you can see why its customers see value in a supplier that helps them conform to safety legislation and helps them achieve the productivity and flexibility they need. A core belief within Rockwell Automation is to supply automation solutions that are functionally safer through the adoption of Functional Safety standards. This is where you can clearly see how Functional Safety Standards such as EN ISO 13849-1 will help manufacturing.

Rockwell Automation is an automation company that understands safety. A single solution for the control, motion, and process of the machine can be developed and safety is integrated into this single control platform.

Working with Rockwell Automation

An automation supplier that understands automation and safety… not just safety.

• Helping you get performance you need… safely

Cost – helping you get the most from your investment

• Legislation requirements – helping you achieve conformance

A full range of services and solutions for safer automation

• A comprehensive product portfolio (input / logic / actuation)

• Standard and safety within one network (CIP Safety)

• Safety services (assessments, validation, training etc)

Integrating safety functions into standard automation solutions

• Drives, PLC, I/Os, Motion, networks, programming software…

• Simplifying your architecture

• Lowering cost

• Increasing performance

Rockwell Automation, the Global leader in safety solutions, if you would like to know more please contact your local office.

21

Automation, the Global leader in safety solutions, if you would like to know more please contact
ROCKWELL AUTOMATION Safety Solutions

ROCKWELL AUTOMATION

Safety Solutions

Input devices

ROCKWELL AUTOMATION Safety Solutions Input devices Interlock Switches These devices are designed for physical

Interlock Switches

These devices are designed for physical interlocking of guard doors and equipment thus offering access into a potentially hazardous area only when the hazard is in a safe condition. Devices available include; Interlock switches with and without conditional guard locking, trapped key systems and safety limit switches.

Logic

trapped key systems and safety limit switches. Logic Safety Relays These devices are designed to monitor

Safety Relays

These devices are designed to monitor the status of a safety circuit and offer a variety of configurations. They are available as single function relays or hardware configurable multi-function relays.

relays or hardware configurable multi-function relays. Presence Sensing Devices These devices are designed to

Presence Sensing

Devices

These devices are designed to detect the presence of

a person or object in or around a hazardous area.

They offer no physical barrier and therefore are ideal

in applications where frequent access is required

under safe conditions. Devices available include; Safety Light Curtains, Safety Laser Scanners, Pressure Sensitive Safety Mats and Edging Strips.

Scanners, Pressure Sensitive Safety Mats and Edging Strips. Programmable Safety Controllers These devices are designed

Programmable

Safety Controllers

Mats and Edging Strips. Programmable Safety Controllers These devices are designed to monitor the status of

These devices are designed to monitor the status of a safety circuit and can be software configured for specific functionality. They are dedicated safety controllers specifically designed for safety circuit control.

Output devices

designed for safety circuit control. Output devices Safety Contactors P o w e r F l

Safety Contactors

for safety circuit control. Output devices Safety Contactors P o w e r F l e

PowerFlex ® AC Drives with integrated safety

x ® A C D r i v e s with integrated safety Safety contactors are

Safety contactors are used to remove power from the actuator. Special features are added to the contactors to provide the safety rating. Mechanically linked normally closed contacts are used to feed back the status of the contactors to the logic device, thus ensuring the safety function.

A range of PowerFlex AC drives have optional

integrated safety functionality including Safe Torque Off, Safe Speed Control and Conditional Guard Locking Control. Currently the PowerFlex 40P, 70, 700S and 700H offer Safe Torque Off while new new range of 750 series PowerFlex drives offer all safety functionality mentioned above.

22

FUNCTIONAL SAFETY

Transition from EN 954-1 to EN ISO 13849-1

SAFETY Transition from EN 954-1 to EN ISO 13849-1 E-Stop & Trip Devices These devices are

E-Stop & Trip Devices

from EN 954-1 to EN ISO 13849-1 E-Stop & Trip Devices These devices are designed to

These devices are designed to offer an emergency stop function on machines and are used in positions within easy reach of an operator. Devices include; Emergency Stop Push Buttons, rope (cable) actuated Emergency Stop devices and enabling switches with Emergency Stop functionality.

Integrated Safety

Controllers

Emergency Stop functionality. Integrated Safety Controllers These devices are designed to offer control of both standard

These devices are designed to offer control of both standard automation control and safety control within one platform. They are software programmable and allow configuration of standard and safety functionality in the same programming environment.

safety functionality in the same programming environment. Operator Interface These devices are designed to offer

Operator Interface

These devices are designed to offer operators safe interaction for machine control and include devices such as 3 position enabling switches and two hand control enabling devices.

enabling switches and two hand control enabling devices. Safety I/O These devices offer safety rated I/O

Safety I/O

These devices offer safety rated I/O solutions for application flexibility. They are available in a range of solutions communication of CIP Safety via DeviceNet or EtherNet/IP. Family ranges include; CompactBlock Guard I/O, ArmourBlock Guard I/O and POINT Guard I/O.

Guard I/O, ArmourBlock Guard I/O and POINT Guard I/O. Kinetix ® Motion Drives with integrated safety

Kinetix ® Motion Drives with integrated safety

The Kinetix 6000 Motion Drive has optional integrated safety functionality including Safe Torque Off and in the impending next release will also Safe Speed Control and Conditional Guard Locking Control.

23

Safe Torque Off and in the impending next release will also Safe Speed Control and Conditional
Rockwell Automation The products, the knowledge and the global infrastructure to help you with your

Rockwell Automation

The products, the knowledge and the global infrastructure to help you with your safety and automation needs.

FACTORYTALK™ NETLINX ™ NETWORKS APPLICATION INDUSTRY KNOWLEDGE SOLUTIONS HMI INTEGRATED SAFETY SOLUTIONS
FACTORYTALK™
NETLINX ™
NETWORKS
APPLICATION
INDUSTRY
KNOWLEDGE
SOLUTIONS
HMI
INTEGRATED
SAFETY
SOLUTIONS
SAFETY LOGIC
SAFETY INPUTS
SAFETY OUTPUTS
CONTROLLERS
CONNECTION SYSTEMS
SAFETY
SAFETY
WWW
SERVICES
LEGISLATION
& STANDARDS
GUIDANCE

www.discoverrockwellautomation.com/safety

www.rockwellautomation.com

24

Publication: SAFETY-RM004A-EN-P — April 2009 © 2009 Rockwell Automation, Inc. All Rights Reserved.

Publication: SAFETY-RM004A-EN-P — April 2009

© 2009 Rockwell Automation, Inc. All Rights Reserved.