- 1 -

Septembre 2002
224




GESTION DES FONCTIONS DE SECURITE
PAR AUTOMATE PROGRAMMABLE
DEDIE A LA SECURITE (APIdS)





DEI-SVALDI D., KNEPPERT M.





















N Edition : NS 0224

- 2 -


GESTION DES FONCTIONS DE SECURITE PAR AUTOMATE
PROGRAMMABLE DEDIE A LA SECURITE (APIdS)



DEI-SVALDI D. , KNEPPERT M.

Dpartement Ingnierie des Equipements de Travail



Rsum

La cration ou la rnovation dunit de fabrication automatise conduit lutilisateur initier une
rflexion quant au choix technico-conomique oprer pour dvelopper son application. Cest
dans ce cadre quil est ncessairement amen sinterroger et prendre position sur le systme de
gestion des scurits et notamment sur lutilisation dautomates programmables.
Lobjectif de cette publication est de guider lutilisateur dans sa rflexion en prsentant les tapes
quil aura franchir pour atteindre lobjectif quil sest fix notamment sur la scurit des
personnes exploitant lquipement.
Dans une premire phase, nous invitons le lecteur prendre connaissance de la rglementation qui
accompagne lutilisation des APIdS.
Dans une deuxime phase, nous prsentons les principales approches industrielles permettant,
selon les exigences de scurit requises et la nature de lapplication, de choisir la structure du
systme de gestion des scurits directes la mieux adapte.
Dans une troisime phase, nous posons les principaux problmes rsoudre lorsque la gestion des
scurits sera confie un APIdS.







Mots-cls : Automates programmables Gestion des scurits Scurits directes


- 3 -

SOMMAIRE





1 - INTRODUCTION 4

2 - ETAT DE LA REGLEMENTATION 4

3 - ARCHITECTURE 5
3.1. API grant la commande et les scurits 6
3.2. API grant la commande, le circuit traitant les scurits tant spar 6
3.3. Redondance dAPI grant la commande et les scurits 7
3.4. APIdS grant la commande et les scurits 8
3.5. APIdS grant les scurits spares 9
3.6. Conclusion 9

4 - AUTOMATES PROGRAMMABLES DEDIES A LA SECURITE (APIDS) 11
4.1. APIdS en commande de processus 11
4.2. APIdS en commande de machine 12

5 - GESTION DES FONCTIONS DE SECURITE PAR APIDS CONUS
POUR LA MACHINERIE 14
5.1. Aspect matriel 14
5.2. Aspect logiciel 15
5.3. Aspect intgration dans lquipement 17

6 - CLASSEMENT DES APPLICATIONS GEREES PAR APIDS 19

7 - CONCLUSION 22

REFERENCES BIBLIOGRAPHIQUES 23


- 4 -
1 - INTRODUCTION

En 1984, l'INRS [1] (CND 1502-117-84) recommandait de ne pas faire confiance au seul
Automate Programmable Industriel (API) pour assurer la gestion des fonctions de scurit et
il tait propos d'assurer celle-ci par une logique cble extrieure la commande gre par
l'API. Depuis certains fabricants proposent ou vont proposer de nouveaux API appels
Automate Programmable Industriel ddi Scurit (APIdS) devant pouvoir assurer eux seuls
la gestion des fonctions de scurit. Ce document aborde la problmatique lie l'exploitation
et la mise en uvre des fonctions de scurit sur les machines ou quipements pilots par un
APIdS. Dans un premier temps, nous rappellerons la position prise en 1998 par le Ministre
de l'Emploi et de la Solidarit [2] (note relative lacceptation de certains automates
programmables pour grer des fonctions de scurit sur machine). Nous citerons ensuite les
diffrentes architectures permettant de grer les fonctions de scurit ainsi que les solutions
existantes, nous analyserons les architectures internes des APIdS actuellement sur le march
et les problmes de validation lis aux diffrents types d'applications rencontres.

2 - ETAT DE LA REGLEMENTATION

