IEC/TR 62061–1 Reviewed

This entry is part 2 of 2 in the series IEC/TR 62061–1

Why You Need to Spend More Cash on Yet Another Document

Stan­dards orga­ni­za­tions pub­lish doc­u­ments in a fair­ly con­tin­u­ous stream, so for those of us tasked with stay­ing cur­rent with a large num­ber of stan­dards (say, more than 10), the pub­li­ca­tion of anoth­er new stan­dard or Tech­ni­cal Report isn’t news — it’s busi­ness as usu­al. The ques­tion is always: Do we real­ly need to add this to the library?

For those who are new to this busi­ness, hav­ing to pay for crit­i­cal design infor­ma­tion is a new expe­ri­ence. Find­ing out that it can cost hun­dreds, if not thou­sands, to build the library you need can be over­whelm­ing.

This review aims to help you decide if you need IEC/TR 62061–1 in your library.

The Problem

As a machine builder or a man­u­fac­tur­er build­ing a prod­uct designed to be inte­grat­ed into machin­ery, how do you choose between ISO 13849–1 and IEC 62061?

IEC 62061–1 attempts to pro­vide guid­ance on how to make this choice.

History

When CENELEC pub­lished EN 954–1 in 1995, machine builders were intro­duced to a whole new world of con­trol reli­a­bil­i­ty require­ments. Pri­or to its pub­li­ca­tion, most machines were built with very sim­ple inter­locks, and no spe­cif­ic stan­dards for inter­lock­ing devices exist­ed. In the years since then, the EN 954–1 Cat­e­gories have become well known and are applied inside and out­side the EU.

In the inter­ven­ing years, IEC pub­lished IEC 61508. This sev­en-part stan­dard intro­duced the idea of ‘Safe­ty Integri­ty  Lev­els’ or SILs. This stan­dard is aimed at process con­trol sys­tems and could be used for com­plex machin­ery as well.

Why the Confusion?

In 2006, IEC pub­lished a machin­ery sec­tor spe­cif­ic stan­dard based on IEC 61508, called IEC 62061. This stan­dard offered a sim­pli­fied appli­ca­tion of the IEC 61508 method­ol­o­gy intend­ed for machine builders. The key prob­lem with this stan­dard is that it did not pro­vide a means to deal with pneu­mat­ic or hydraulic con­trol ele­ments, which are cov­ered by ISO 13849–1.

ISO adopt­ed EN 954–1 and reis­sued it as ISO 13849–1 in 1999. This edi­tion of the stan­dard was vir­tu­al­ly iden­ti­cal to the stan­dard it replaced from a tech­ni­cal require­ments per­spec­tive. EN 954–1/ISO 13849–1 did not pro­vide any means to esti­mate the integri­ty of the safe­ty relat­ed con­trols, but did define cir­cuit archi­tec­tures (Cat­e­gories B, 1–4) and spoke to the selec­tion of com­po­nents, intro­duc­ing the con­cepts of ‘well-tried safe­ty prin­ci­ples’ and ‘well-tried com­po­nents’. A sec­ond prob­lem had long exist­ed in addi­tion to this — EN 954–2, Val­i­da­tion, was nev­er pub­lished by CENELEC except as a com­mit­tee draft, so a key ele­ment in the appli­ca­tion of the stan­dard had been miss­ing for five years at the point where ISO 13849–1 Edi­tion 1 was pub­lished.

The first cut at guid­ing users in choos­ing an appro­pri­ate stan­dard came with the pub­li­ca­tion of IEC 62061 Edi­tion 1.  Pub­lished in 2005, Edi­tion 1 includ­ed a table that attempt­ed to pro­vide users with some guid­ance on how to choose between ISO 13849–1 or IEC 62061.

…and then came 2007…

In 2007, ISO pub­lished the Sec­ond Edi­tion of ISO 13849–1, and brought a whole new twist to the dis­cus­sion by intro­duc­ing ‘Per­for­mance Lev­els’ or PLs. PLs can be loose­ly equat­ed to SILs, even though PLs are stat­ed in fail­ures per year and SILs in fail­ures per hour. The same table includ­ed in IEC 62061 was includ­ed in this edi­tion of ISO 13849–1.

Table 1
Recommended application of
IEC 62061 and ISO 13849–1(under revision)

(from the Sec­ond Edi­tion, 2007)

Tech­nol­o­gy imple­ment­ing the
safe­ty relat­ed con­trol function(s)
ISO
13849–1 (under revi­sion)
IEC 62061
A Non elec­tri­cal, e.g. hydraulics X Not cov­ered
B Electro­mechan­i­cal, e.g. relays, or
non-com­plex elec­tron­ics
Restrict­ed to des­ig­nat­ed
archi­tec­tures (see Note 1) and up to PL=e

All archi­tec­tures and up to
SIL 3

C Com­plex elec­tron­ics, e.g. pro­gram­ma­ble Restrict­ed to des­ig­nat­ed
archi­tec­tures (see Note 1) and up
to PL=d
All archi­tec­tures and up to
SIL 3
D A com­bined with B Restrict­ed to des­ig­nat­ed
archi­tec­tures (see Note 1) and up
to PL=e
X
see Note 3
E C com­bined with B Restrict­ed to des­ig­nat­ed
archi­tec­tures (see Note 1) and up
to PL=d
All archi­tec­tures and up to
SIL 3
F C com­bined with A, or C com­bined with
A and B
X
see Note 2
X
see Note 3

X” indi­cates that this item is dealt with by the stan­dard shown in the col­umn head­ing.

NOTE 1 Des­ig­nat­ed archi­tec­tures are defined in Annex B of EN ISO 13849–1(rev.) to give a sim­pli­fied approach for quan­tifi­ca­tion of per­for­mance lev­el.

NOTE 2 For com­plex elec­tron­ics: Use of des­ig­nat­ed archi­tec­tures accord­ing to EN ISO 13849–1(rev.) up to PL=d or any archi­tec­ture accord­ing to IEC 62061.

NOTE 3 For non-elec­tri­cal tech­nol­o­gy use parts accord­ing to EN ISO 13849–1(rev.) as sub­sys­tems.

So how is a machine builder to choose the ‘cor­rect’ stan­dard, if both stan­dards are applic­a­ble and both are cor­rect? Fur­ther­more, how do you assess the reli­a­bil­i­ty of the safe­ty-relat­ed con­trols when inte­grat­ing equip­ment from var­i­ous sup­pli­ers, some of whom rate their equip­ment in PLs and some in SILs? Why are two stan­dards address­ing the same top­ic required? Will ISO 13849–1 and IEC 62061 ever be merged?

The Technical Report

In July this year the IEC pub­lished a Tech­ni­cal Report that dis­cuss­es the selec­tion and appli­ca­tion of these two key con­trol reli­a­bil­i­ty stan­dards for machine builders. This guide has long been need­ed, and pre­cedes a face to face event planned by IEC to bring machine builders and stan­dards writ­ers face-to-face to dis­cuss these same issues.

The guide, titled IEC/TR 62061–1 — Tech­ni­cal Report — Guid­ance on the appli­ca­tion of ISO 13849–1 and IEC 62061 in the design of safe­ty-relat­ed con­trol sys­tems for machin­ery pro­vides direct guid­ance on how to select between these two stan­dards.

Down­load IEC stan­dards, Inter­na­tion­al Elec­trotech­ni­cal Com­mis­sion stan­dards.

Merger

In the intro­duc­tion to the report the TC makes it clear that the stan­dards will be merged, although they don’t pro­vide any kind of a time line for the merg­er. Quot­ing from the intro­duc­tion:

It is intend­ed that this Tech­ni­cal Report be incor­po­rat­ed into both IEC 62061 and ISO 13849–1 by means of cor­ri­gen­da that ref­er­ence the pub­lished ver­sion of this doc­u­ment. These cor­ri­gen­da will also remove the infor­ma­tion giv­en in Table 1, Rec­om­mend­ed appli­ca­tion of IEC 62061 and ISO 13849–1, pro­vid­ed in the com­mon intro­duc­tion to both stan­dards, which is now rec­og­nized as being out of date. Sub­se­quent­ly, it is intend­ed to merge ISO 13849–1 and IEC 62061 by means of a JWG of ISO/TC 199 and IEC/TC 44.

I added the bold face to the para­graph above to high­light the key state­ment regard­ing the even­tu­al merg­er of the two doc­u­ments.  If you’re not famil­iar with the stan­dards acronyms, a ‘JWG’ is a Joint Work­ing Group, and a TC is a Tech­ni­cal Com­mit­tee. TC’s are formed from vol­un­teer experts from indus­try and acad­e­mia sup­port­ed by their orga­ni­za­tions. So a JWG formed from two TC’s just means that a joint com­mit­tee has been formed to work out the details of the merg­er. Even­tu­al­ly.

The oth­er key point in this para­graph relates to the replace­ment of Table 1. In the inter­im, IEC/TR 62061–1 will be incor­po­rat­ed into both stan­dards, replac­ing Table 1.

Even­tu­al­ly the con­fu­sion will be cleared up because only one stan­dard will exist in the machin­ery sec­tor, but until then, machine builders will need to fig­ure out which stan­dard best fits their prod­ucts.

Comparing PL’s and SIL’s

The Tech­ni­cal Report does a good job of dis­cussing the dif­fer­ences between PL and SIL, includ­ing pro­vid­ing an expla­na­tion of how to covert one to the oth­er, very use­ful if you are try­ing to inte­grate an SIL rat­ed device into a PL analy­sis or vice-ver­sa.

Selecting a Standard

Clause 2.5 gives some sol­id advice on select­ing between the two stan­dards based on the tech­nolo­gies employed in the design and your own com­fort lev­el in using the ana­lyt­i­cal tech­niques in the two stan­dards.

Anoth­er key point is that EITHER stan­dard can be used to ana­lyze com­plex OR sim­ple con­trol sys­tems. Some fans of IEC 62061 have been known to put ISO 13849–1 down as use­ful exclu­sive­ly for sim­ple hard­wired con­trol sys­tems. Clause 3.3 makes it clear that this is not the case. Pick the one you like or know the best and go with that. As an addi­tion­al thought, con­sid­er which stan­dard your com­peti­tors are using, and also which your cus­tomers are using. For exam­ple, if your cus­tomers use ISO 13849–1 pri­mar­i­ly, qual­i­fy­ing your prod­uct under IEC 62061 might seem like a good idea, but may dri­ve your cus­tomers to a com­peti­tor who makes their life eas­i­er by using ISO 13849–1. If your com­peti­tors are using a dif­fer­ent stan­dard, try to under­stand the choice before climb­ing on the band­wag­on. There may be a com­pet­i­tive advan­tage lurk­ing in being dif­fer­ent.