En l'tat de la technique, il est en toute rigueur impossible de s'assurer intgralement du
respect de lexigence essentielle 1.2.7 de l'annexe 1 au dcret 92-767 du 29 juillet 1992
(transposant lannexe 1 de la directive Machines 98/37/CEE) dans le cas d'utilisation
d'automates programmables standards (un dfaut affectant la logique du circuit de commande
ou une dfaillance ou une dtrioration du circuit de commande, ne doit pas crer de
situations dangereuses).
C'est pourquoi, la note tablie par le Ministre de lEmploi et de la Solidarit [2], propose
l'ensemble des industriels et agents de prvention concerns de choisir le ou les types de
technologie appropris l'analyse des risques effectue en prenant en considration les
prcautions lmentaires suivantes :
- la gestion des fonctions de scurit doit tre spare de la gestion de la partie fonctionnelle,
- les fonctions de scurit doivent tre figes et non modifiables par l'utilisateur.
Le respect de ces critres est fondamental. Il est en effet normal que l'exploitant puisse avoir
accs au programme grant son processus de fabrication. Par contre, ces modifications ne
doivent en aucun cas dgrader le niveau de scurit de lquipement, ce qui est assur si les
deux conditions prcdentes sont respectes.

- 5 -

On comprendra aisment que l'exploitant ne puisse pas intervenir sur le niveau de scurit de
son installation sans sentourer de prcautions. En effet, il faut garder en mmoire que
l'obtention d'un niveau de scurit donn rsulte d'une analyse de risques, d'un choix des
dispositifs de scurit les mieux adapts, le cas chant d'une concertation avec le personnel
intervenant, et surtout de la validation de lensemble. De ce fait, la moindre modification,
mme partielle, requiert une nouvelle validation sans quoi elle pourrait avoir de graves
consquences sur la scurit du personnel.

3 - ARCHITECTURE

Avant d'aborder les diffrentes architectures possibles, il y a lieu d'examiner la part prise par
le circuit de commande dans la scurit globale de la machine. En effet, si sur certaines
machines prsentant un niveau de risque trs lev, la conception du circuit de commande
contribue de manire importante la prvention des risques daccidents (cas des presses,
notamment), il arrive aussi que la scurit repose pour l'essentiel non sur le circuit de
commande mais sur d'autres moyens tels que la mise sous carter, l'loignement, la mise en
place de procdure d'intervention, etc. Dans ce contexte, les effets prvisibles d'une ventuelle
dfaillance du circuit de commande apparaissent comme ngligeables dans l'apprciation des
risques [3] (EN 292).
Les paragraphes suivants prsentent les diffrentes architectures thoriques possibles pour la
gestion des fonctions de scurit sur une machine.

- 6 -
3.1. API grant la commande et les scurits








Lobservation de ce synoptique montre qu'un mouvement dangereux peut se produire suite
une dfaillance de l'API, les scurits ne pouvant plus intervenir pour arrter ce mouvement
dangereux.
Ce comportement est d au fait qu'un API standard na pas t conu pour dtecter toutes ses
dfaillances internes et adopter une position de repli en scurit lorsque celles-ci se
produisent. Pour ces raisons, lutilisation dun API standard nest pas admise pour grer les
fonctions de scurit directe sur une machine.

3.2. API grant la commande, le circuit traitant les scurits tant spar











On constate quil nexiste pas de liaison directe entre une commande intempestive provenant
de lAPI et le mouvement dangereux. Le traitement des scurits par un circuit spcifique
valid permet la commande de la mise en scurit de la machine mme si la sortie de lAPI
commande un mouvement intempestivement. Cette architecture permet lutilisation dun
automate car le traitement spar des scurits annihile les mouvements dangereux malgr la
dfaillance de lAPI.
Entres fonctionnelles
Entres de scurit
ex : cran, barrage
immatriel
API
Mouvement Dangereux
actionneur
Mouvement dangereux
Entres fonctionnelles
Entres de scurit
ex : cran, barrage
immatriel
API
Circuit traitant les
scurits.
actionneur

- 7 -
Cette solution se rencontre frquemment et elle est recommande lorsquelle peut tre
applique, car elle permet de valider aisment la scurit dun systme global, complexe ou
non, en validant seulement le circuit traitant les scurits.

3.3. Redondance dAPI grant la commande et les scurits

Dans cet exemple, la redondance choisie repose sur la mise en uvre de deux automates
devant donner la mme information pour que celle-ci soit prise en considration ; en cas de
discordance, il y a arrt du processus et mise en scurit.
La redondance permettant une meilleure disponibilit, cest--dire celle o linformation dun
seul des API suffit pour commander le mouvement, ne permet pas dassurer un bon niveau de
scurit en prsence de la dfaillance dune des deux voies. Elle ne sera pas analyse dans ce
document.





















Entres fonctionnelles et de
scurit
Entres fonctionnelles et de
scurit
API 1
API 2
Mouvement
dangereux
Circuit
traitant la
discordance
actionneur
alimentation

- 8 -
Dans ce cas, la dfaillance de lun des deux automates ne peut pas mener laccident. La
discordance entre les deux sorties des API est dtecte par un circuit extrieur qui commande
l'arrt du mouvement dangereux et interdit la remise en fonctionnement obligeant la
rparation de l'API dfaillant.
Cette architecture pourra tre utilise pour des systmes o il est admis que la probabilit de
dfaillance de mode commun des deux API est ngligeable. Elle doit tre mise en uvre par
des spcialistes capables de valider lapplication sachant que la scurit dpend des mesures
prises pour rduire les dfaillances de mode commun et de la validation du circuit traitant la
discordance des sorties des API.

3.4. APIdS grant la commande et les scurits

Cette architecture peut tre rencontre sur les systmes o la commande et les scurits sont
fortement imbriques, comme la commande de certaines machines telles que les presses
mcaniques par exemple.









Sur cette reprsentation on remarque qu'une dfaillance de lAPIdS pourrait conduire
directement laccident malgr les scurits initialement prvues. Il faut prciser toutefois
quun APIdS a justement t construit pour quune dfaillance matrielle ou une mauvaise
conception du logiciel systme conduisant une commande intempestive soit peu probable
par rapport celle dun API standard. Resteront toutefois traiter comme pour les autres
solutions, les problmes lis aux programmes applicatifs, aux cblages, la validation et la
maintenance.

Entres fonctionnelles
ex: slecteur, came
Entres de scurit
Ex : cran, barrage
immatriel
APIdS
Mouvement Dangereux
actionneur

- 9 -
3.5. APIdS grant les scurits spares

Lorsque la complexit ou le nombre de fonctions de scurit traiter est important, il est
envisageable de grer les fonctions de scurit par un APIdS spar de la commande
fonctionnelle de la machine. Dans cette architecture comme dans celle o l'APIdS devait grer
en plus le fonctionnel, la scurit du systme repose entirement sur le comportement de
l'APIdS en prsence de dfaillances. L'avantage de cette solution par rapport la prcdente,
rside dans le fait que nayant grer que les scurits, la validation s'en trouve simplifie. De
plus, les modifications du fonctionnel n'ont pas de consquences sur le traitement des
scurits.

3.6. Conclusion

Le tableau ci-aprs rsume les principales architectures dcrites et potentiellement rencontres
sur un quipement industriel.

Paragraphe Architecture Commentaires
3.1 Un API Dconseill pour la gestion des fonctions
de scurits.

3.2

API + traitement des
scurits spares
Conseill lorsque le traitement des
scurits ne ncessite pas d'oprations
complexes. Seul le traitement des
scurits spares est valider.
3.3
Redondance dAPI


Validation complexe ncessitant une
expertise.
3.4 Un APIdS grant le
fonctionnel et les scurits
Validation ncessitant une expertise.
(Point abord dans les paragraphes
suivants) limit certaines applications
bien cibles.
3.5 Scurits spares traites
par un APIdS

idem


- 10 -
Lanalyse de ce tableau montre la diversit des architectures qui s'offre aux concepteurs de
circuits de commande de machines pour grer la scurit. Lorsque cela est possible, il
convient de retenir les architectures o "les scurits sont spares du fonctionnel". Cette
solution a lavantage didentifier avec prcision lensemble des moyens mis en uvre pour
viter les situations risque pouvant conduire laccident, mais aussi de bien circonscrire ce
qui doit tre test et valid. Nanmoins, malgr ce choix de structure o le traitement des
scurits est spar du circuit de commande, les difficults tant de conception que de
validation vont dpendre de la complexit des fonctions traiter ainsi que de la technologie
utilise pour raliser ces scurits.

- La logique cble
Cette technologie base de relais lectromcaniques, a fait ses preuves depuis plusieurs
dcennies car il est ais avec celle-ci de raliser et de valider les fonctions de scurit en
respectant les catgories de l'EN 954-1 demandes pour les diffrents types dapplications
rencontrs en machinerie [5] (ED 807).

- Les blocs logiques de scurit
On trouve souvent en machinerie les mmes fonctions destines assurer la scurit (arrt
durgence, double commande, etc.). Depuis quelques annes, des fabricants proposent des
blocs pr-cbls ralisant ces fonctions. Ces blocs peuvent tre base de composants
lectromcaniques ou lectroniques. Ils ont t conus pour la seule fonction quils doivent
raliser et ont t valids ou certifis par un organisme tiers reconnu comptent. Lutilisateur
doit les cbler conformment aux instructions du fabricant et il ne lui restera qu' valider ou
faire valider leur agencement dans l'application.