Risk Assessment

Clause 4 speaks direct­ly to the indis­pens­able need to con­duct a method­i­cal risk assess­ment, and to use that to guide the design of the con­trols.

In my prac­tice, many clients decide that they would pre­fer to choose a con­trol reli­a­bil­i­ty lev­el that they feel will be more than good enough for any of their designs, and then to ‘stan­dard­ize’ on that design for all their prod­ucts, there­by elim­i­nat­ing the need to thought­ful­ly decide on the appro­pri­ate design for the appli­ca­tion. In oth­er cas­es, end-users may choose to use a ‘stan­dard’ design through­out their facil­i­ty to assist main­te­nance per­son­nel by lim­it­ing their need to become tech­ni­cal­ly famil­iar with a vari­ety of designs. This is done to speed trou­bleshoot­ing and reduce down time and spares stocks.

The prob­lem with this approach can be that some man­agers believe this approach can elim­i­nate the need to con­duct risk assess­ments, see­ing this as a fruit­less, expen­sive and often futile exer­cise. This is emphat­i­cal­ly NOT the case. Risk assess­ments address much more than the selec­tion of con­trol reli­a­bil­i­ty require­ments and need to be done to ensure that all haz­ards that can­not be elim­i­nat­ed or sub­sti­tut­ed are safe­guard­ed. A miss­ing or bad­ly done risk assess­ment may inval­i­date your claim to a CE mark, or be the land­mine that ends a lia­bil­i­ty case — with you on the los­ing end.

Safety Requirement Specification (SRS)

Each safe­ty func­tion needs to be defined in detail in a Safe­ty Require­ment Spec­i­fi­ca­tion (SRS). A reli­a­bil­i­ty assess­ment needs to be com­plet­ed for each safe­ty func­tion defined in the SRS. This point is dis­cussed in detail in IEC 62061, but is not dealt with in any detail in ISO 13849–1, so IEC/TR 62061–1 once again bridges the gap by pro­vid­ing an impor­tant detail that is miss­ing in one of the two stan­dards.

If you are unfa­mil­iar with the con­cept of an SRS, each safe­ty func­tion needs to be described with a cer­tain min­i­mum amount of infor­ma­tion, includ­ing:

  • The name of safe­ty func­tion;
  • A descrip­tion of the func­tion;
  • The required lev­el of per­for­mance based on the risk assess­ment and accord­ing to either ISO 13849–1 (PLr a to e) or the required safe­ty integri­ty accord­ing to IEC 62061 (SIL 1 to 3)

Once the safe­ty func­tions are defined and ana­lyzed, each safe­ty func­tion must be imple­ment­ed by a con­trol cir­cuit. The select­ed PL will dri­ve the design to one or two of the defined ISO 13849–1 archi­tec­tures, and then the com­po­nent selec­tions and oth­er design details will dri­ve the final fail­ure rate and PL. Alter­na­tive­ly, the SRS will dri­ve the selec­tion of IEC 62061 archi­tec­ture (1oo1, 1oo2, 2oo2, etc.) and the rest of the design details will lead to the final fail­ure rate and SIL.

Table 1 in the Tech­ni­cal Report com­pares the lev­els.

Table 1 – Relationship between PLs and SILs based on the average probability
of dangerous failure per hour

Per­for­mance Lev­el (PL) Aver­age prob­a­bil­i­ty of a dan­ger­ous
fail­ure per hour (1/h)
Safe­ty integri­ty lev­el (SIL)
a >= 10-5 to < 10-4 No spe­cial safe­ty require­ments
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

This table com­bines ISO 13849–1 2007, Tables 3 & 4. No sim­i­lar tables exist in IEC 62061 2005.

Combining Equipment with PLs and SILs

Sec­tion 7 of the report speaks to the chal­lenge of inte­grat­ing equip­ment with rat­ings in a mix of PLs and SILs. Until the stan­dards merge and a sin­gle sys­tem for describ­ing reli­a­bil­i­ty cat­e­gories is agreed on, this prob­lem will be with us.

When design­ing sys­tems using either sys­tem the design­er has to deter­mine the approx­i­mate rate of dan­ger­ous fail­ures. In ISO 13849–1, MTTFd is the com­po­nent fail­ure rate para­me­ter, while in IEC 62061, PFHd is the sub­sys­tem fail­ure rate para­me­ter. MTTFd does not con­sid­er diag­nos­tics or archi­tec­ture, only the com­po­nent fail­ure rate per year, while PFHd does include diag­nos­tics and archti­tec­ture, and it speaks to the sys­tem fail­ure rate per hour. To com­pare these rates, ISO 13849–1 Annex K describes the rela­tion­ship between MTTFd and PFHd for dif­fer­ent archi­tec­tures.

In the design process only one method can be used, so where equip­ment with dif­fer­ent rat­ings must be com­bined the fail­ure rates must be con­vert­ed to either MTTFd or to PFHd, depend­ing on the sys­tem being used to com­plete the analy­sis. Mix­ing require­ments with­in the design of a sub­sys­tem is not per­mit­ted (See Clause 7.3.3).

Fault Exclusions

Fault exclu­sions are per­mit­ted under both stan­dards with some lim­i­ta­tions: up to IEC 62061 SIL 2. No fault exclu­sions are per­mit­ted in SIL 3. Prop­er­ly jus­ti­fied fault exclu­sions can be used up to PLe. “Prop­er­ly jus­ti­fied” fault exclu­sions are those that can be shown to be valid through the life­time of the SRP/CS.

In gen­er­al, fault exclu­sions for mechan­i­cal fail­ures of electro­mechan­i­cal devices such as inter­lock devices or emer­gency stop devices are not per­mit­ted, with a few excep­tions giv­en in ISO 13849–2, (See Claus­es 7.2.2.4 and 7.2.2.5).

This approach is con­sis­tent with the cur­rent approach tak­en in Cana­da, as described in CSA Z432 & Z434. Fault exclu­sions are gen­er­al­ly not per­mit­ted under ANSI stan­dards.

Worked Examples

Sec­tion 8 of the Tech­ni­cal Report gives a cou­ple of worked exam­ples, one done under ISO 13849–1, and one under IEC 62061. For some­one look­ing for a good exam­ple of what a prop­er­ly com­plet­ed analy­sis should look like, this sec­tion is the gold at the end of the rain­bow. Sec­tion 8.2 pro­vides a good, clear exam­ple of the appli­ca­tion of the stan­dards along with a nice, sim­ple exam­ple of what a safe­ty require­ment spec­i­fi­ca­tion might look like.

Understanding the Differences

One area where pro­po­nents of the two stan­dards often dis­agree is on the ‘accu­ra­cy’ of the ana­lyt­i­cal pro­ce­dures giv­en in the two stan­dards. The Tech­ni­cal Report pro­vides a detailed expla­na­tion of why the two tech­niques pro­vide slight­ly dif­fer­ent results and pro­vides the ratio­nale explain­ing why this vari­a­tion should be con­sid­ered accept­able.

To Buy or Not to Buy…

At the end of the day, the ques­tion that needs to be answered is whether to buy this doc­u­ment or not. If you use either of these stan­dards, I strong­ly rec­om­mend that you spend the mon­ey to get this Tech­ni­cal Report, if for noth­ing more than the worked exam­ples. Until the two stan­dards are merged, and that could be a few years, you will need to be able to effec­tive­ly apply these approach­es to PL and SIL rat­ed equip­ment. This Tech­ni­cal Report will be an invalu­able aid.

It also pro­vides some guid­ance on the direc­tion that the new merged stan­dard will take. Some old argu­ments can be set­tled, or at least re-direct­ed, by this doc­u­ment.

Final­ly, since the TR is to be incor­po­rat­ed in both stan­dards and con­tains mate­r­i­al replac­ing that in the cur­rent edi­tions of the stan­dard, you must buy a copy to remain cur­rent.

For all of these rea­sons, I would spend the mon­ey to acquire this doc­u­ment, read and apply it.

Down­load IEC stan­dards, Inter­na­tion­al Elec­trotech­ni­cal Com­mis­sion stan­dards.

Down­load ISO Stan­dards

If you’ve bought the report and would like to add your thoughts, please add a com­ment below. Got ques­tions? Con­tact me!

Interlock Architectures – Pt. 3: Category 2

This entry is part 3 of 8 in the series Cir­cuit Archi­tec­tures Explored

This arti­cle explores the require­ments for safe­ty relat­ed con­trol sys­tems meet­ing ISO 13849–1 Cat­e­go­ry 2 require­ments. “Gotcha!” points in the def­i­n­i­tion are high­light­ed to help design­ers avoid this com­mon pit­falls.

In the first two posts in this series, we looked at Cat­e­go­ry B, the Basic cat­e­go­ry of sys­tem archi­tec­ture, and then moved on to look at Cat­e­go­ry 1. Cat­e­go­ry B under­pins Cat­e­gories 2, 3 and 4. In this post we’ll look more deeply into Cat­e­go­ry 2.

Let’s start by look­ing at the def­i­n­i­tion for Cat­e­go­ry 2, tak­en from ISO 13849–1:2007. Remem­ber that in these excerpts, SRP/CS stands for Safe­ty Relat­ed Parts of Con­trol Sys­tems.

Definition

6.2.5 Category 2

For cat­e­go­ry 2, the same require­ments as those accord­ing to 6.2.3 for cat­e­go­ry B shall apply. “Well–tried safe­ty prin­ci­ples” accord­ing to 6.2.4 shall also be fol­lowed. In addi­tion, the fol­low­ing applies.

SRP/CS of cat­e­go­ry 2 shall be designed so that their function(s) are checked at suit­able inter­vals by the machine con­trol sys­tem. The check of the safe­ty function(s) shall be per­formed

  • at the machine start-up, and
  • pri­or to the ini­ti­a­tion of any haz­ardous sit­u­a­tion, e.g. start of a new cycle, start of oth­er move­ments, and/or
  • peri­od­i­cal­ly dur­ing oper­a­tion if the risk assess­ment and the kind of oper­a­tion shows that it is nec­es­sary.