- Les dispositifs lectroniques programmables
Pour les fonctions plus complexes o llectromcanique ne convient plus, il est possible
dutiliser des logiques base dlectronique programmable. Mais l se pose le problme de la
conception et de la validation qui demandent aux concepteurs plus de comptences et des
moyens d'investigation plus importants. Cette technologie utilise pour la scurit n'est pas
encore stabilise. Pour y remdier, des fabricants d'API proposent des APIdS (Automate
Programmable Industriel ddi la Scurit) qui devraient simplifier la conception dun
systme ralis base de ce type dquipement.

- 11 -

Dans la suite du document, nous allons aborder lutilisation des APIdS et surtout les
problmes lis la validation des applications quils grent. Comme nous lavons vu
prcdemment, ils peuvent tre utiliss pour traiter les seules fonctions de scurit mais leur
puissance de traitement peut permettre de traiter en mme temps le fonctionnel.

4 - AUTOMATES PROGRAMMABLES DEDIES A LA SECURITE (APIdS)

Ces automates se distinguent des API standards par la mise en uvre de moyens spcifiques
qui leurs permettent de rpondre de manire dfinie lapparition dune dfaillance dun de
leur composant.

Deux grandes classes cohabitent :
a) Les APIdS orients vers la commande de processus tels que : Tricon de Triconex, H51 de
Hima, 5000S de AEG Schneider Automation,
b) Les APIdS orients vers la commande des machines tels que : 95F, 115F et la srie 400 F
de Siemens, PSS 3000 et 3056 de Pilz, ABB Master 220/1,
Les premiers sont conus pour assurer la disponibilit d'un processus c'est--dire qu'ils ont
pour mission de poursuivre le process en cours en toute scurit malgr la dfaillance d'une
voie de traitement.
Les seconds sont orients scurit machine et ils doivent interrompre un mouvement
dangereux ds qu'une voie de traitement est dfaillante. Leurs temps de rponse sont
beaucoup plus courts que les APIdS orients vers la commande de processus.
Cette diffrence est fondamentale car elle a une influence vidente, tant sur larchitecture
interne des APIdS concerns que sur le contenu des logiciels applicatifs.

4.1. APIdS en commande de processus

Ces automates mettent en uvre des architectures redondantes d'ordre 3 avec voteur ou une
architecture dordre 2 avec dtection des fautes du canal dfaillant par des autotests. Seules
ces structures sont capables d'une part, de dtecter la voie dfaillante pour initialiser une
procdure d'urgence ou dalerte permettant la remise en tat et d'autre part, de poursuivre le
processus en maintenant lefficacit des scurits.

- 12 -
Le schma N 1 [6] (EXERA) dcrit ci dessous un exemple darchitecture interne dun APIdS
utilis en sret des processus savoir trois voies indpendantes et un voteur.


Schma n 1

4.2. APIdS en commande de machine

Ces automates peuvent se contenter d'architectures redondantes d'ordre 2 avec comparateur
permettant de vrifier que les deux voies, partir des mmes informations d'entre, donnent
les mmes rsultats en sortie.
En ralit, les constructeurs dAPIdS ddis la machinerie ont dvelopp pour certains des
structures redondantes d'ordre 2 et pour dautres des structures tri-redondantes. De mme, il
existe des structures voies indpendantes ou communicantes ou encore des structures
utilisant les mmes composants ou au contraire des composants diffrents ncessitant des
logiciels applicatifs diffrents ou non.
Ces diffrentes solutions montrent la diversit des moyens utiliss et surtout que chaque
solution nest quun compromis privilgiant tel ou tel paramtre de la scurit comme par
exemple :
- la rapidit de raction face une dfaillance,

- 13 -
- la rduction de linfluence des pannes de mode commun,
- la dtection des pannes latentes,
- le temps rponse de lapplication.

Le schma n 2 [6] (EXERA) prsente une structure redondante d'ordre 2 de lunit centrale
de lautomate. Il est remarquer que les deux voies sont indpendantes et quaucun contrle
nest effectu entre les CPU A et B. L'intrt d'une telle architecture est d'liminer la
contamination dune voie par lautre car elles sont compltement indpendantes.
L'inconvnient tient au fait que seules les dfaillances ayant une influence sur la sortie sont
dtectes par le comparateur, les autres dfaillances (pannes latentes) ne sont pas traites.

Schma n 2

Le schma n 3 [6] (EXERA) prsente une structure tri-redondante dun APIdS utilisable en
machinerie. Dans ce cas, le constructeur a choisi de procder des changes inter voies ce qui
permet la dtection de certaines dfaillances latentes qui ne seraient pas dtectes par le
comparateur de sortie.