The ini­ti­a­tion of this check may be auto­mat­ic. Any check of the safe­ty function(s) shall either

  • allow oper­a­tion if no faults have been detect­ed, or
  • gen­er­ate an out­put which ini­ti­ates appro­pri­ate con­trol action, if a fault is detect­ed.

When­ev­er pos­si­ble this out­put shall ini­ti­ate a safe state. This safe state shall be main­tained until the fault is cleared. When it is not pos­si­ble to ini­ti­ate a safe state (e.g. weld­ing of the con­tact in the final switch­ing device) the out­put shall pro­vide a warn­ing of the haz­ard.

For the des­ig­nat­ed archi­tec­ture of cat­e­go­ry 2, as shown in Fig­ure 10, the cal­cu­la­tion of MTTFd and DCavg should take into account only the blocks of the func­tion­al chan­nel (i.e. I, L and O in Fig­ure 10) and not the blocks of the test­ing chan­nel (i.e. TE and OTE in Fig­ure 10).

The diag­nos­tic cov­er­age (DCavg) of the total SRP/CS includ­ing fault-detec­tion shall be low. The MTTFd of each chan­nel shall be low-to-high, depend­ing on the required per­for­mance lev­el (PLr). Mea­sures against CCF shall be applied (see Annex F).

The check itself shall not lead to a haz­ardous sit­u­a­tion (e.g. due to an increase in response time). The check­ing equip­ment may be inte­gral with, or sep­a­rate from, the safe­ty-relat­ed part(s) pro­vid­ing the safe­ty func­tion.

The max­i­mum PL achiev­able with cat­e­go­ry 2 is PL = d.

NOTE 1 In some cas­es cat­e­go­ry 2 is not applic­a­ble because the check­ing of the safe­ty func­tion can­not be applied to all com­po­nents.

NOTE 2 Cat­e­go­ry 2 sys­tem behav­iour allows that

  • the occur­rence of a fault can lead to the loss of the safe­ty func­tion between checks,
  • the loss of safe­ty func­tion is detect­ed by the check.

NOTE 3 The prin­ci­ple that sup­ports the valid­i­ty of a cat­e­go­ry 2 func­tion is that the adopt­ed tech­ni­cal pro­vi­sions, and, for exam­ple, the choice of check­ing fre­quen­cy can decrease the prob­a­bil­i­ty of occur­rence of a dan­ger­ous sit­u­a­tion.

ISO 13849-1 Figure 10
Fig­ure 1 — Cat­e­go­ry 2 Block dia­gram [1, Fig.10]

Breaking it down

Let start by tak­ing apart the def­i­n­i­tion a piece at a time and look­ing at what each part means. I’ll also show a sim­ple cir­cuit that can meet the require­ments.

Category B & Well-tried Safety Principles

The first para­graph speaks to the build­ing block approach tak­en in the stan­dard:

For cat­e­go­ry 2, the same require­ments as those accord­ing to 6.2.3 for cat­e­go­ry B shall apply. “Well–tried safe­ty prin­ci­ples” accord­ing to 6.2.4 shall also be fol­lowed. In addi­tion, the fol­low­ing applies.

Sys­tems meet­ing Cat­e­go­ry 2 are required to meet all of the same require­ments as Cat­e­go­ry B, as far as the com­po­nents are con­cerned. Oth­er require­ments for the cir­cuits are dif­fer­ent, and we will look at those in a bit.

Self-Testing required

Cat­e­go­ry 2 brings in the idea of diag­nos­tics. If cor­rect­ly spec­i­fied com­po­nents have been select­ed (Cat­e­go­ry B), and are applied fol­low­ing ‘well-tried safe­ty prin­ci­ples’, then adding a diag­nos­tic com­po­nent to the sys­tem should allow the sys­tem to detect some faults and there­fore achieve a cer­tain degree of ‘fault-tol­er­ance’ or the abil­i­ty to func­tion cor­rect­ly even when some aspect of the sys­tem has failed.

Let’s look at the text:

SRP/CS of Cat­e­go­ry 2 shall be designed so that their function(s) are checked at suit­able inter­vals by the machine con­trol sys­tem. The check of the safe­ty function(s) shall be per­formed

  • at the machine start-up, and
  • pri­or to the ini­ti­a­tion of any haz­ardous sit­u­a­tion, e.g. start of a new cycle, start of oth­er move­ments, and/or
  • peri­od­i­cal­ly dur­ing oper­a­tion if the risk assess­ment and the kind of oper­a­tion shows that it is nec­es­sary.

The ini­ti­a­tion of this check may be auto­mat­ic. Any check of the safe­ty function(s) shall either

  • allow oper­a­tion if no faults have been detect­ed, or
  • gen­er­ate an out­put which ini­ti­ates appro­pri­ate con­trol action, if a fault is detect­ed.

When­ev­er pos­si­ble this out­put shall ini­ti­ate a safe state. This safe state shall be main­tained until the fault is cleared. When it is not pos­si­ble to ini­ti­ate a safe state (e.g. weld­ing of the con­tact in the final switch­ing device) the out­put shall pro­vide a warn­ing of the haz­ard.

Peri­od­ic check­ing is required. The checks must hap­pen at least each time there is a demand placed on the sys­tem, i.e. a guard door is opened and closed, or an emer­gency stop but­ton is pressed and reset. In addi­tion the integri­ty of the SRP/CS must be test­ed at the start of a cycle or haz­ardous peri­od, and poten­tial­ly peri­od­i­cal­ly dur­ing oper­a­tion if the risk assess­ment indi­cates that this is nec­es­sary. The test­ing fre­quen­cy must be at least 100x the demand rate [1, 4.5.4], e.g., a light cur­tain on a part load­ing work sta­tion that is inter­rupt­ed every 30 s dur­ing nor­mal oper­a­tion requires a min­i­mum test rate of once every 0.3 s, or 200x per minute or more.

The test­ing does not have to be auto­mat­ic, although in prac­tice it usu­al­ly is. As long as the sys­tem integri­ty is good, then the out­put is allowed to remain on, and the machin­ery or process can run.

Watch Out!

Notice that the words ‘when­ev­er pos­si­ble’ are used in the last para­graph in this part of the def­i­n­i­tion where the stan­dard speaks about ini­ti­a­tion of a safe state. This word­ing alludes to the fact that these sys­tems are still prone to faults that can lead to the loss of the safe­ty func­tion, and so can­not be called tru­ly ‘fault-tol­er­ant’. Loss of the safe­ty func­tion must be detect­ed by the mon­i­tor­ing sys­tem and a safe state ini­ti­at­ed. This requires care­ful thought, since the safe­ty sys­tem com­po­nents may have to inter­act with the process con­trol sys­tem to ini­ti­ate and main­tain the safe state in the event that the safe­ty sys­tem itself has failed. Also note that it is not pos­si­ble to use fault exclu­sions in Cat­e­go­ry 2 archi­tec­ture, because the sys­tem is not fault tol­er­ant.

All of this leads to an inter­est­ing ques­tion: If the sys­tem is hard­wired through the oper­at­ing chan­nel, and all the com­po­nents used in that chan­nel meet Cat­e­go­ry B require­ments, can the diag­nos­tic com­po­nent be pro­vid­ed by a mon­i­tor­ing the sys­tem with a stan­dard PLC? The answer to this is YES. Test equip­ment (called TE in Fig. 1) is specif­i­cal­ly exclud­ed, and Cat­e­go­ry 2 DOES NOT require the use of well-tried com­po­nents, only well-tried safe­ty prin­ci­ples.

Final­ly, for the faults that can be detect­ed by the mon­i­tor­ing sys­tem, detec­tion of a fault must ini­ti­ate a safe state. This means that on the next demand on the sys­tem, i.e. the next time the guard is opened or the emer­gency stop is pressed, the machine must go into a safe con­di­tion. Gen­er­al­ly, detec­tion of a fault should pre­vent the sub­se­quent reset of the sys­tem until the fault is cleared or repaired.

Test­ing is not per­mit­ted to intro­duce any new haz­ards or to slow the sys­tem down. The tests must occur ‘on-the-fly’ and with­out intro­duc­ing any delay in the sys­tem com­pared to how it would have oper­at­ed with­out the test­ing incor­po­rat­ed. Test equip­ment can be inte­grat­ed into the safe­ty sys­tem or be exter­nal to it.

One more ‘gotcha’

Note 1 in the def­i­n­i­tion high­lights a sig­nif­i­cant pit­fall for many design­ers: if all of the com­po­nents in the func­tion­al chan­nel of the sys­tem can­not be checked, you can­not claim con­for­mi­ty to Cat­e­go­ry 2. If you look back at Fig. 1, you will see that the dashed “m” lines con­nect all three func­tion­al blocks to the TE, indi­cat­ing that all three must be includ­ed in the mon­i­tor­ing chan­nel. A sys­tem that oth­er­wise would meet the archi­tec­tur­al require­ments for Cat­e­go­ry 2 must be down­grad­ed to Cat­e­go­ry 1 in cas­es where all the com­po­nents in the func­tion­al chan­nel can­not be test­ed. This is a major point and one which many design­ers miss when devel­op­ing their sys­tems.

Calculation of MTTFd

The next para­graph deals with the cal­cu­la­tion of the fail­ure rate of the sys­tem, or MTTFd.

For the des­ig­nat­ed archi­tec­ture of cat­e­go­ry 2, as shown in Fig­ure 10, the cal­cu­la­tion of MTTFd and DCavg should take into account only the blocks of the func­tion­al chan­nel (i.e. I, L and O in Fig­ure 10) and not the blocks of the test­ing chan­nel (i.e. TE and OTE in Fig­ure 10).

Cal­cu­la­tion of the fail­ure rate focus­es on the func­tion­al chan­nel, not on the mon­i­tor­ing sys­tem, mean­ing that the fail­ure rate of the mon­i­tor­ing sys­tem is ignored when ana­lyz­ing sys­tems using this archi­tec­ture. The MTTFd of each com­po­nent in the func­tion­al chan­nel is cal­cu­lat­ed and then the MTTFd of the total chan­nel is cal­cu­lat­ed.

The Diag­nos­tic Cov­er­age (DCavg) is also cal­cu­lat­ed based exclu­sive­ly on the com­po­nents in the func­tion­al chan­nel, so when deter­min­ing what per­cent­age of the faults can be detect­ed by the mon­i­tor­ing equip­ment, only faults in the func­tion­al chan­nel are con­sid­ered.