- 14 -
Cette solution a toutefois linconvnient dtre une source potentielle de pannes de mode
commun car les voies ne sont plus totalement indpendantes [4].



Schma n 3

5 - GESTION DES FONCTIONS DE SECURITE PAR APIDS CONUS POUR LA
MACHINERIE

Les problmes de l'utilisation d'un APIdS pour grer les fonctions de scurit doivent tre
abords suivant trois aspects :
a) l'APIdS en tant que matriel,
b) le programme applicatif dont il doit tre muni,
c) l'interface "APIdS machine" c'est--dire l'interconnexion de l'automate avec l'quipement
qui lui aussi revt une part importante dans la russite des objectifs fixs.

5.1. Aspect matriel

Ces automates mettent en uvre des moyens matriels qui leur permettent de rpondre de
manire dfinie (pannes orientes) lapparition dune dfaillance dun de leurs composants
et lon peut citer :
- une structure au moins redondante des principaux lments matriels ou autres dispositions
donnant une garantie au moins quivalente (dynamisme, contrle,),
- une excution contrle des logiciels systmes et applicatifs dans des temps limits,
- des logiciels applicatifs pr-crits, des blocs de fonctions pr-certifis et ou pr-valids,

- 15 -
- une srie dautotests destins vrifier labsence de dfauts latents (par exemple au niveau,
des mmoires EPROM en lecture, des RAM en criture et en lecture, des microprocesseurs
par la vrification de lexcution dinstructions de contrle, des horloges, des
alimentations),
- une certification ou une validation du produit par un organisme comptent.

Rappelons que des organismes comptents europens (BIA, BG, TV...) valident suivant une
dmarche volontaire des APIdS en fonction de diffrents rfrentiels issus :
- d'une norme europenne harmonise: la EN 954-1 [7],
- de normes internationales de la CEI (Commission Electrotechnique Internationale) : la CEI
61508 et la CEI 62061 (encore l'tat de projet ) [8] [9],
- d'une norme nationale, par exemple la VDE 801 pour l'Allemagne.
Il faut toutefois remarquer qu'il n'existe pas de norme spcifique APIdS contrairement aux
normes API qui permettent d'avoir un avis de conformit sur ce produit [10].
A ce jour, un APIdS composant matriel sans son logiciel applicatif, nest pas considr au
sens rglementaire comme un composant de scurit pouvant tre mis isolment sur le
march. Les certificats dlivrs pour certains APIdS n'tant pas des attestations dexamen CE
de type (non lists lannexe IV de la directive Machines), on peut tout au plus en dduire
une prsomption daptitude grer des fonctions de scurit. Cette prsomption sera dautant
plus forte si l'organisme est reconnu pour la qualit de ses expertises dans ce domaine.

5.2. Aspect logiciel

Un APIdS sans son logiciel applicatif na aucune fonction dfinie. Cest uniquement lorsquil
excute un logiciel applicatif spcifique qu'il devient apte grer une ou plusieurs fonctions
de scurit d'une application industrielle. Cette proprit justifie l'intrt des APIdS, car il
devient ainsi possible avec un seul type de composant matriel et divers logiciels applicatifs
de raliser lensemble des fonctions de scurit ncessit par la diversit des applications en
automatisme. De plus, la possibilit de modifier le logiciel permet une volution de
lapplication comme par exemple la gestion des zones de protection volutives dans le temps.
Rappelons que le logiciel applicatif est le logiciel dvelopp avec le langage propre chaque
APIdS pour grer une application.
Cas particulier : Pour les applications de type presse ou machine bois, pour lesquelles le
fonctionnel de la machine a un rle dterminant sur la scurit, le logiciel applicatif inclura
fonctionnel et gestion des scurits.

- 16 -
Quant au logiciel systme (qui gre le fonctionnement interne de lAPIdS), il nest pas
accessible aux utilisateurs. Ayant t valid en mme temps que la partie matrielle de
l'APIdS, il nintervient pas sur la validation du logiciel applicatif.
Brivement on peut citer les tapes ncessaires pour valider un logiciel applicatif :

a) Sapproprier les moyens mis en uvre par le dveloppeur pour atteindre lobjectif de
scurit revendiqu en sappuyant sur :
- l'existence de prescriptions fonctionnelles de la machine (exigences normatives, de
scurit, de contrles...),
- la faon dont ces prescriptions ont t mises en uvre,
- les contrles et valuations raliss (auto certification ou certification par un organisme
comptent),
- l'existence dune notice d'utilisation spcifique l'application.

b) Vrifier de faon purement formelle que le logiciel est bien crit :
- modularit,
- hirarchisation des modules,
- nombre d'instructions par module,
- nombre d'entres/sorties des modules,
- affectation des entres et des sorties,
- commentaires,
- ...
En fait, partir d'outils spcifiques on doit savoir si le logiciel a t correctement crit pour
qu'il soit lisible, maintenable et testable. Ce critre est ncessaire mais n'est nanmoins pas
suffisant pour valider un logiciel, car on ne sait pas encore ce stade ce qu'il excute
rellement.

c) Vrifier que le logiciel est conforme aux spcifications dfinies dans le cahier des
charges.
Pour y satisfaire, il est ncessaire de stimuler lAPIdS afin de vrifier que sa raction est
conforme celle spcifie, et cela dans toutes les configurations possibles d'utilisation.
En thorie, il faut vrifier la rponse de l'APIdS avec son logiciel applicatif pour chaque
squence d'entre.
En ralit, on se rend compte rapidement qu'un test exhaustif devient irralisable si le
nombre de fonctions ou de squences est important. Il convient alors dutiliser des

- 17 -
mthodes spcifiques adaptes aux logiciels pour assurer un niveau de confiance
raisonnable quant la conformit du cahier des charges.

d) Vrifier la prennit de la solution retenue
Le contrle tant ralis, il faut s'assurer que des modifications de programme ne
pourront pas tre ralises sans excuter une procdure spcifique destine matriser
cette modification. Celle ci doit tre valide et surtout inscrite dans un processus de
traabilit ce qui peut par ailleurs limiter la flexibilit et la souplesse reconnue un
APIdS.
En ce qui concerne le dveloppement du logiciel applicatif, les rsultats d'une tude en
cours l'INRS donneront de plus amples informations.

5.3. Aspect intgration dans l'quipement

Cet aspect ne sera que brivement abord car il ne diffre que trs peu des applications base
de logique cble dont on matrise assez bien la mise en uvre et la validation. Il faut
toutefois signaler que cette mise en uvre nest pas commune tous les APIdS et que chaque
fabricant propose sa manire de bien raliser cette interconnexion suivant la catgorie (EN
954-1) revendique pour lapplication (voir rfrence cblage des APIdS) [11].
Partant d'un APIdS avec son logiciel applicatif valid, le constructeur ou l'intgrateur doit le
connecter sa machine de faon sre.
Pour cela, il doit :
a) Choisir des capteurs et des actionneurs compatibles avec le niveau de scurit attendu et le
logiciel applicatif mis en uvre dans lAPIdS. Ils seront soit auto-contrls, soit scurit
intrinsque, soit doubls selon le type de capteurs/actionneurs retenus et le niveau de
scurit revendiqu.
b) Raliser le cblage entre les diffrents capteurs/actionneurs et les entres/sorties de
lAPIdS comme conseill par le fabricant de l'APIdS et suivant le type de carte
d'entres/sorties utilis.
c) Valider la ralisation globale :
- vrifier que toutes les fonctions prvues rpondent au cahier des charges,
- injecter sil y a lieu des fautes sur les capteurs et actionneurs de la machine ainsi que sur
le cblage de ceux-ci et sassurer chaque fois du bon comportement de la machine.

- 18 -
d) Etablir la notice d'utilisation et de dpannage de la machine ainsi que les procdures de
contrle mettre en place tout au long de son cycle dutilisation pour en assurer sa
prennit.

- 19 -
6 - CLASSEMENT DES APPLICATIONS GEREES PAR APIDS
Le synoptique suivant propose une classification des diverses applications gres par APIdS
selon trois familles.
Classement des applications gres par APIdS en machinerie

















































(1) : Validation par le constructeur de lAPIdS ou par un organisme comptent.
(2) : Le programme applicatif est cre par le constructeur de la machine. Sa validation intervient en
fin de cycle de dveloppement de la machine.
APIdS dont
le
programme
applicatif est
fig et
valid
(1)
.
Exemple:
machines de
srie
APIdS dont
le
programme
applicatif est
fig
(2)
mais
unique.
Exemple:
machines
spciales
APIdS dont
le
programme
applicatif
peut voluer
Exemple:
lignes
automatises
CAS A
CAS B
CAS C
Partie commune

- Cblage des
E/S

- Validation
de lquipement

- Mise en place
dun suivi

- 20 -