This high­lights the fact that a fail­ure of the mon­i­tor­ing sys­tem can­not be detect­ed, so a sin­gle fail­ure in the mon­i­tor­ing sys­tem that results in the sys­tem fail­ing to detect a sub­se­quent nor­mal­ly detectable fail­ure in the func­tion­al chan­nel will result in the loss of the safe­ty func­tion.

Summing Up

The next para­graph sums up the lim­its of this par­tic­u­lar archi­tec­ture:

The diag­nos­tic cov­er­age (DCavg) of the total SRP/CS includ­ing fault-detec­tion shall be low. The MTTFd of each chan­nel shall be low-to-high, depend­ing on the required per­for­mance lev­el (PLr). Mea­sures against CCF shall be applied (see Annex F).

The first sen­tence reflects back to the pre­vi­ous para­graph on diag­nos­tic cov­er­age, telling you, as the design­er, that you can­not make a claim to any­thing more than LOW DC cov­er­age when using this archi­tec­ture.

This rais­es an inter­est­ing ques­tion, since Fig­ure 5 in the stan­dard shows columns for both DCavg = LOW and DCavg=MED. My best advice to you as a user of the stan­dard is to abide by the text, mean­ing that you can­not claim high­er than LOW for DCavg in this archi­tec­ture. This con­flict will be addressed by future revi­sions of the stan­dard.

Anoth­er prob­lem raised by this sen­tence is the inclu­sion of the phrase “the total SRP/CS includ­ing fault-detec­tion”, since the pre­vi­ous para­graph explic­it­ly tells you that the assess­ment of DCavg ‘should’ only include the func­tion­al chan­nel, while this sen­tence appears to include it. In stan­dards writ­ing, sen­tences includ­ing the word ‘shall’ are clear­ly manda­to­ry, while those includ­ing the word ‘should’ indi­cate a con­di­tion which is advised but not required. Hope­ful­ly this con­fu­sion will be clar­i­fied in the next edi­tion of the stan­dard.

MTTFd in the func­tion­al chan­nel can be any­where in the range from LOW to HIGH depend­ing on the com­po­nents select­ed and the way they are applied in the design. The require­ment will be dri­ven by the desired PL of the sys­tem, so a PLd sys­tem will require HIGH MTTFd com­po­nents in the func­tion­al chan­nel, while the same archi­tec­ture used for a PLb sys­tem would require only LOW MTTFd com­po­nents.
Final­ly, applic­a­ble mea­sures against Com­mon Cause Fail­ures (CCF) must be used. Some of the mea­sures giv­en in Table F.1 in Annex F of the stan­dard can­not be applied, such as Chan­nel Sep­a­ra­tion, since you can­not sep­a­rate a sin­gle chan­nel. Oth­er CCF mea­sures can and must be applied, and so there­fore you must score at least the min­i­mum 65 on the CCF table in Annex F to claim com­pli­ance with Cat­e­go­ry 2 require­ments.

Example Circuit

Here’s an exam­ple of what a sim­ple Cat­e­go­ry 2 cir­cuit con­struct­ed from dis­crete com­po­nents might look like. Note that PB1 and PB2 could just as eas­i­ly be inter­lock switch­es on guard doors as push but­tons on a con­trol pan­el. For the sake of sim­plic­i­ty, I did not illus­trate surge sup­pres­sion on the relays, but you should include MOV’s or RC sup­pres­sors across all relay coils. All relays are con­sid­ered to be con­struct­ed with  ‘force-guid­ed’ designs and meet the require­ments for well-tried com­po­nents.

Example Category 2 circuit from discrete components
Fig­ure 2 — Exam­ple Cat­e­go­ry 2 cir­cuit from dis­crete com­po­nents

How the cir­cuit works:

  1. The machine is stopped with pow­er off. CR1, CR2, and M are off. CR3 is off until the reset but­ton is pressed, since the NC mon­i­tor­ing con­tacts on CR1, CR2 and M are all closed, but the NO reset push but­ton con­tact is open.
  2. The reset push but­ton, PB3,  is pressed. If both CR1, CR2 and M are off, their nor­mal­ly closed con­tacts will be closed, so press­ing PB3 will result in CR3 turn­ing on.
  3. CR3 clos­es its con­tacts, ener­giz­ing CR1 and CR2 which seal their con­tact cir­cuits in and de-ener­gize CR3. The time delays inher­ent in relays per­mit this to work.
  4. With CR1 and CR2 closed and CR3 held off because its coil cir­cuit opened when CR1 and CR2 turned on, M ener­gizes and motion can start.

In this cir­cuit the mon­i­tor­ing func­tion is pro­vid­ed by CR3. If any of CR1, CR2 or M were to weld closed, CR3 could not ener­gize, and so a sin­gle fault is detect­ed and the machine is pre­vent­ed from re-start­ing. If the machine is stopped by press­ing either PB1 or PB2, the machine will stop since CR1 and CR2 are redun­dant. If CR3 fails with weld­ed con­tacts, then the M rung is held open because CR3 has not de-ener­gized, and if it fails with an open coil, the reset func­tion will not work, there­fore both fail­ure modes will pre­vent the machine from start­ing with a failed mon­i­tor­ing sys­tem, if a “force-guid­ed” type of relay is used for CR3. If CR1 or CR2 fail with an open coil, then M can­not ener­gize because of the redun­dant con­tacts on the M rung.

This cir­cuit can­not detect a fail­ure in PB1, PB2, or PB3. Test­ing is con­duct­ed each time the cir­cuit is reset. This cir­cuit does not meet the 100x test rate require­ment, and so can­not be said to meet Cat­e­go­ry 2 require­ments.

If M is a motor starter rather than the motor itself, it will need to be dupli­cat­ed for redun­dan­cy and a mon­i­tor­ing con­tact added to the CR3 rung .

In cal­cu­lat­ing MTTFd, PB1, PB2, CR1, CR2, CR3 and M must be includ­ed. CR3 is includ­ed because it has a func­tion­al con­tact in the M rung and is there­fore part of the func­tion­al chan­nel of the cir­cuit as well as being part of the OT and OTE chan­nels.

Down­load IEC stan­dards, Inter­na­tion­al Elec­trotech­ni­cal Com­mis­sion stan­dards.
Down­load ISO Stan­dards

Watch for the next install­ment in this series where we’ll explore Cat­e­go­ry 3, the first of the ‘fault tol­er­ant’ archi­tec­tures!

New Guide to Applying ISO 13849–1 and IEC 62061

This entry is part 1 of 2 in the series IEC/TR 62061–1

IEC and ISO have pub­lished a new guide to help users select between ISO 13849–1 and IEC 62061. This new Tech­ni­cal Report will replace Table 1 in both stan­dards.

One of the big chal­lenges fac­ing machine builders has been choos­ing between ISO 13849–1 and IEC 62061. The IEC pub­lished a new guide at the end of July, 2010 called Tech­ni­cal Report IEC/TR 62061–1 ed1.0 Guid­ance on the appli­ca­tion of ISO 13849–1 and IEC 62061 in the design of safe­ty-relat­ed con­trol sys­tems for machin­ery. The new 38-page guide is avail­able as a hard copy or a PDF file. Writ­ten joint­ly by Tech­ni­cal Com­mit­tee IEC/TC 44, Safe­ty of machin­ery – Elec­trotech­ni­cal aspects and Tech­ni­cal Com­mit­tee ISO/TC 199, Safe­ty of machin­ery. The Tech­ni­cal Report was pub­lished in par­al­lel by ISO as ISO/TR 23849.

Tech­ni­cal Reports don’t have the same sta­tus as Inter­na­tion­al Stan­dards, but pro­vide the TC’s with  a means to pro­vide guid­ance and expla­na­tion to help users imple­ment the stan­dard.

Table of Contents

Since this is a copy­right­ed doc­u­ment, I can’t repro­duce it here. Instead, here’s the Table of Con­tents that will give you some idea of  the document’s con­tents.

Cover of IEC/TR 62061-1
IEC/TR 62061–1
  1. Scope
  2. Gen­er­al
  3. Com­par­i­son of stan­dards
  4. Risk esti­ma­tion and assign­ment of required per­for­mance
  5. Safe­ty require­ments spec­i­fi­ca­tion
  6. Assign­ment of per­for­mance tar­gets: PL ver­sus SIL
  7. Sys­tem design
  8. Exam­ple
  9. Bib­li­og­ra­phy

Merger Coming Soon

The intro­duc­tion to the TR indi­cates that it will be incor­po­rat­ed into both IEC 62061 and ISO 13849–1 through a cor­ri­gen­da that ref­er­ences this new doc­u­ment. The cor­ri­gen­da will also remove the infor­ma­tion giv­en in Table 1, Rec­om­mend­ed appli­ca­tion of IEC 62061 and ISO 13849–1, found in the com­mon intro­duc­tion to both stan­dards and which is now out of date.

At some point in the near future, IEC and ISO  intend that ISO 13849–1 and IEC 62061 will be merged. A  Joint Work­ing Group (JWG) of ISO/TC 199 and IEC/TC 44 will be formed to com­plete this task. No pub­lic time line has been set for this activ­i­ty, how­ev­er the Intro­duc­tion to the Tech­ni­cal Report sug­gests that it may be a few years yet, as the TC’s involved want to get some feed­back from users on the lat­est ver­sions. If I had to haz­ard a guess, I would sug­gest that the new merged doc­u­ment might make its first appear­ance in 2013 when the cur­rent edi­tion of ISO 13849–1 comes up for main­te­nance revi­sion. I guess we’ll have to wait and see whether I’m right on that or not. In any case, I as a user of the stan­dards, I am whole­heart­ed­ly behind the merg­er, and hope­ful­ly the sim­pli­fi­ca­tion, of these stan­dards to make them more acces­si­ble to the machine build­ing com­mu­ni­ty.

Availability

A bilin­gual (Eng­lish and French) ver­sion of IEC/TR 62061–1 edi­tion 1.0 is avail­able.

ISO/TR 23849:2010 is avail­able as a 14-page doc­u­ment, in either Eng­lish or French.

Down­load IEC stan­dards, Inter­na­tion­al Elec­trotech­ni­cal Com­mis­sion stan­dards.

Watch for my review of this impor­tant new doc­u­ment com­ing in the next few days!