- La premire famille (cas A) concerne les machines autonomes mettant en uvre peu
d'entres/sorties et dont les fonctions logiques raliser sont assez simples bien qu'tant
squentielles (presses, presses plieuses, cisailles, machines bois classiques). Dans ce cas
particulier o l'quipement possde une fonction bien dfinie, il devient possible de figer son
logiciel applicatif, de le protger contre toutes modifications non contrles et ensuite de le
dupliquer sur tous les quipements pour lesquels il a t dvelopp. Lavantage dune telle
procdure rside dans le fait quun seul logiciel est dvelopper, mettre au point et
valider.
Dans cette premire famille, le programme applicatif est dfini et fig sous la forme d'un
module valid pour lequel tous les paramtres internes sont fixs ainsi que l'affectation des
entres et des sorties. Ainsi, lintgrateur n'a plus qu' cbler l'APIdS sa machine en
respectant le plan de cblage fourni avec le logiciel applicatif. Il lui restera toutefois
contrler par un test fonctionnel la bonne ralisation du cblage. Le concepteur du logiciel
applicatif devra lui fournir les tests effectuer pour l'aider raliser cette vrification.
En fait cela est similaire la philosophie des blocs logiques de scurit pour lesquels
l'intgrateur a pour seule initiative la ralisation du branchement et le contrle de la bonne
mise en uvre sans se proccuper des problmes lis a la ralisation technique.
Bien entendu le logiciel applicatif devra tre verrouill de faon ce qu'il ne puisse plus tre
modifi par l'utilisateur et il devra comporter une signature garantissant sa prennit tout au
long de son utilisation.
Quelques constructeurs (Pilz, Siemens) proposent dj des logiciels applicatifs valids.
Pour des machines risques levs, il nous semble judicieux de confier la validation de
lensemble de lapplication un organisme reconnu pour ses comptences en la matire.
Pour des machines faibles risques, le constructeur pourra auto-certifier son produit
directement condition de respecter les tapes nonces ci-dessus. S'il n'en a pas les
capacits, il devra utiliser des technologies prouves et connues ou faire appel un
organisme reconnu.
On peut remarquer dans ce type dapplication o le programme est verrouill, que l'utilisateur
final na en aucun cas la possibilit d'intervenir sur le programme applicatif donc sur la
gestion des scurits. Seuls les paramtres de la machine (sans incidence sur la scurit) lui
sont accessibles. Pour assurer la prennit des fonctions de scurit, toute modification du
processus de travail ou tout dpannage ncessitant une modification du programme devra
faire l'objet d'une demande d'intervention auprs de l'intgrateur, charge ce dernier de faire
le ncessaire et de revalider l'quipement.

- 21 -

- La deuxime famille (cas B) rassemble lensemble des machines spciales dveloppes soit
unitairement, soit en srie limite. Contrairement au cas A, ces applications possdent des
logiciels applicatifs non standard. Lutilisateur ou lintgrateur dveloppe son propre logiciel
applicatif. Ensuite il devra le verrouiller pour viter toute modification et le valider ou le faire
valider sachant que cette validation ne correspondra qu cette application.
Les problmes soulevs dans ce type dapplication sont :
- la ncessit dun personnel hautement qualifi en programmation et scurit,
- la difficult pour lexploitant matriser la validation,
- le cot dune telle validation du fait de son unicit et des moyens mettre en uvre.
Compte tenu de ces problmes, ces applications grant des fonctions de scurit seront
gnralement rserves des grandes entreprises sur des installations complexes.

- La troisime famille (cas C) se distingue des deux prcdentes par le fait que le logiciel
applicatif de l'APIdS grant les fonctions de scurit doit pouvoir tre facilement adapt aux
volutions d'une production automatise rencontres par exemple dans l'industrie automobile,
alimentaire ou la fabrication de produits en bton dans le btiment et les travaux publics.
Cette obligation contraint lintgrateur fournir un systme ouvert ne lui permettant pas de
garantir une scurit prenne, contrairement aux cas A et B o le logiciel applicatif grant les
fonctions de scurit est valid et verrouill pour l'application.
Cette grande souplesse de modification du programme utilisateur pose des difficults quant
la gestion et au maintien de la scurit aprs une modification. En effet, de la mme faon que
chaque application ncessite une conception et une validation qui lui est propre, chaque
modification apporte doit aussi tre rpertorie et valide. Ceci demande un personnel
hautement qualifi en programmation et l'existence de procdures de modifications mettre
en uvre et respecter.


- 22 -
7 - CONCLUSION

Aprs avoir montr la diversit des architectures pouvant tre mises en uvre, fait linventaire
des diffrents types d'APIdS prsents sur le march, rpertori les types dapplications, il est
noter que lutilisation du composant APIdS pour rsoudre les problmes de scurit dune
application nest pas une condition suffisante et qu'il faudra comme pour toute application
valider lensemble du systme.
Ce qui pose problme aujourdhui dans lusage dun APIdS nest pas le composant en tant
que tel mais plutt la complexit et la validation de la mise en uvre tant du point de vue
logiciel applicatif que du cblage des capteurs et surtout des actionneurs qui lui sont associs.

Aujourd'hui, on peut admettre que les machines quipes dun APIdS avec son programme
applicatif fig (cas A et B), verrouill et valid par un organisme comptent apporte une
garantie suffisante pour un fonctionnement en scurit.
Pour les ralisations dquipement base dAPIdS dont le programme applicatif est ouvert
(cas C) permettant ainsi les volutions ultrieures, cest lintgrateur ou lutilisateur
apporter la preuve du niveau de scurit revendiqu, de surcrot il doit aussi en assurer la
prennit tout au long du cycle de vie du systme. Pour ce cas, devant la difficult du
problme rsoudre, il est recommand d'avoir encore recours dans la mesure du possible aux
solutions classiques ayant fait leurs preuves (logique cble, bloc logique, redondance). Si
la solution par APIdS est incontournable, il conviendra pour garantir une bonne mise en
uvre que les intgrateurs ou utilisateurs qui n'ont pas le personnel qualifi, se fassent assister
par un organisme comptent. Celui-ci les aidera valider le produit final, mais aussi les
conseillera depuis la conception, la mise en uvre, lexploitation et jusqu' la fin de vie de
linstallation.


- 23 -
REFERENCES BIBLIOGRAPHIQUES

[1] Les automates programmables - Cahiers de Notes Documentaires n117, 4
me
trimestre-
1984, pp. 467-474.

[2] Note tablie par le bureau CT5 du Ministre de l'Emploi et de la Solidarit, note relative
l'acceptation de certains automates programmables pour grer des fonctions de
scurit sur machines (26 Mai 1998).

[3] NF EN 292 Scurit des machines - Notion fondamentales, principes gnraux de
conception : Partie 1 : Terminologie de base, mthodologie, AFNOR, Paris, 1991, 33 p.

[4] Outil pour l'vitement des fautes logicielles - dfaillances de mode commun dans les
systmes de scurit, projet Europen STARCES SMT4CT97-2191, mars 2000,
annexes au rapport final, 54 p.

[5] Scurit des machines et des quipements de travail - Moyens de protection contre les
risques mcaniques. Paris, INRS, ED 807, 2
e
dition (2000).

[6] Document EXERA, Groupe de travail "Systmes de scurit API-APIdS : panorama",
rapport EXERA (rdacteur : J.F. AUBRY), Paris, dcembre 2000, 68 p.

[7] NF EN 954-1 (2/1997) Scurit des machines- Parties des systmes de commande
relatives la scurit. Partie 1 : Principes gnraux de conception. Paris- La dfense,
AFNOR.

[8] CEI 61508 "Scurit fonctionnelle des systmes lectriques / lectroniques /
lectroniques programmables relatifs la sret".
Partie 1 : Prescriptions gnrales, UTE C 46-061, avril 2000, 59 p.
Partie 2 : Exigences pour les systmes lectriques / lectroniques / lectroniques
programmables, UTE C 46-062, avril 2000, 71 p.
Partie 3 : Prescriptions concernant les logiciels, UTE C 46-063, avril 2000, 49 p.
Partie 4 : Dfinitions et abrviations, UTE C 46-064, avril 2000, 26 p.
Partie 5 : Exemples de mthodes pour la dtermination des niveaux d'intgrit de scurit,
UTE C 46-065, avril 2000, 28 p.
Partie 6 : Guide pour l'application des parties 2 et 3, UTE C 46-066, avril 2000, 75 p.
Partie 7 : Bibliographie des techniques et des mesures, UTE C 46-067, avril 2000, 115 p.


- 24 -
[9] CEI 62061 "Scurit des machines Scurit fonctionnelle des systmes Electriques /
Electroniques / Electroniques Programmables" Version CD, septembre 2000, 63p.

[10] EN/CEI 61131 - Automates programmables, Octobre 1992
Partie 1 : Informations gnrales.
Partie 2 : Spcifications et essais des quipements.
Partie 3 : langages de programmation.
Partie 4 : Recommandation l'utilisateur.
Partie 5 : Communications.
Partie 6 : ( l'tude).
Partie 7 : Programmation en logique floue.

[11] Document CRAMIF - Utilisation d'Automates pour l'excution de fonctions de scurit.
Complment d'information destination des concepteurs/intgrateurs d'installations
automatises et des rnovateurs d'quipements de travail. (En cours d'dition).