RAPPORT FINAL

Sûreté fonctionnelle des systèmes

dédiés à la sécurité

E. FAÉ & J.-L. DURKA

2000
 Sommaire

1. INTRODUCTION 3
1.1. Objectif 3
1.2. Que sont les systèmes électroniques complexes ? 4
1.3. Problèmes à résoudre 5
1.4. EN 954-1 & IEC 61508 5
1.5. Point de vue des organismes de certification 6

2. ANALYSE DE LA SITUATION ACTUELLE 8

2.1. Utilisation croissante de CES pour les applications de sécurité 8
2.2. Base pour la validation des CES 11

3. ATTEINDRE LA SÉCURITÉ EN SUIVANT LE CYCLE DE VIE 12

3.1. Introduction 12
3.2. Spécifications 17
3.3. Architecture 22
3.4. Conception et développement 38
3.5. Validation 55

4. APPLICABILITÉ DES NORMES EN 954 ET IEC 61508 SUR LES MACHINES 69

4.1. Introduction 69
4.2. Exigences communes et différences entre les normes EN 954-1 et IEC 61508 69
4.3. Difficultés pratiques rencontrées pour la validation d’une machine 74
4.4. Conclusions de l'exercice de validation du système de commande 81
4.5. Techniques et mesures pour la validation de machines 83

5. MANUEL UTILISATEUR 85
5.1. Méthodologie de validation pour les SRCES 85
5.2. Ce à quoi nous ne pouvons pas répondre 87

6. CONCLUSIONS 90
6.1. Contribution de STSARCES à EN 954 90
6.2. Contribution de STSARCES à IEC 62061 92
6.3. Validation du projet par des fabricants externes 93

7. BIBLIOGRAPHIE 94

-2-
1. INTRODUCTION

1.1. Objectif

Le projet européen STSARCES (Standard for Safety Related Complex Electronic Systems) porte
sur le développement de méthodes d'analyse de systèmes de sécurité mettant en oeuvre les
technologies modernes de l'électronique et de l'informatique, telles qu'on les rencontre fréquemment
sur les installations à risques (boucles de sécurité avec composants ou automates programmables,
réseaux de terrain, capteurs intelligents). Dans ce cadre, le principal objectif est de proposer au CEN
une méthodologie harmonisée d'évaluation des systèmes de sécurité en appui au projet de norme
pr EN 954-2 sur la sécurité des dispositifs de commande dans le cadre de la Directive Machine, et
cohérente avec la normalisation internationale : CEI 61508 en cours de publication.

Cette recherche a été menée avec le partenariat de onze organisations européennes pour aider au
développement d'une norme émergente « pr EN 954-2 » en produisant un document décrivant des
propositions de méthodes de validation harmonisées.

Le projet de norme européenne pr EN 954-2 fournit les détails des mesures et techniques qui doivent
être appliquées pour valider les composants liés à la sécurité pour toutes les technologies utilisées
dans les systèmes de commande des machines.

Une contrainte imposée à toutes les méthodes de validation développées à partir de ce programme de
recherche consistait à éviter toute déviation par rapport aux exigences de la norme IEC 61508
(sécurité fonctionnelle des systèmes électriques/électroniques/électroniques programmables), compte
tenu de son statut de norme pilote.

L’INERIS, coordinateur du projet STSARCES, et les organisations suivantes ont participé au

programme de recherche :
 INERIS (Institut National de l’Environnement Industriel et des Risques, France)
 BIA (Berufsgenossenschaftliches Institut fur Arbeitssicherheit, Allemagne)
 HSE (Health & Safety Executive, Royaume-Uni)
 INRS (Institut National de Recherche et de Sécurité, France)
 VTT (Technical Research Centre, Finlande)
 CETIM (Centre Technique des Industries Mécaniques, France)
 INSHT (Instituto Nacional de Seguridad e Higiene en el Trabajo, Espagne)
 JAY (Jay Électronique SA, France)
 SP (Swedish National Testing and Research Institute, Suède)
 TUV (TUV Product Service GMBH, Allemagne)
 SICK AG (SICK AG Safety Systems Division, Allemagne)

-3-
 1.2. Que sont les systèmes électroniques complexes ?

La Directive machines (98/37/CE), qui couvre les machines et les composants de sécurité, et la
norme EN 292 « sécurité des machines - Concepts de base, principes généraux de conception » se
basent, en général, sur des pratiques établies dans la conception de systèmes de commande de
machines, tels que les protections mécaniques ou inhibiteurs d'alimentation, dans les cas où le
personnel peut accéder à des zones dangereuses pour des tâches comme les réglages, le changement
d'outil et la maintenance. Ces protections sont communément conçues et mises en œuvre au niveau
de la machine après la fin de la conception de son système de commande de base. Cette application
rétrospective de protections présentait une solution pratique partout où il existait un niveau adéquat
d'indépendance vis-à-vis du système de commande des machines.

Cependant, cette approche de la sécurité des machines s'est montrée moins viable avec l'émergence
de solutions électroniques et électroniques programmables qui doivent être plus étroitement intégrées
à la conception d'un système de commande de machines. Les systèmes de commande liés à la
sécurité qui mettent en œuvre ces solutions comprennent souvent une série de dispositifs/composants
et de technologies électriques/électroniques.

Ces systèmes électroniques complexes peuvent être caractérisés comme des systèmes de commande
de machines dans lesquels :
 le mode de panne d'au moins un constituant, dispositif ou composant, n'est pas bien défini ;

 le comportement du dispositif composant en conditions de défaut ne peut être

complètement déterminé ;

 il n'existe pas suffisamment de données du retour d’expérience sur les dysfonctionnement et

défaillances qui permettent de déduire des taux de pannes dangereuses détectées et non
détectées du dispositif ou composant.

Un exemple de composant de sécurité à base de systèmes électroniques "complexes" permettant la

détection de présence, le contrôle de mouvement et de vitesse d'une machine à commande
numérique. Ceci peut impliquer un régulateur de machine basé sur l'électronique programmable qui
effectue des fonctions dites de sécurité et d’autres non liées à la sécurité.

Ce régulateur peut être capable de traiter les signaux d'entrée reçus de dispositifs de contrôle du
mouvement installés sur des arbres mobiles ou rotatifs dangereux, et transmettre un signal de sortie
aux dispositifs de commande comme un système électrique afin de réduire la vitesse ou le
mouvement jusqu'à un niveau de sécurité.

-4-
 1.3. Problèmes à résoudre

Les dispositifs et composants électroniques et électroniques programmables complexes comme les

circuits intégrés LSI « large scale integrated circuits » et VLSI « very large scale integrated
circuits », les circuits intégrés spécifiques ASIC « application specific integrated circuits », les
contrôleurs logiques programmables PLC « programmable logic controllers », les microcontrôleurs,
etc., sont de plus en plus utilisés pour la réalisation de fonctions liées à la sécurité mises en œuvre par
des systèmes de commande de machines.

La performance de sécurité de tels dispositifs et composants, soit en tant que parties individuelles ou
en combinaison de système complet lié à la sécurité, a été difficile à établir en pratique. Il s'agit avant
tout d'un résultat des caractéristiques fondamentales d'un système électronique complexe, qui rend
difficile d'établir que sa mise en œuvre finale satisfait les exigences de performance de
fonctionnement ou de sécurité nécessaires en testant une machine.

En conséquence, on a découvert que les tests fonctionnels doivent être complétés par une analyse de
la conception du système électronique complexe lié à la sécurité utilisé pour la commande de
machines pour évaluer correctement la performance de sécurité de ses éléments matériels et logiciels.
Il existe un grand nombre de mesures et de techniques pour cette analyse de conception basée sur
des méthodologies quantitatives et qualitatives qui peuvent être utilisées par les fabricants de
machines et les organismes de certification.

La plupart des techniques et mesures établies, comme les arbres de fautes et l’analyse des modes de
défaillance et de leurs effets ont des mérites lorsqu'elles sont utilisées en combinaison avec des
philosophies de tests classiques pour des systèmes électroniques complexes liés à la sécurité. La
difficulté pour les praticiens se situe dans la détermination des mesures adéquates pour des
applications à des machines particulières et dans la cohérence atteinte par leur utilisation.

Ces difficultés ont été abordées dans une certaine mesure par les normes existantes et émergentes
considérées par le projet STSARCES.

1.4. EN 954-1 & IEC 61508

Le Projet STSARCES inclut une comparaison des méthodologies et des exigences de deux normes :
IEC 61508 (Sécurité fonctionnelle des systèmes de sécurité électriques/ électroniques/électroniques
programmables) et EN 954 (Sécurité des machines - Composants liés à la sécurité des systèmes de
commande). Elle a été effectuée afin de déterminer la différence entre les exigences de ces deux
normes pour les technologies électroniques complexes et électroniques programmables lorsqu'elles
sont appliquées à des systèmes de commande des machines.

-5-
Les deux normes proposent une approche structurée tendant à la conception de systèmes de
commande liés à la sécurité, mais elles diffèrent dans le sens où EN 954 vise à s'appliquer à tous les
types de technologies de système de commande alors que IEC 61508 vise avant tout, mais pas
exclusivement, à s'appliquer aux systèmes de commande liés à la sécurité électriques, électroniques et
électroniques programmables. Les normes exigent que les fonctions liées à la sécurité du système de
commande soient hiérarchisées : la norme IEC 61508 exige qu'on affecte un niveau d'intégrité de
sécurité aux fonctions liées à la sécurité réalisées par un système de commande d'une machine alors
que EN 954 utilise le concept de performance de sécurité et place le système dans une catégorie
parmi cinq. Il existe une différence significative dans la manière dont les niveaux d'intégrité de
sécurité et les catégories sont dérivés et définis ; ce sont les problèmes posés par cette différence qui
ont été considérés, en particulier dans la mesure où les deux classifications ont été comparées dans le
but de développer une stratégie pour les lier.

La norme IEC 61508 utilise une approche de cycle de vie de sécurité pour garantir que la conception
d'un système de commande de sécurité est effectuée de manière systématique. Cette approche de
cycle de vie est examinée dans le projet STSARCES pour établir si elle conviendrait à la conception
de systèmes de commande des machines.

1.5. Point de vue des organismes de certification

Des CES (Systèmes Electroniques Complexes) de sécurité certifiés par des organismes de
certification sont aujourd'hui en vente également dans le secteur des machines. Bien qu'il n'y ait pas
aujourd'hui de procédure de validation harmonisée pour les CES, on peut formuler les remarques
suivantes :
 L'utilisation de CES pour les systèmes de commande liés à la sécurité représente également,
depuis quelques temps, l'état de l'art avancé pour le secteur des machines.

 Il n'y a pas eu d'accident avec les machines et les dispositifs de sécurité certifiés qui soient
imputables à la technologie électronique programmable de l'unité de commande.

 Étant donné le grand nombre d'applications différentes en utilisation pratique et le taux

d'accident faible et encourageant, on peut dire que les CES ont fait leurs preuves en tant que
technologie de sécurité en génie mécanique et, en outre, qu'ils ont souvent permis des
concepts de protection complètement nouveaux.

 Les dépenses de développement de la part du fabricant et de validation par un organisme de

certification sont habituellement différentes de celles utilisées pour les technologies de
commande classiques. Le défi consiste à assurer la sécurité ainsi qu'une grande disponibilité
malgré une complexité élevée. Plus la flexibilité est importante, plus les coûts de production
sont faibles, moins les exigences de maintenance sont fréquentes et plus la fiabilité
compense les coûts supplémentaires.

 Presque tous les fabricants impliqués dans les processus de certification ont dû apporter des
changements conceptuels au cours du développement, parce que, dans certains cas, des
faiblesses graves sont apparues au cours de la validation.

-6-
  Souvent, seuls les fabricants impliqués dans des procédures de certification ayant plusieurs
années d'expérience des systèmes de commande de sécurité classiques avaient le savoir-faire
suffisant pour développer des solutions CES acceptables. D'autres fabricants qui abordaient
des applications de sécurité pour la première fois étaient fréquemment incapables de
produire des solutions acceptables.

 L'idée de spécifier des procédures de validation pour les PES (Systèmes Electroniques
Programmables) dans des normes si rigides que tous les organismes et tout le monde
arrivent toujours au même résultat en tous points de la validation paraît irréaliste étant
donné la complexité du sujet traité. Il existe ici une limite technique à la standardisation qui
amène à la question grave de savoir si nous ne devrions pas nous satisfaire d'une structure
pour une procédure de validation harmonisée.

Comme on peut le voir dans ces remarques, les organismes de certification européens doivent donner
des réponses constructives à la validation des CES liés à la sécurité. Les procédures de validation
sont développées, et il existe plusieurs orgnanismes qui certifient des CES liés à la sécurité
conformément à la directive machines. Il existe toujours un manque d'harmonisation entre les
différentes organismes qui travaillent dans ce domaine. Le présent rapport final du projet européen
STSARCES "Normes pour les systèmes électroniques complexes liés à la sécurité" développera une
structure pour une procédure de validation harmonisée qui doit être normalisée par
CEN/CENELEC.

-7-
2. ANALYSE DE LA SITUATION ACTUELLE

2.1. Utilisation croissante de CES pour les applications de sécurité

Au début des années 80, des systèmes électroniques ont été introduits en génie mécanique. Ils ont
d'abord été utilisés uniquement dans des fonctions non liées à la sécurité. Puis, on a essayé d'utiliser
cette technologie pour des applications sensibles pour la sécurité. Cette intention a rencontré une
forte résistance de presque tous les experts en sécurité, car les techniques électroniques ne
respectaient aucun des principes et critères de sécurité de la technologie de commande classique qui
avait été appliquée avec succès par le passé. Une comparaison montre l'ampleur du problème :
 La sécurité inhérente, en d'autres termes, la sécurité garantie par la conception de
composants individuels, ne peut être réalisée avec des systèmes électroniques.

 Il est quasiment impossible d'exclure la possibilité de panne ayant des causes physiques,
comme c'est le cas pour les circuits électromécaniques.

 La nature des défaillances éventuelles et leurs conséquences sont habituellement connues

dans le cas des composants électromécaniques ; elles sont pour la plupart inconnues en ce
qui concerne les circuits intégrés complexes.

 Les systèmes programmables sont extrêmement complexes. Nous devons accepter que ces
systèmes ne soient plus complètement testables.

 Si des modifications sont faites, il existe un risque relativement élevé, par rapport à la
technologie conventionnelle, que des défaillances graves soient intégrées.

 La compatibilité électromagnétique ne pose pas de problème pour les composants

électromécaniques ; il existe une extrême sensibilité, néanmoins, pour les systèmes
éléctroniques programmables.

Ces problèmes ont été résolus par des documents nationaux et internationaux de standardisation qui
ont introduit des exigences de base, en particulier au cours de la conception, pour contourner ces
difficultés. Tous ces documents se basent sur le cycle de vie de sécurité.

Les massicots ont vraisemblablement été les premières machines à utiliser l'informatique pour des
fonctions de sécurité au début des années 80. Ils sont utilisés en grande quantité dans les usines de
transformation du papier et sont particulièrement dangereux. Les doigts et les mains peuvent être
grièvement blessés par la lame de presse si un dysfonctionnement des dispositifs de protection
intégrés se produit. Ceci a posé des problèmes liés au manque d'expérience pratique en applications
industrielles et en méthodes d'évaluation appropriées. En coopération avec un organisme de tests
allemand, le premier fabricant de machines a décidé de développer le contrôle-commande en
redondance multiple où une voie correspondait au calculateur, une autre était câblée en logique
CMOS.

-8-
En plus de 15 ans et plusieurs générations de machines, presque tous les fabricants de grands
massicots utilisent maintenant des systèmes de commande numériques. Une technologie moderne
pour des contrôles de catégorie 4 de la norme EN 954 signifie : redondance multiple ou homogène
avec comparateur à sécurité intrinsèque, commande bimanuelle et détection par cellule
photoélectrique.

Les forts besoins de l'industrie ont obligé l'organisme national de standardisation allemand à créer
une norme générale pour les commandes numériques liées à la sécurité (voir DIN V VDE 08011). Le
contenu technique de cette norme nationale a ensuite été introduit en Europe (voir EN954-12) et
dans la standardisation internationale (voir IEC 615083).

Les équipements de protection électro-sensibles ont été utilisés pour garantir la sécurité de machines
et de zones potentiellement dangereuses pendant presque 30 ans. Jusqu'à présent, il n'a jamais été
possible de changer la géométrie du champ de protection : les calculateurs n'ont pas été utilisés avant
environ 1992. Au début des années 90, plusieurs cellules photoélectriques qui contenaient des
microcontrôleurs en redondance homogène ont été fabriquées. L'avant-projet allemand
DIN V VDE 0801 a été utilisé comme base de certification. Cette norme construit un système
hiérarchique de huit niveaux de réduction des risques basée sur la norme DIN V VDE 19250 4. Ces
premières cellules photoélectriques utilisant des CES ont été certifiées conformément au niveau 5 de
cette norme et pouvaient être utilisées comme dispositifs de protection électro-sensibles pour les
presses mécaniques.

Figure 1 : Scanner laser de protection de zone

Au cours des trois dernières années, un véritable "bond en avant " a eu lieu dans ces systèmes. Non
seulement les microprocesseurs, mais également les principes physiques appliqués sont en train de
révolutionner la philosophie de sécurité antérieure des équipements protecteurs électro-sensibles. Par
le passé, la fonction de sécurité des dispositifs protecteurs électro-sensibles était activée
exclusivement par l'interruption du faisceau de lumière.

Dans l'exemple illustré (Figure 1) du "scanner laser", le corps humain dans la zone de danger est
détecté par la réflexion d'un faisceau de lumière infrarouge. Un faisceau de lumière pivotant balaie
rapidement la zone de danger et transmet une image de la zone au calculateur. Pour déterminer la
position exacte de la personne, le temps de parcours aller et retour de la lumière de l'équipement
jusqu'à la personne est mesuré. La géométrie du champ protecteur peut être ajustée par le logiciel.
-9-
Le scanner électro-sensible décrit ici est mis en œuvre pour gérer des fonctions de sécurité de
catégorie 3 conformément à la norme EN 954. L'architecture du système est à voie unique avec de
nombreux autotests et des dispositifs de surveillance5 supplémentaires.

Aujourd'hui, plus de soixante mille dispositifs électro-sensibles commandés par microprocesseur sont
utilisés dans toutes sortes d'applications.

Des centres d'usinage à commande numérique possèdent des installations pour permettre le
changement d'outil automatique à partir d'un magasin ou d'une unité de stockage similaire
conformément au programme d'usinage. La situation la plus dangereuse est un mouvement,
démarrage ou accélération de vitesse imprévu alors que l'ouvrier observe le processus tandis que les
caches et protections mécaniques sont encore ouverts. Pour éviter ce risque, les centres d'usinage
nécessitaient par le passé qu'on ouvre et qu'on ferme les caches et protections mécaniques très
souvent en mode réglage.

Dans un nouveau concept de sécurité, basé sur l'informatique, le technicien peut opérer en mode
réglage à côté de caches et protections ouverts et observer et estimer les mouvements de la machine.
Dans la nouvelle approche, une surveillance de sécurité a été intégrée dans un calculateur à
redondance multiple. Les calculateurs avant tout responsables des fonctions non liées à la sécurité de
la machine font partie de l'architecture à redondance multiple6.

Si le mouvement automatique est commandé de cette manière sûre, l'utilisateur peut évoluer à
l'intérieur de zones définies. Toute déviation dans l'espace ou toute vitesse est détectée par le
système d'entraînement à vitesse réglable à redondance multiple, réalisé par un logiciel. De manière
extrêmement flexible, la machine peut être adaptée au travail de l'utilisateur et non le contraire.

- 10 -
 2.2. Base pour la validation des CES

Comme indiqué dans le paragraphe précédent, les CES liés à la sécurité sont aujourd'hui certifiés
conformément à la norme EN 954 en conjonction avec des spécifications nationales, comme
DIN V VDE 0801. Certaines autorités ont également utilisé la norme internationale IEC 61508 pour
la certification de contrôleurs logiques programmables liés à la sécurité7. Dans la plupart des cas, un
certificat mentionne la norme EN 954-1, des spécifications nationales et quelquefois la norme IEC
61508 comme exigences de tests. Cependant, il n'existe pas aujourd'hui de procédure utilisée au
niveau international pour la validation des CES liés à la sécurité dans le secteur des machines et dans
la pratique entre stations de tests en Europe. Quelques remarques générales peuvent être faites sur la
base des procédures utilisées aujourd'hui :
 La validation à la fin du développement uniquement, lorsque le produit est terminé, n'est
plus possible. Comme le processus de développement lui-même est un sujet essentiel de
validation, il est recommandé d'impliquer l'organisme de validation dès la conception afin de
se mettre d'accord sur les documents à soumettre.

 La spécification des CES liés à la sécurité est d'importance capitale et doit être inspectée par
l'autorité de certification. L'une des entrées importantes de la spécification est la nécessaire
réduction de risque des CES lorsqu'ils sont utilisés dans une fonction de sécurité spécifique.
Si un CES n'est pas fabriqué en vue d'une fonction de sécurité spécifique, la réduction de
risque minimum réalisable des CES, en tant que sous-système, doit être spécifiée.

 Au cours de toutes les phases du cycle de vie du produit, des mesures analytiques et de tests
sont nécessaires pour réaliser un produit qui soit robuste par rapport aux pannes
systématique et fortuite. Ces mesures peuvent être prises principalement par le fabricant de
CES et elles accroissent considérablement les efforts de développement.

 Les logiciels deviennent de plus en plus importants pour l'intégrité de sécurité des CES
modernes. Une compréhension étendue des logiciels liés à la sécurité est essentielle à la
validation des CES. Plus le matériel semble simple, plus les logiciels intégrés peuvent être
complexes.

 L'installateur et l'utilisateur des CES ont besoin d'informations suffisantes et également de

logiciels ergonomiques pour une installation sûre des CES liés à la sécurité. Cette
documentation et le logiciel forment une partie très importante du processus de validation.

 La modification des CES est un processus très critique et doit être planifié au cours de la
première conception. Les organismes de certification doivent être impliquées dans le
processus complet de maintenance des CES liés à sécurité.

Le chapitre suivant décrit une procédure harmonisée pour la validation des CES liés à la sécurité
tandis que le Chapitre 4 considère la possibilité d'application de la norme EN 954 et de la norme
IEC 61508 au secteur de la machine.

- 11 -
3. ATTEINDRE LA SÉCURITÉ EN SUIVANT LE CYCLE DE VIE

3.1. Introduction

3.1.1. Le cycle de vie de sécurité global

La complexité des systèmes électroniques actuels est telle qu'il est impossible à l'analyste de valider le
niveau de sécurité d'un système CES en effectuant des activités de test uniquement lorsque le
processus de conception est bien entamé ou même terminé.

Cette nouvelle approche, appelée le cycle de vie, n'était pas aussi importante pour les technologies
électromécaniques ou électroniques à faible intégration qui étaient généralement utilisées jusqu'à
présent dans la sécurité des machines.

Pour traiter correctement la sécurité, il est maintenant nécessaire d'avoir une vue globale des
différentes étapes qui délimitent la "vie" d'une application, à partir de la définition des limites de cette
application jusqu'à, au moins, la validation de sécurité (il est souvent difficile pour les machines de
traiter de la maintenance et de la mise en service finale des éléments). Ces étapes sont généralement
regroupées au sein du cycle de vie de sécurité au niveau global de l'application (cf. norme IEC
61508-1). Ceci établit les activités nécessaires pour mettre en œuvre les différents moyens de réduire
le risque, c'est-à-dire les CES, mais également les systèmes liés à la sécurité basés sur d'autres
technologies et des installations externes de réduction des risques.

Trois grandes parties dans le cycle de vie global de sécurité peuvent être distinguées.
[1]Les premières étapes, basées sur la définition du concept et une analyse des risques et
des dangers au niveau global de l'application en particulier, amènent à l'affectation
d'exigences de sécurité aux différents moyens de réduire les risques. Deux systèmes de
référence peuvent éventuellement être employés pour effectuer les analyses de danger
et de risque : la norme EN 954 (en conjonction avec la norme EN 10508) et la norme
IEC 61508 (voir Chapitre 4 pour le choix d'un système de référence).

[2]Puis vient le cycle de vie inhérent au développement des CES employés, mais
également aux systèmes liés à la sécurité basés sur d'autres technologies et des
installations externes de réduction des risques.

[3]Ces deux premières parties sont complétées par les phases d'installation et de
validation globale de la sécurité, de fonctionnement et de modifications éventuelles
des E/E/PES (avec, le cas échéant, un retour à la phase adéquate du cycle de vie).

- 12 -
 3.1.2. Le cycle de vie de sécurité des E/E/PES

Dans cette section, le contenu du cycle de vie concernant le développement des CES est examiné. Ce
cycle commence à la spécification des conditions nécessaires et suffisantes à la réalisation de tels
systèmes et se termine lorsque tous les systèmes liés à la sécurité ne sont plus disponibles à
l'utilisation.

Les phases principales qui constituent le cycle de vie sont les suivantes :
 Spécification : basée sur l'affectation faite dans le cycle de vie global de sécurité, cette phase
spécifie des fonctions de sécurité effectuées par le CES ainsi que la performance en termes
de niveau intégrité de sécurité (IEC 61508) ou de catégorie (EN 954), le choix de l'un ou de
l'autre étant orienté par la considération des éléments indiqués au Chapitre 4.

 Conception et développement : cette phase a pour but de concevoir et produire le matériel

et les logiciels des CES afin de respecter les exigences établies au cours de la phase de
spécification. La planification de la validation de sécurité des CES en question doit avoir
lieu au cours de cette phase.

 Validation : La validation a pour but de garantir que les exigences établies au cours de la
phase de spécification sont bien respectées.

Afin que l'analyste ne soit pas juge et partie, ses interventions sont prioritairement limitées au niveau
de la spécification et de la validation des CES.

3.1.3. Le cycle de vie des logiciels

Le cycle de vie des logiciels est un sous-ensemble du cycle de vie des CES qui concerne les activités
ayant eu lieu au cours d'une période qui commence lorsque le logiciel est conçu et se termine lorsque
le logiciel est abandonné de manière permanente.

Le déroulement des activités est défini en relation avec les particularités du projet, par exemple
complexité du système considéré et des logiciels, utilisation finale de produits développés
auparavant, production d'un prototype ou disponibilité des matériaux de tests. L'organisation de ces
activités peut être représentée par différents cycles de vie distincts, définis en fonction du type de
projet en question.

3.1.3.1. Le cycle de vie en « V » du logiciel

Le cycle en forme de « V » est choisi parce qu'il est adapté aux produits logiciels. Une activité de
tests est placée directement en face d'une activité de développement pour s'assurer que les éléments
spécifiés ont été correctement réalisés.

Ce cycle de vie correspond à une activité de développement continu et itératif. Cette représentation
en forme de V est illustrée dans le schéma suivant :

- 13 -
 Vérification
Spécifications du Validation du
système système

Vérification
Spécifications du Tests de validation
logiciel logicielle

Conception préliminaire Vérification Tests d'intégration

logicielle
(architecture logicielle)

Vérification Tests de modules

Conception détaillée
(Tests unitaires)

Codage

Figure 2 : Le cycle de vie en V du logiciel

La définition des logiciels comprend habituellement les activités de développement séquentielles

suivantes :
 Spécifications : activité qui consiste en la description des fonctionnalités logicielles prévues
et qui prend en compte des entrées et toutes contraintes applicables.

 Conception : activité de construction de l'architecture logicielle (habituellement appelée

"conception préliminaire"), qui permet la mise en œuvre de spécifications logicielles et la
construction d'algorithmes détaillés (activité généralement appelée "conception détaillée").
Le code source peut alors être construit sans aucune autre information.

 Codage : activité de production du code source, en langages appropriés, qui peut ensuite
être accepté par un assembleur ou un compilateur pour la production d'instructions
exécutables pour utilisation par le processeur cible.

 Production du code exécutable : activité au cours de laquelle les différents composants du

code sont groupés (en particulier par édition de liens) en une forme qui permet la génération
d'un code exécutable pour chargement dans le système cible.

Ces activités de définition sont complétées par les activités de vérification logicielle, dont le but est
de vérifier que le produit logiciel répond aux exigences spécifiées à chaque étape de développement
et de vérifier toutes les erreurs qui ont pu être introduites au cours du développement du logiciel.

L'activité principale de toute vérification logicielle est la conduite de tests. D'autres activités telles
que l'examen ou l'analyse sont des composants éventuels de la vérification logicielle. Les activités de
tests des logiciels comprennent généralement différentes phases qui correspondent à différentes
activités de développement :

- 14 -
  Tests de modules au niveau de chaque module individuel qui peuvent être utilisés pour
démontrer que le module effectue la fonction spécifiée et seulement cette fonction.
Différents types de tests de modules peuvent être déterminés, y compris tests logiques
(recherche d'erreur, vérification de l'exactitude des interconnexions des différentes branches,
recherche de comportement anormal) et des tests de calcul (vérification de résultats de
calcul, algorithmes de performance et d'exactitude). Les tests de calcul incluent typiquement
des tests de données au sein de limites de spécification ainsi qu'en dehors de ces limites, aux
limites spécifiées, et aux singularités algorithmiques. Les tests de comportement anormal
sont généralement appelés tests de robustesse.

 Les tests d'intégration logicielle sont utilisés pour démontrer que les unités fonctionnelles
constituées d'un ensemble de modules opèrent correctement. Ce type de tests concerne
principalement la vérification des interconnexions entre modules, la circulation de données,
les aspects dynamiques et la mise en séquence d'évènements prévus. Ils comprennent
typiquement des tests sur les connexions inter modulaires, les aspects dynamiques, la mise
en séquence d'évènements prévus, et la reprise des opérations en cas d'interruption.

 Les tests de validation servent à vérifier que le logiciel installé sur le matériel répond aux
spécifications fonctionnelles, en vérifiant particulièrement les interfaces matériel/logiciels,
les niveaux de performance généraux, l'exploitation en temps réel, les fonctions générales et
l'utilisation et l'affectation de ressources.

3.1.3.2. Autres cycles de vies logiciels

Il existe d'autres cycles de vie de sécurité dont il n'a pas été question précédemment comme le cycle
de vie incrémentiel qui concerne en priorité ces projets qui n'ont pas été précisément définis. Le cycle
de vie envisagé concerne des projets qui traitent du développement d'un concept de produit reposant
sur des technologies innovantes ou pas encore totalement maîtrisées.

3.1.4. Exigences de cycle de vie

Le but des exigences de cycle de vie1 suivantes est d'obtenir une description formalisée de
l'organisation du développement et, en particulier, des différentes tâches techniques qui composent le
développement. Cette description encourage la planification améliorée des activités de
développement, et permet une réflexion plus approfondie sur la gestion optimale du temps pour ce
développement.

Le cycle de vie de développement des logiciels doit être spécifié et documenté (par exemple dans un
Plan de qualité logiciel). Le cycle de vie doit inclure toutes les activités techniques et les phases
nécessaires et suffisantes au développement logiciel.

Chaque phase du cycle de vie doit être divisée en tâches élémentaires et doit inclure une description :
 des entrées (documents, normes, etc.),
 des sorties (documents produits, rapports analytiques, etc.),

1
Ces exigences ne sont pas réservées au cycle de vie des logiciels et peuvent donc s'appliquer à la conception des différents sous-ensembles d'un CES.

- 15 -
  des activités à effectuer,
 des vérifications à réaliser (analyses, tests, etc.).

La documentation nécessaire doit être établie à chaque phase du cycle de vie pour faciliter la
vérification et la validation et les exigences de sécurité logicielle doivent être identifiables et
vérifiables à chaque étape du processus (matrice de traçabilité pour chaque document de définition).
Ceci évitera une situation où seule la documentation disponible constitue le code source parce que
les documents qui auraient dû être préparés ne l'ont pas été (délais trop courts, responsable de projet
transféré sur un autre contrat, etc.).

L'analyste doit être capable d'effectuer l'évaluation de la conformité du logiciel aux exigences
présentes en conduisant tous audits ou expertises jugés utiles au cours des différentes phases de
développement du logiciel.

Tous les aspects techniques des processus du cycle de vie des logiciels sont soumis à l'évaluation de
l'analyste.

On doit permettre à l'analyste de consulter tous les rapports de vérification (tests, analyses, etc.) et
tous les documents techniques utilisés au cours du développement du logiciel.

L'intervention de l'analyste à la phase des spécifications est préférable à une intervention a posteriori
puisque cela limiterait l'impact de toute décision prise. D'autre part, les aspects financiers et humains
du projet ne sont pas soumis à évaluation.

L'analyste doit avoir tous les éléments nécessaires à sa disposition afin de formuler une opinion. Les
logiciels en contrat de sous-traitance ne doivent pas être exclus de la procédure d'évaluation et
doivent être conformes aux exigences de la même documentation.

- 16 -
 3.2. Spécifications

3.2.1. Procédure de spécification pour les logiciels de sécurité

Aujourd'hui, les programmes logiciels sont caractérisés par leur complexité et leur taille telles qu'il
semble excessivement optimiste d'essayer d'éviter tous les défauts qu'ils contiennent au moyen de leur
construction et de tests à la fin de leur développement. Afin de maîtriser le développement de
logiciels, il est absolument nécessaire qu'une procédure adaptée à cette technologie soit établie.

Au cours de la durée de vie d'un programme logiciel, l'une des étapes les plus délicates à accomplir
est la traduction de besoins en spécifications. La rédaction de spécifications et la possibilité d'évaluer
ces spécifications sont des avantages très importants, en particulier pour les logiciels de sécurité.
Ceci est confirmé par une étude menée par HSE concernant les causes primaires de panne, basée sur
34 incidents, qui montre que la proportion principale (44 %) est causée par de mauvaises
spécifications (Figure 3).

On estime que la correction d'une erreur de spécification demande environ 20 fois plus d'efforts
lorsqu'elle est détectée au cours de l'utilisation, et quelquefois même plus. En fait, les conséquences
des pannes logicielles ne se limitent pas au réparations. Dans certains cas, des vies humaines peuvent
être impliquées.

Les systèmes en développement sont souvent accompagnés d'exigences de qualité, certes

nécessaires, mais insuffisantes dans le cas des systèmes de sécurité. Les exigences de qualité peuvent
être considérées au même titre que les exigences de sécurité.

Prim ary cause of control system failure[based on

34 incidents]

Design &
14.70%
44.10 % im plem entation
5.9 0%
Ins tallation &
c o m m iss ionin g
O peration& m aintena nce
1 4.70%
Changes after
20.6 0% c o m m iss ionin g
S pec ification

Figure 3 : Portion principale attribuée aux spécifications dans les causes de panne

Les procédures de spécifications des logiciels de sécurité tombent dans le cadre d'une approche de
sécurité de l'exploitation de systèmes qui permet de maîtriser les risques du système dans son
environnement. Il s'agit d'une approche méthodologique complète qui doit être planifiée et
systématique, afin d'identifier, analyser et contrôler les risques tout au long du cycle de vie du
système, en particulier tout au long du cycle de vie du logiciel, avec pour intention d'anticiper et de
réduire les incidents.
- 17 -
Alors que les procédures de qualité traditionnelle mettent en œuvre des moyens qui tendent à un
système exempt de défaut, la procédure de sécurité d'exploitation met en œuvre d'autres moyens afin
de tendre à un système exempt de panne (Figure 4).

L'objectif zéro défaut est une illusion qu'il faut complètement abandonner face aux exigences strictes
de sécurité. Il est irréaliste d'essayer de limiter tous les défauts, tentative qui conduit à des efforts
énormes bien supérieurs aux règles économiques ordinaires et au-delà des limites actuelles de la
technologie de production des logiciels et de l'état de l'art.

FAULT FAULT FAULT FAULT

PREVENTION TOLERANCE ELIMINATION FORECAST

Grant the system the aptitude Obtain confidence in the aptitude

Strive for a system
to provide services of the system to provide
exempt from faults
which fulfil its function services which fulfil its function

AVOID
ATTAINMENT VALIDATION
FAULTS

OPERATION SAFETY

Zéro ZERO
fault failure

Figure 4 : Moyens de sécurité d'exploitation

3.2.2. Méthodes de spécification

Des méthodes et outils d'Atelier de Génie Logiciel (AGL) sont offerts aux développeurs, afin de les
aider et de les accompagner dans leur travail. Le tableau ci-après fournit une liste non exhaustive des
quelques méthodes de spécification et de leurs principales caractéristiques.

Ces méthodes peuvent être utilisées pour tout type de logiciels. Les exigences de sécurité au niveau
des spécifications du logiciel sont prises en compte par les méthodes de sécurité d'exploitation.

- 18 -
 Nom Phase dans le Remarques
cycle de vie
PN Spécification Méthode basée sur des systèmes de transition, utilisant des
Réseau Pétri Développement jetons de réseau et des espaces. Elle permet de démontrer
des propriétés comme tolérance au blocage, réactivité ou
équité d'un ensemble de processus coopérants. Elle est
souvent utilisée pour spécifier le parallélisme et la
synchronisation.
Statecharts Spécification Méthode de spécification basée sur des systèmes de
Développement transition.

SADT Spécification, Méthode de spécification graphique. Elle utilise des cases

(Structured Analysis conception pour représenter les données ou les activités et des flèches
Design Technique, Développement pour représenter les flux entre ces données ou ces
technique de conception activités. Elle est quelquefois désignée comme une
d'analyse structurée) méthode de conception semi-formelle et est souvent
utilisée dans l'industrie.
SART Spécification Extension en temps réel proposée pour la méthode
(Structured Analysis Développement structurée S.A. de E. Yourdon et T. de Marco. Une des
Real Time, analyse méthodes d'analyse structurée logicielle les plus utilisées
structurée temps réel) pour les applications en temps réel.

Z Spécification, Langage de spécification formelle basé sur la théorie

conception Zermelo des ensembles. Elle permet d'exprimer les
Développement conditions fonctionnelles du problème à traduire en
notation fixe.
LDS Spécification Langage de spécification et de description fonctionnelle. Il
Développement est soumis à la norme CCITT.

CCS Spécification Formalisme utilisé pour décrire la sémantique de

Développement parallélisme. Il est basé sur une algèbre de processus et
reste très abstrait et impossible à utiliser pour tirer des
conclusions utiles.
CSP Spécification Présente les mêmes caractéristiques que CCS.
Développement

Tableau 1 : Méthodes de spécification

3.2.3. Outils d'AGL pour les spécifications des logiciels de sécurité

À notre connaissance, aucun AGL ne combine des outils de spécification et des outils de sécurité
d'exploitation pour des spécifications logicielles, tout en prenant en compte les exigences de sécurité.
Néanmoins, il existe tout un ensemble de programmes logiciels de spécification logicielle sur le
marché qui mettent en œuvre des méthodes formelles et des méthodes semi-formelles (méthodes
SART, méthodes SADT, etc.), ainsi que des programmes logiciels qui permettent de créer des
schémas d’arbres de panne et des AMDEC.

- 19 -
 Outil Concepteur Plate-forme Méthode
ATELIER B STERIA, GEC-ALTHOM UNIX (HP-UX-LINUX- Méthode B formelle
SOLARIS)
AXIOM/SYS STG Microsoft (Windows 3.xx, SART
Windows 95, Windows NT)
DESIGN IDEF METASOFTWARE Microsoft (Windows 3.xx, IDEF0 et IDEFIX
Windows 95, Windows NT)
ENVISION FUTURE Microsoft (Windows 3.xx, SART, SADT, UML
TECH.SYSTEMS
Windows 95, Windows NT)
OBJECT GEODE VERILOG UNIX (AIX, HP, UX, SOLARIS, OMT, SDL, MSC
SUN/OS)
ORCHIS TNI Microsoft et UNIX IDEF0
STP-SE AONIX Microsoft et UNIX SART
SYNCCHARTS SIMILOG UNIX Esterel
TEAMWORK CAYENNE Microsoft, UNIX SART

Tableau 2 : Outils de cas pour les spécifications des logiciels de sécurité

Les méthodes formelles sont plus qu'un outil de représentation ; elles sont aussi une technique pour
rédiger des spécifications qui empêchent le concepteur de faire des abstractions et résultent
finalement en une meilleure analyse et un degré accru de modélisation des problèmes de
spécification. Il est quelquefois même possible d'effectuer des simulations.

L'utilisation d'une méthode formelle demande des investissements considérables en temps et en

formation. Les méthodes formelles sont un pas en avant significatif pour le développement et
l'évaluation des logiciels critiques.

- 20 -
 Spécifications logicielles Niveau
1 2
Les spécifications logicielles doivent prendre en compte les points suivants : O O
 fonctions de sécurité avec une description quantitative des critères de performance
(précision, exactitude) et des contraintes temporelles (temps de réponse) avec pour
toutes des tolérances ou des marges si possible,
 fonctions non liées à la sécurité avec une description quantitative des critères de
performance (précision, exactitude) et des contraintes temporelles (temps de
réponse) avec pour toutes des tolérances ou des marges si possible,
 architecture ou configuration du système,
 instructions relatives à l'intégrité de sécurité matérielle (systèmes électroniques
programmables, capteurs, actionneurs, etc.),
 instructions relatives à l'intégrité logicielle et à la sécurité des fonctions de
sécurité,
 contraintes relatives à la capacité de mémoire et au temps de réponse du système,
 interfaces matériel et opérateur,
 instructions pour l'auto-surveillance des logiciels et pour la surveillance du
matériel effectuée par les logiciels,
 instructions permettant le contrôle de toutes les fonctions de sécurité au cours du
fonctionnement du système (tests en ligne).
Les instructions de surveillance, développées en prenant en compte les objectifs de sécurité et les contraintes
de fonctionnement (durée de fonctionnement en continu, etc.) peuvent inclure des dispositifs comme les
chiens de garde, la surveillance de chargement de l'UC, retour d'informations des sorties et entrées pour
l'auto-surveillance des logiciels. Pour la surveillance matérielle, surveillance mémoire et UC, etc.
Instructions pour la vérification des fonctions de sécurité : par exemple, la possibilité de vérifier de manière
périodique le fonctionnement correct des dispositifs de sécurité doit être incluse dans les spécifications.

Les exigences de fonctionnement doivent être spécifiées pour chaque mode de O O

fonctionnement. La transition d'un mode à l'autre doit être spécifiée.
Les modes de fonctionnement peuvent inclure :
 modes nominaux,
 un ou plusieurs modes dégradés.
L'objectif est de spécifier le comportement dans toute situation afin d'éviter des comportements non prévus
dans des contextes non nominaux.

Tableau 3 : Spécifications logicielles

Notation : Les exigences abordées dans le présent document s'organisent en deux niveaux d'exigences logicielles (1,
2) selon la criticité des fonctions assurées par le logiciel. Le niveau 2 correspond aux exigences les plus
élevées pour le logiciel considéré dans le présent document. Le niveau associé à une fonction donnée
dépend d'une analyse des risques du système complet.
Le niveau peut être utilisé pour établir une liste d'exigences élémentaires pour le logiciel considéré. Trois degrés
d'importance peuvent être définis pour aider à décider s'il est ou non nécessaire d'envisager une exigence donnée
comme fonction du niveau de criticité :
 "O" (Exigence de qualité Obligatoire) : cette exigence doit être appliquée systématiquement au
logiciel en question.
 "R" (Exigence de qualité Recommandée) : l'application de cette exigence est recommandée mais pas
systématiquement imposée.
 "/" (pas d'exigence) : l'application de cette exigence est laissée à la discrétion de l'utilisateur.

- 21 -
 3.3. Architecture

L'architecture d'un CES lié à la sécurité est l'un des éléments clés pour atteindre la catégorie requise
(CAT) ou le niveau d'intégrité de sécurité (SIL). C'est la raison pour laquelle les architectures jouent
un rôle important dans la connexion des catégories (EN 954) et des niveaux d'intégrité de sécurité
(SIL – IEC 61508).

Les exigences d'architecture sont liées aux logiciels et au matériel. Dans le premier paragraphe de ce
chapitre, les architectures matérielles communément utilisées pour les machines (appelées
"architectures désignées") sont décrites et une vue générale des simulations Markov de ces
architectures est donnée. Dans le second paragraphe, l'influence de l'architecture logicielle est
analysée. Une quantification de cette influence ne peut être considérée que partiellement en utilisant
le facteur de cause commune.

3.3.1. Architectures CES désignées pour les machines

3.3.1.1. Le rôle des architectures pour les systèmes liés à la sécurité

En étudiant la norme EN 954-1, on peut interpréter les exigences pour les différentes catégories en
tant que contraintes architecturales pour la conception de composants liés à la sécurité de systèmes
de commande. Dans les catégories B et 1, une architecture à voie unique sans installation de
surveillance est décrite, tandis que la catégorie 2 spécifie une architecture à voie unique avec
surveillance et chemin de désactivation redondant et les catégories 3 et 4 nécessitent normalement un
traitement du signal redondant et une réaction pour remplir les exigences. Par exemple, le transfert
des exigences de la norme EN 954-1 en systèmes électroniques complexes liés à la sécurité mènera à
différentes architectures de système utilisées dans le secteur des machines.

En mettant ces architectures communes dans différents modèles Markov, la probabilité d'une panne
dangereuse par heure (PDF) ou la probabilité de panne à la demande (PFD) peut être calculée pour
différentes couvertures de diagnostic et facteurs de cause commune. Les résultats de ces calculs
peuvent être utilisés pour établir des relations entre les architectures communément utilisées dans le
secteur des machines et les différents niveaux d'intégrité de sécurité tels que définis en IEC 61508-1.

Le paragraphe suivant décrit les architectures communément utilisées pour les CES dans le secteur
des machines. Plusieurs hypothèses peuvent être avancées qui sont typiques de ces architectures. Un
test d’intégrité n'est pas standard pour les CES dans le secteur des machines. L'intervalle de test
d’intégrité a donc été fixé 10 ans, ce qui est le temps moyen d'utilisation de CES lié à la sécurité
aujourd'hui (appelé le "temps de mission").

- 22 -
 3.3.2. Architectures communes pour les machines

3.3.2.1. Système à voie unique sans détection de défaut conformément

à la catégorie B ou 1 de la norme EN 954-1

Les Catégories B ou 1 conformément à EN 954-1 impliquent que le système ne fournit pas de

capacité de détection des défauts internes. Pour la catégorie 1, les composants et principes de
sécurité utilisés doivent être non seulement basiques mais encore éprouvés, ce qui signifie qu'on
atteint une plus forte fiabilité et donc que la probabilité de panne du système est plus faible qu'en
catégorie B (voir la norme EN 954-1, § 6.22).

Soit le système comprenant un capteur (S), un dispositif électronique programmable (PED) avec une
alimentation électrique intégrée et un actionneur (D) contrôlé par le PED, il peut être représenté :

Figure 5 : Synoptique d'un système à voie unique sans détection de défauts

Normalement, un dispositif électronique simple n'est pas considéré comme un composant éprouvé. Il
n'est donc pas possible de réaliser un système de sécurité à voie unique de catégorie 1 en utilisant un
PED.

Trois hypothèses ont été avancées afin de déterminer le SIL :

[1] La désactivation de l’actionneur est l'action appropriée pour générer un état de
sécurité de la machine (appelé "équipement contrôlé" (EUC) dans la norme
IEC 61508) à laquelle l’actionneur appartient.

[2] Le système de sécurité n'est pas capable d'induire une situation dangereuse de lui-
même. Le pire des cas qui peut se produire est une panne dangereuse, c'est-à-dire
que le système ne peut effectuer sa fonction de sécurité prévue.

[3] Les pannes sont uniquement révélées par une demande de la fonction de sécurité.
Ceci amène à une situation dangereuse qui sera suivie d'une réparation.

- 23 -
 3.3.2.2. Système à voie unique avec tests mis en œuvre conformément
à la catégorie 2 de la norme EN 954-1

La catégorie 2 de la norme EN 954-1 demande que des autocontrôles soient exécutées par le
système dédié à la sécurité à intervalles convenables. Les tests peuvent être initiés soit manuellement,
soit automatiquement. Si un défaut est détecté, un signal de sortie doit être généré afin d'initier une
action de contrôle appropriée. Chaque fois que cela est possible, un état de sécurité doit être induit.

Ces exigences impliquent que l'occurrence d'un défaut puisse amener à la perte de la fonction de
sécurité entre les intervalles de vérification. De plus, il convient de remarquer que de nombreuses
techniques de tests typiques ne fournissent pas une couverture de diagnostic de 100%. Il peut donc
exister des défauts au sein du dispositif de sécurité qui ne peuvent être détectés par les vérifications.

Une architecture de systèmes représentative pour la catégorie 2 est présentée par le synoptique de la
Figure 6.

Figure 6 : Synoptique d'un système à voie unique avec mise en œuvre de tests

Par rapport au système simple de la Figure 5, un chien de garde (WD) a été ajouté afin de surveiller
le fonctionnement du dispositif électronique programmable (PED). Une alimentation électrique est
intégrée au PED. L’actionneur (D) possède deux entrées séparées, la première (Ip) pour le PED et
une seconde (Iw) pour le chien de garde, chacune fournissant une capacité d'interruption complète.
Le système effectue également des tests périodiques du capteur, du ou des chemins de désactivation
de l’actionneur et du chien de garde.

Plusieurs hypothèses ont été avancées afin de faciliter la création d'un modèle de Markov
convenable :
[1] La désactivation de l’actionneur est l'action appropriée pour générer un état de
sécurité de l'équipement contrôlé (EUC) auquel l’actionneur appartient.

- 24 -
 [2] Le système de sécurité n'est pas capable d'induire une situation dangereuse de lui-
même. Le pire des cas qui peut se produire est une panne dangereuse, c'est-à-dire
que le système ne peut effectuer sa fonction de sécurité prévue.

[3] Le dispositif électronique programmable (PED) effectue périodiquement un

autotest. La détection d'un défaut dangereux dans le PED est reconnue par
l'absence d'impulsion de déclenchement au cours du délai du chien de garde (WD).
Ce test en ligne est caractérisé par le taux de test et la couverture de diagnostic CPE
à laquelle on affecte une valeur entre zéro et un. Le CPE est la probabilité
conditionnelle qu'une panne dangereuse de PED soit détectée, étant donné qu'elle a
eu lieu. Dans ce cas, le PED n'est plus capable de déconnecter l’actionneur via
l'entrée Ip, même si ceci peut être nécessaire. Si le défaut est détectable, le lecteur
sera déconnecté par le chien de garde via l'entrée Iw (en supposant que WD et Iw
sont tous les deux opérationnels).

[4] Le capteur et le chemin de désactivation interne de l’actionneur commençant à

l'entrée Ip de l’actionneur sont testés périodiquement par le PED. On suppose que
les couvertures de diagnostic sont égales à un tout au long de la durée des tests.

[5] Le chien de garde est également testé par le PED. On suppose que la couverture de
diagnostic est égale à un. Il y a deux manières de surveiller le fonctionnement du
chien de garde. Son signal de sortie peut être soit directement relu par le PED, soit
le chemin de désactivation interne de l’actionneur commençant à l'entrée Iw de
l’actionneur peut être incluse dans la boucle de test. Dans ce dernier cas, le chemin
de désactivation est inclus dans la boucle de test. Ceci peut être exprimé par la
couverture de diagnostic qui est fixée soit à zéro, soit à un.

[6] Toute panne qu'on a réussi à détecter conduira le système à un état de sécurité non
volatil avec déconnexion de l’actionneur. On suppose que le système est
déconnecté manuellement de l'alimentation électrique jusqu'à ce qu'il ait été réparé
ou remplacé par un neuf.

[7] Si le PED est tombé en panne, il n'effectuera plus de tests sur les composants
externes au PED, c'est-à-dire que S, Ip, WD et Iw ne sont pas testés en cas de
panne du PED.

[8] Afin de décrire l’actionneur par un seul taux de panne dangereuse, ce taux est
distribué également entre les entrées Ip et Iw respectivement.

3.3.2.3. Système voies doubles avec comparaison conformément à la

catégorie 3 ou 4 de la norme EN 954-1

EN 954-1 demande qu'un dispositif de catégorie 3 reste opérationnel si un défaut unique est présent
en n'importe quel point du système. De plus, toutes les fois que cela est raisonnablement applicable,
le défaut unique doit être détecté avant ou à la demande suivante de la fonction de sécurité. Ceci
inclut que tous les défauts ne devraient pas être détectés et que l'accumulation de défauts non
détectés peut amener à une sortie non prévue et à une situation dangereuse au niveau de la machine.
Les pannes de mode commun doivent être prises en compte.

- 25 -
Outre les exigences mentionnées ci-avant, il existe des exigences plus rigides à remplir par un
système de sécurité revendicant une conformité à la catégorie 4. Le défaut unique doit être détecté
(aussi tôt que possible) et, si cette détection n'est pas possible, alors une accumulation de défauts ne
doit pas amener à une perte des fonctions de sécurité.

Le problème de la fourniture des fonctions de sécurité après l'occurrence d'un défaut est souvent
résolu par la mise en œuvre de la redondance. Un exemple typique pour la redondance homogène est
donné par le système à voies doubles illustré par la Figure 7. La possibilité d'atteindre la catégorie 3
ou 4 dépend de la mesure dans laquelle les défauts peuvent être détectés ou tolérés.

Le système comprend deux capteurs (S1, S2) du même type et deux dispositifs électroniques
programmables (PED1, PED2) de type identique, avec alimentation électrique intégrée à chaque
PED, combinés à un seul actionneur (D). Les deux PED sont connectés à une entrée individuelle
(IN1, IN2) de l’actionneur.

Figure 7 : Synoptique d'un système à voies doubles avec comparaison

Là encore, il existe un certain nombre d'hypothèses raisonnables qui ont été avancées pour obtenir un
modèle Markov convenable :
 Hypothèse 1 : La désactivation de l’actionneur est l'action appropriée pour générer un état
de sécurité de l'équipement contrôlé (EUC) auquel le lecteur appartient.

 Hypothèse 2 : Le système de sécurité n'est pas capable d'induire une situation dangereuse de
lui-même. Le pire des cas qui peut survenir est une panne dangereuse, c'est-à-dire que le
système ne peut effectuer sa fonction de sécurité prévue.

 Hypothèse 3 : Des tests périodiques en ligne sont effectués par les deux dispositifs
électroniques programmables (PED). L'ensemble de tests complets comprend :
 un auto-test de PED1 contrôlé et surveillé par PED2,
 un auto-test de PED2 contrôlé et surveillé par PED1,
 un test du chemin de désactivation interne de l’actionneur qui commence à l'entrée IN1
de l’actionneur, effectué par PED1,

- 26 -
  un test du chemin de désactivation interne de l’actionneur qui commence à l'entrée IN2
de l’actionneur, effectué par PED2,
 une comparaison des signaux de sortie des deux capteurs (S1, S2), effectuée par PED1
et PED2 ensemble.

Chacun des tests vérifie des sous-fonctions qui sont effectuées par les différents
composants. Effectuer toutes les sous-fonctions correctement est une condition préalable
pour que le système de sécurité fournisse sa ou ses fonctions de sécurité prévues.

 Hypothèse 4 : Les auto-tests mutuellement contrôlés et surveillés des PED sont caractérisés
par une couverture de diagnostic à laquelle on peut affecter une valeur entre zéro et un.

 Hypothèse 5 : La couverture de diagnostic liée aux capteurs est égale à un. Dans certains
cas, la caractéristique sera mise en œuvre, dans d'autres, elle ne le sera pas. Ceci peut être
exprimé par la couverture de diagnostic fixée soit à zéro soit à un.

 Hypothèse 6 : La couverture de diagnostic liée aux chemins de désactivation internes à

l’actionneur, commençant aux entrées IN1 et IN2 de l’actionneur est égale à un. Dans
certains cas, la caractéristique sera mise en œuvre, dans d'autres, elle ne le sera pas. Ceci
peut être exprimé par la couverture de diagnostic qui est fixée soit à zéro soit à un.2

 Hypothèse 7 : Toute panne qu'on a réussi à détecter amènera le système à un état de

sécurité non volatil avec l’actionneur déconnecté. On suppose que le système est
déconnecté du courant manuellement jusqu'à ce qu'il soit réparé ou remplacé par un neuf.

 Hypothèse 8 : Si un PED connaît une panne dangereuse, il n'effectuera plus le test de sa

sortie de lecteur associé. La comparaison des signaux de sortie des capteurs est également
inhibée.

 Hypothèse 9 : La même panne dangereuse des deux capteurs au même moment n'est pas
détectable car ils délivrent des signaux de sortie (faux) identiques. Ceci ne peut pas être
révélé par comparaison.

 Hypothèse 10 : Le taux de panne de chaque voie d'entrée de l’actionneur est donné par :
 I  05
.  D
 Hypothèse 11 : Les effets de cause commune ne touchent pas les voies complètes mais les
deux capteurs, les deux PED et les deux entrées d'interrupteur de l’actionneur séparément.

3.3.2.4. Système à voies doubles en technologie mixte conformément à

la catégorie 3 de la norme EN 954-1

Dans de nombreuses applications, une technologie mixte est utilisée afin de mettre en œuvre une
fonction de sécurité. Une première voie est donnée par un contrôleur logique programmable (PLC)
standard avec alimentation électrique intégrée et sans test spécifique en ligne, alors que la seconde
voie est formée de moyens électromécaniques. Les tests en ligne sont effectués par le PLC pour
vérifier les éléments du chemin de signal électromécanique.

2
Pour les machines, quelques capteurs numériques seulement comme des interrupteurs sont normalement utilisés. La surveillance du lecteur se fait
également par signaux numériques. Ainsi, une couverture de diagnostic à 100 % est possible.

- 27 -
Pour exemple, le schéma simplifié de la Figure 8 décrit la mise en œuvre d'une fonction d'arrêt
d'urgence en employant un PLC et un relais.
L
Monitoring

ES

Control Signal
ES: Emergency Stop
PLC: Programmable PLC RC
Logic Controller
CC: Current Converter +
RC: Relay Circuit Control Signal
S: Rotation Sensor
CC
M: Motor Speed Control

Monitoring
S M

Figure 8 : Mise en œuvre d'une fonction d'arrêt d'urgence en utilisant une technologie mixte

On suppose une machine où le convertisseur (CC) est contrôlé par un PLC standard. Le capteur de
rotation (S) fait partie du contrôle de la vitesse ou de la position du convertisseur et peut être utilisé
par le PLC pour surveiller les mouvements du moteur.

La fonction de sécurité à implémenter est l'arrêt d'urgence du mouvement dangereux dès que le
dispositif d'arrêt d'urgence (ES) est actionné. L'actionneur contient deux contacts forcés
mécaniquement, chacun fournissant un signal de sortie distinct. L'un d'entre eux est traité par le PLC
alors que l'autre est amené à un circuit relais (RC) constitué de 2 relais (ou contacteurs
respectivement) à contacts forcés. La fonction d'arrêt d'urgence est exécutée par les deux PLC via le
convertisseur et le circuit de relais. Une panne de l'ouverture des contacts du dispositif actionneur de
l'arrêt d'urgence est exclue. On suppose que des pannes fortuites indépendantes surviennent au PLC,
au convertisseur, au circuit relais et au capteur tandis que l'actionneur d'arrêt d'urgence (ES) est
censé réussir à ouvrir ses contacts si le bouton est enfoncé.

Le logiciel PLC est conçu de manière à ce que l'ouverture du contact d'ES entraîne immédiatement
un signal d'arrêt pour le convertisseur. Quatre tests en ligne peuvent être modélisés par méthode de
Markov. Si l'un des tests n'est pas mis en œuvre en réalité, le taux de test pertinent peut être fixé à
zéro.

Pour les tests en ligne les hypothèses suivantes ont été avancées :
 Test de diagnostic du PLC : comme indiqué précédemment, un PLC standard est utilisé. On
suppose donc uniquement des tests en ligne simple tels que des tests de chien de garde et un
test de bit de parité de la mémoire qui sont également communs aujourd'hui pour
l'électronique standard. Ceci résultera en une couverture de diagnostic de 30%. On suppose
que le PLC après détection de panne désactive de manière permanente les sorties
connectées à CC et RC.

- 28 -
  Test de diagnostic du CC : à des intervalles de temps convenables, par exemple, une fois par
an ou au cours de la maintenance, le PLC déconnecte le mouvement du moteur en utilisant
le convertisseur (CC). En parallèle, le PLC surveille le signal de sortie du capteur de
rotation (S) afin de détecter la réaction de CC. Si le mouvement n'est pas arrêté par CC, le
PLC arrête le moteur de manière permanente via le circuit de relais (RC).

 Test de diagnostic du capteur de rotation : le test de diagnostic de CC ne peut être efficace

que si le capteur de rotation (S) est capable de détecter le mouvement du moteur. Pour
vérifier ceci, le PLC lit le signal du capteur après avoir mis en route le moteur. Si le
mouvement n'est pas détecté, le PLC arrête le moteur de façon permanente en utilisant le
circuit de relais (RC).

 Test de diagnostic du circuit de relais : après un arrêt normal du moteur en utilisant le CC et

après avoir exécuté le test de diagnostic du CC, le PLC désactive le signal de contrôle pour
RC. Simultanément, le PLC surveille le ou les contacts correspondants du circuit de relais
(RC). Si RC ne réagit pas correctement, le PLC arrête le moteur de manière permanente via
le convertisseur (CC). Grâce à la simplicité du test, la couverture de diagnostic peut
atteindre 100%.

3.3.2.5. Système à voies triples avec comparaison conformément à la

catégorie 4 de la norme EN 954-1

Parfois, le problème de disponibilité des fonctions de sécurité après l'occurrence d'un défaut est
résolu par la mise en œuvre d'une redondance triple. Un exemple typique de redondance homogène
est donné par le système à voies triples illustré à la Figure 9. La conformité à la catégorie 3 ou 4
dépend de la mesure à laquelle les défauts peuvent être détectés ou tolérés.

Figure 9 : Synoptique d'un système à voies triples avec comparaison

Le système se compose de trois capteurs (S1, S2 et S3) du même type et de trois dispositifs
électroniques programmables (PED1, PED2 et PED3) de type identique (avec alimentation
électrique intégrée) connectés à un seul actionneur (D). Chaque PED est connecté à une entrée
individuelle (IN1, IN2 et IN3) de l’actionneur.
- 29 -
 3.3.3. Architectures désignées des CES pour le secteur des machines

Afin de rendre comparables des architectures différentes, les paramètres d'entrée pour des unités
fonctionnelles identiques ou similaires ont été fixés aux mêmes valeurs. Dans d'autres cas, des valeurs
raisonnables ont été choisies. Sauf indication contraire, on a supposé les données d'entrée suivantes :
MTTF des capteurs, PED et PLC : 15 ans
MTTF des chemins de désactivation de l’actionneur : 30 ans
MTTF d'un chien de garde : 100 ans
MTTF d'un circuit de relais (deux contacteurs) : 50 ans
Temps de mission (durée de vie) : 10 ans
Temps de réparation (après détection de panne) : 1/(8 heures)
Temps de test des systèmes à voie unique : 1/(15 mn)
Temps de test des systèmes à voies doubles ou à voies triples : 1/(10 s)
Temps de demande de systèmes à voie unique : 1/(24 heures)
Temps de demande de systèmes à voies doubles ou à voies triples : 10/heure

1.0E-04
Cat. B Cat. 2 Cat. 3 Cat. 4
   
    
   
1.0E-05 
  

        
     
  

 
 
1.0E-06    

  


 
 

1.0E-07  
 

1.0E-08

MT "Si DC
DC DCMT DC DC DCMT DC
mpl
1.0E-09 SinDC (PE DC
TF( (PETF
e
Du (PE (PE (PETF (PE (PE
SinD) S/D SinD) = al D) D) D) D)
gle= 0 (PE red Du= Du = = Tri D)
)= mix= Du =
gle= D)
Sin (7. gle= 100 DC
Du und 100 ple
=
0.8 0.8y ed 0.3 al 0.9 al 0.9 al 0.9 0.9
gle= 5/5 al
= 0anc y
9
0.8 y"
)y

Figure 10 : Comparaison de différentes architectures utilisées pour les machines

- 30 -
Toutes les évaluations ont été effectuées en appliquant la procédure à demande élevée. Comme
illustré à la figure 10, les SIL 1 à 3 peuvent être atteints par des architectures de système appartenant
à différentes catégories. Pour la catégorie B, aucun lien à un SIL n'est possible. Avec la catégorie 2
et des tests appropriés effectués à un intervalle de temps environ 100 fois plus court que le temps
moyen entre les demandes, le SIL 1 est réalisable. La redondance sans test de diagnostic est
comparable aux systèmes de catégorie B et ne peut être utilisée, même pour le SIL 1. La redondance
en technologie mixte peut atteindre le SIL 2 si les tests en ligne des périphériques sont mis en œuvre.
Pour atteindre le SIL 3, un système redondant doit avoir une couverture de diagnostic de 99 % ou
un MTTF des sous-systèmes bien meilleur que celui que nous supposions pour nos systèmes de
référence. Dans des conditions appropriées, le SIL 3 est possible avec un système à triple
redondance.

Cette figure démontre que le simple doublement des chemins de traitement des signaux sans mise en
œuvre de tests en ligne (redondance simple) ne fournit pas de gain significatif si le temps de mission
est d'un ordre de grandeur similaire au MTTF d'une voie unique. D'autres investigations ont montré
que la simple redondance peut avoir un effet positif uniquement si le temps de mission est d'un ordre
de grandeur plus faible que le MTTF. Pour des systèmes simples (contacteurs ou vannes) qui
peuvent subir des tests d'épreuve une fois par an (couverture de diagnostic à 100 % pour tous les
sous-systèmes), le doublement simple du matériel peut être utile. Pour des sous-systèmes complexes
comme les ASIC ou PED, le doublement simple est utile uniquement si le MTTF est d'un ordre de
grandeur plus grand (possible par exemple pour certains ASIC) que le temps de mission (durée de
vie) du système de sécurité. Dans tous les autres cas, les diagnostics en ligne sont également
essentiels dans les systèmes redondants liés à la sécurité.

Ces résultats rassemblés pourraient être utiles à la standardisation. Un lien peut être fait entre les SIL
et les catégories pour les architectures appelées architectures désignées. Les architectures introduites
dans ce chapitre sont proposées pour être envisagées comme des architectures désignées pour le
secteur des machines. Un fabricant qui peut prouver que son architecture est équivalente à l'une des
architectures désignées doit déterminer le MTTFdangereux de ses sous-systèmes, la couverture de
diagnostic des tests en ligne et, en cas de systèmes redondants, estimer le facteur de cause commune.
Le tableau suivant est la compilation de résultats atteints en choisissant des données d'entrée
particulières. Une nouvelle modélisation Markov sera nécessaire uniquement si des architectures de
système et/ou des paramètres pour les sous-systèmes utilisés ne sont pas listés dans ce tableau.

Il existe plusieurs banques de données qui pourraient être employées pour déterminer le MTTF de
composants matériels, par exemple, FARADIP.THREE9, MIL HDBK 217 ou la Norme
Siemens SN 2950010 . Les résultats obtenus sont sensibles en fonction de la banque de données
utilisée ; pour atteindre des résultats comparables, il est donc préférable d'en utiliser seulement une.
La couverture de diagnostic peut être déterminée en utilisant le modèle de panne (voir annexe A de
IEC 61508-2). L’IEC 61508-6 peut être utile pour estimer le facteur de cause commune . La
standardisation pourrait spécifier une méthodologie pour estimer le CCF. Avec cette proposition, un
lien entre les deux normes IEC 61508 et EN 954-1 est possible, mais il ne s'agit pas d'un lien fixe
entre catégories et SIL.

- 31 -
 3.3.4. Conclusions pour les architectures CES désignées pour les machines

Les modèles Markov se sont avéré des outils très appropriés pour déterminer le niveau d'intégrité de
sécurité (SIL) des systèmes liés à la sécurité. Enrichies d'une caractéristique spécifique permettant le
calcul de l’intervalle de test en ligne et le taux de demande concernant la fonction de sécurité, la
probabilité d'une panne à la demande (PFD) et la probabilité d'une panne dangereuse par heure
(PDF). Ainsi la méthode couvre le mode de fonctionnement à faible demande ainsi que le mode de
fonctionnement à demande élevée ou à demande continue tels que définis en IEC 61508.

En appliquant la technique développée à un certain nombre d'architectures de système typiques

communément utilisées pour les machines, des investigations systématiques pourraient être
effectuées. Ainsi, beaucoup d'informations pourraient être obtenues sur l'influence des paramètres de
systèmes fondamentaux tels que le temps moyen avant panne (MTTF) des composants, la couverture
de diagnostic (DC) et l’intervalle de répétition des tests automatiques en ligne, l’intervalle de
demande sur la fonction de sécurité et le facteur de cause commune () dans les architectures à voies
multiples. Ces informations sont non seulement utiles à l'intervenant en charge de la validation mais
peuvent également aider le concepteur du système à choisir une structure de système approprié et à
établir des paramètres de conception basiques pour une application donnée.

Certains des résultats obtenus par modélisation Markov sont présentés dans la liste suivante :
 En supposant des taux de panne raisonnables des composants, il sera difficile d'atteindre le
SIL 1 avec un système à voie unique non testé. Théoriquement, la situation peut être
améliorée en introduisant des tests hors ligne réguliers, mais ceci n'est pas réaliste pour
l'électronique complexe tout comme les tests hors ligne standards ne le sont pas pour les
dispositifs électroniques de machines.

 Les tests en ligne sont essentiels non seulement pour des structures à voie unique, mais
aussi pour les architectures à voies multiples. En utilisant des composants avec un MTTF
suffisant (pas irréaliste), on peut atteindre le SIL 3 avec une couverture de diagnostic de
90 % ou plus. Le chien de garde simple d'un système typique à voie unique fournira
habituellement une couverture de diagnostic plus faible si bien que l'on ne peut atteindre que
le SIL 2.

 L'influence de l'intervalle de test en ligne dépend de l'architecture du système. En

considérant un système à voie unique pour une efficacité de test maximale, l'intervalle de
test doit être choisi plus petit par un facteur d'au moins 100 par rapport au temps moyen
entre les demandes sur la fonction de sécurité. Dans un système à voies doubles, l'intervalle
de test peut être beaucoup plus petit puisqu'il est lié au MTTF d'une des voies.

 Des pannes de cause commune peuvent réduire substantiellement le SIL de structures

redondantes particulièrement homogènes. L'avantage d'un système à voies doubles ou
triples peut être complètement perdu à cause d'un facteur de cause commune de quelques
pour cents seulement.

- 32 -
On propose que les architectures de système ayant été soumises aux investigations soient considérées
comme des architectures désignées pour le secteur des machines. Une liste d'exemples de résultats
d'évaluation présentée en un tableau fournit une vue d'ensemble utile sur la performance de
différentes solutions techniques. En impliquant des paramètres d'entrée supplémentaires comme le
MTTF de composants du système et la couverture de diagnostic, le tableau peut établir un lien entre
les catégories de la norme EN 954-1 et les SIL conformément à la norme IEC 61508. En outre, dans
certains cas, même la validation concernant le niveau d'intégrité de sécurité à atteindre par un
système lié à la sécurité particulier peut être simplifiée en appliquant ce tableau.

Potentiel moyen avant

Couverture de
panne dangereuse
CCF diagnostic (par voie)
MTTFd
SIL Architecture du système  (%) CAT
(années)
Entrée/Traitement/
(%) Entrée/Traitement/
Sortie Sortie
PE unique, E/S unique 15/15/30 - 0/0/0 B
- PE unique, I unique, ext. WD(u/t) 15/15/30 - 0/60/0 B
Double PE, double E/S, 1oo2 15/15/30 5 0/0/0 B
PE unique, I unique, ext. WD(u/t) 15/15/30 - 100/60/100 2
PE unique, I unique, ext. WD(u/t) 7.5/15/10 - 100/60/100 2
1 Double PE, IPC, double E/S, 1oo2 15/15/30 5 100/60/100 3
Double PE, IPC, double E/S, 1oo2 15/15/30 10 100/90/100 3
Double PE, IPC, double E/S, 1oo2 45/15/60 10 100/90/100 3
Triple PE, IPC, triple E/S, 1oo3 15/15/30 5 100/60/100 3
Triple PE, IPC, triple E/S, 1oo3 15/15/30 10 100/90/100 4
*
PE unique, I unique, ext. WD(t) 15/15/30 - 100/90 /100 2
Double PE, IPC, double E/S, 1oo2 15/15/30 1 100/90/100 3
2 Double PE, IPC, double E/S, 1oo2 30/30/60 5 100/90/100 3
Double PE, IPC, double E/S, 1oo2 7.5/15/10 1 100/99/100 4
Traitement double mixte, double O, 8 /(15/100)/(15/100) - 0/(30/100)/(100/100) 3
1oo2
Triple PE, IPC, triple E/S, 1oo3 15/15/30 1 100/60/100 3
Triple PE, IPC, triple E/S, 1oo3 100/100/200 10 100/90/100 4
*
PE unique, I unique, ext. WD(t) 30/30/60 - 100/99 /100 2
3 Double PE, IPC, double E/S, 1oo2 45/45/90 1 100/99/100 4
Triple PE, IPC, triple E/S, 1oo3 100/100/200 1 100/90/100 4
Conditions pour systèmes à voie unique : Conditions pour systèmes à voies doubles ou à voies triples :
Taux pour tous les tests : 1/(15 mn) Taux pour tous les tests: 1/(24 h)
Taux de demande : 1/(24 h) Taux de demande: 10/h
Taux de réparation : 1/(8 h) Taux de réparation: 1/(8 h)
Temps de mission (durée de vie) : 10 ans Temps de mission (durée de vie): 10 ans
MTTFd du chien de garde: 100 ans MTTFd du capteur de sortie d'un système mixte : 15 ans
MTTFd du chemin de désactivation pour chien de garde : égal au chemin de désactivation normal (capteur de sortie non testé)
WD(t) : Chien de garde et chemin de désactivation pertinent testé IPC : Communication inter-processeur
WD(u/t): Chien de garde et chemin de désactivation pertinent non testé ou testé
(* ne peut être réalisé par un chien de garde simple)

Tableau 4 : Architectures désignées possibles pour les machines

- 33 -
 3.3.5. Influence de l'architecture logicielle

3.3.5.1. Architecture logicielle et cause commune

La redondance partielle ou complète est un outil puissant pour atteindre des catégories plus élevées
ainsi que, si on l'utilise en connexion avec des tests en ligne, des SIL plus élevés ; la redondance
matérielle des CES est souvent liée à une redondance logicielle. En parallèle à l'architecture
matérielle, l'influence de l'architecture logicielle doit être analysée comme faisant partie de la
conception.

La question des défauts de mode commun, inhérente au concept de redondance, se pose alors ;
L'exemple de la compilation du code source est très révélateur. Deux produits logiciels de source
identique peuvent produire des codes exécutables erronés si ces codes sont générés par le même
compilateur erroné. La source commune de défauts est donc le compilateur qui introduit
systématiquement des erreurs dans les programmes. Ces erreurs, si aucune précaution n'est prise,
produisent des pannes de mode commun qui, dans certains cas, peuvent diminuer la sécurité de
l'application.

Les organismes de certification ont donc pris soin d'attirer l'attention des concepteurs et des
responsables de l'évaluation sur les problèmes liés à ces types de panne. D'où une note associée à la
catégorie 4 de la norme EN 954-1 qui y fait référence.

Si d'autres défauts surviennent en conséquence d'un premier défaut unique, le défaut et tous les
défauts conséquents doivent être considérés comme un seul défaut. Les pannes de mode commun
doivent être prises en compte, par exemple, en utilisant la diversité ou des procédures spéciales pour
identifier de tels défauts.

Les pannes de mode commun (résultant d'un défaut initial unique) sont équivalentes à des défauts
uniques et ne doivent donc pas affecter la sécurité de l'application. Il s'agit là d'une très forte
obligation puisque seul le recours à une structure diversifiée et validée satisfait les exigences de la
catégorie 4 pour de telles pannes.

Dans l'exemple précédent, le concepteur serait amené à utiliser deux compilateurs distincts et validés
s'il apparaît que des erreurs peuvent être introduites à la compilation.

La norme propose deux manières de prendre en compte ces pannes : la diversité ou l'utilisation de
procédures pour identifier les pannes de mode commun. Cette dernière n'est pas soumise à débat et
doit être suivie dès qu'une structure redondante est employée, sans quoi les avantages qui en
découlent pourraient être perdus. Au contraire, le recours à la diversité doit être étudié avec
attention afin de ne pas amener les concepteurs à ces moyens complexes puisque, dans certains cas, il
peut s'agir de deux développements et produits distincts. En outre, l'efficacité concernant les défauts
de mode commun peut quelquefois être discutable si on n'a pas pris de précaution.

- 34 -
En revenant à l'exemple des logiciels, il peut être tentant de concevoir deux logiciels différents pour
effectuer la même fonction. Les limites de cette technique, a priori attrayante, apparaissent cependant
rapidement. Il est en effet très difficile de donner une garantie finale d'absence de points communs
entre de tels programmes. Les mêmes spécifications sont souvent utilisées, et si elles sont erronées,
amèneront à deux programmes avec des pannes similaires pour les mêmes données d'entrée ; les deux
programmes peuvent avoir été conçus et codés par deux personnes ou deux équipes de culture
similaire, générant des erreurs logicielles avec des conséquences identiques, etc.

Cet exemple démontre rapidement que la diversité posée dans la norme EN 954 ne peut être imposée
sans précaution pour traiter des phénomènes de mode commun.

3.3.5.2. Diversité des logiciels

La diversité est une technique qui consiste à créer n versions d'une entité (matérielle ou logicielle)
tout en introduisant une ou plusieurs différences dans chaque entité ou dans son processus de
développement afin d'éviter les pannes de mode commun.

La diversité de fonctionnement est souvent citée pour surmonter les pannes de mode commun11 . Elle
consiste en l'acquisition de différents paramètres, l'utilisation de différentes technologies, différentes
logiques ou algorithmes ou différents moyens d'activer des sorties pour fournir plusieurs manières de
détection12 . Les avantages les plus importants de la diversité se situent au niveau de l'UC, de
l'interface mémoire, du programme et du format des données.

La diversité logicielle est un sous-ensemble de diversités de conception, qui est isolée à cause de son
importance. Il s'agit du développement et de l'exécution de versions (ou variantes) différentes mais
fonctionnellement équivalentes afin de détecter des erreurs éventuelles en comparant en temps réel
les résultats obtenus.

Après l'identification d'un état d'erreur, le rétablissement est entrepris par :

 rétroaction, par laquelle le système revient à l'état sauvegardé précédemment ;

 anticipation, par laquelle le système se ramifie en un nouvel état (généralement en mode

dégradé) dans lequel le système est capable de fonctionner ;

 compensation d'erreur, basée sur un algorithme qui utilise la redondance construite dans le
système pour fournir la réponse juste.

La détection d'erreur par vérification des résultats émanant des différentes variantes peut être
entreprise par :
 test (interne) d'acceptation pour vérifier les résultats de l'exécution d'un programme. Le
calcul du total de contrôle représente un exemple typique de test d'acceptation ;

 cohérence externe, par laquelle les résultats sont vérifiés au moyen d'une intervention
externe ;

- 35 -
  vérification automatique de résultats numériques. Il s'agit de la vérification de la précision
numérique des résultats algorithmiques.

Il arrive que des versions soient conçues par des équipes différentes pour atteindre le même objectif
de sécurité. En ce qui concerne la diversité de conception, on suppose que des concepteurs différents
ne feront pas les mêmes erreurs. Ni la bibliographie ni les expériences pratiques ne permettent de
connaître les conditions de diversité logicielle optimale13 . En fait, les logiciels doivent avoir des
paramètres logistiques dynamiques suffisamment diversifiés pour être considérés comme diversifiés.
Les facteurs accroissant la diversité logicielle peuvent être classés par ordre d'importance
décroissante :
 algorithmes, logique et architecture de programme différents,

 séquences et ordre d'exécution différents,

 langages de programmation différents,

 environnement de programmation différent.

Deux techniques de base sont utilisées pour la tolérance de défauts.

 Blocs de rétablissement

Exécution M1

Test d'acceptation A1 OK

Sortie
correcte
FIN
Exécution M2

Test d'acceptation A2 OK

Sortie
correcte
Exécution M3 FIN

Test d'acceptation A3 OK

Sortie
correcte
FIN

Figure 11 : Exemples de blocs de rétablissement

Plusieurs blocs fonctionnellement équivalents (M1, M2, M3, etc.) sont créés et exécutés en une
séquence jusqu'à ce qu'une erreur soit détectée par les modules entreprenant les tests d'acceptation
(A1, A2, A3, etc.) affectés à chaque bloc Mi.

L'application correcte de ce principe signifie que les tests d'acceptation (A1, A2, A3, etc.) doivent
être distincts mais en pratique un seul test commun à tous les blocs est souvent développé. Un cas
extrême consiste en l'adoption d'un test d'acceptation similaire aux blocs puis à la comparaison des
sorties à partir des blocs surveillés avec les résultats du test d'acceptation. Un des problèmes posés
par cette méthode dans un environnement monoprocesseur se trouve dans la nature séquentielle de
l'exécution des versions.
- 36 -
  Programmation de N versions
La programmation de N versions a été soumise à des expériences académiques destinées avant tout à
établir les limites d'efficacité concernant les pannes de mode commun. Cette technique consiste à
faire fonctionner de multiples versions (N) d'un logiciel en parallèle, le résultat final étant déterminé à
la majorité. Le nombre de versions dépend du nombre de défauts qui doivent être tolérés (3 versions
seront capables de tolérer un défaut). L'hypothèse sur laquelle son efficacité est établie est basée sur
le schéma suivant.

Hypothèse : indépendance des versions

Pas de corrélation (ou relation) entre les défauts logiciels

Des pannes apparaissent indépendamment

Possibilité de détection par un votant

Figure 12 : Principe de la programmation de N versions

Afin d'être complètement efficace, cette technique doit être utilisée en respectant les règles
suivantes :
 des exigences peuvent être spécifiées et analysées avec des méthodes formelles ;

 des documents de spécification doivent être débogués et stabilisés avant le développement

de composants logiciels ;

 un protocole doit exister afin de connaître et résoudre les problèmes. Ce protocole doit
contenir des mesures garantissant l'indépendance de développements et ne doit pas
introduire de défauts corrélés ;

 la vérification, la validation et le test doivent tous être formalisés et doivent prouver

l'absence de défauts corrélés ;

 les spécifications, la conception et le code doivent tous être testés.

- 37 -
 3.4. Conception et développement

Il n'existe pas de réponse simple pour savoir comment les logiciels et le matériel des composants liés
à la sécurité des systèmes de commande des machines doivent être conçus. Plusieurs aspects seront
importants pour atteindre l'objectif d'un système de commande suffisamment sûr pour son application
prévue. Des considérations de sécurité tout au long du cycle de vie seront importantes.

Ce chapitre décrit quelques aspects des logiciels, du matériel microprocesseur et des circuits intégrés
complexes qui doivent être abordés au cours de la phase de développement du cycle de vie :
 Comment les logiciels liés à la sécurité doivent-ils être développés pour éviter les défauts ?

 Quelles mesures peuvent être mises en œuvre pour détecter des défauts dans des circuits à
microprocesseurs avant qu'elles ne se manifestent en tant que pannes de la machine ?

 Comment les circuits intégrés complexes doivent-ils être conçus ?

Ces exigences sont destinées à guider le concepteur au cours du travail de conception.

3.4.1. Logiciel

Le logiciel du système de commande constitue les spécifications de la plupart des fonctions de la

machine. Les fonctions à la fois liées à la sécurité et non liées à la sécurité peuvent être commandées
par logiciel. Même si les spécifications utilisées comme entrées au développement du logiciel sont
exemptes de défauts, des erreurs dans le processus de conception peuvent introduire des défauts
logiciels. Des pannes logicielles et autres comportements inattendus peuvent amener à la création de
défauts dangereux dans le système de commande de la machine. Un ensemble d'exigences pour
toutes les activités techniques associées au développement logiciel doit être respecté afin d'éviter les
défauts dans le logiciel.

Pour obtenir un ensemble logiciel de qualité élevée satisfaisante, un certain nombre d'activités, une
certaine organisation et un certain nombre de principes doivent être établis. Les exigences pour la
conception et le développement doivent couvrir :
 Interface avec l'architecture système.

 Logiciels qui peuvent être paramétrés par l'utilisateur.

 Logiciels préexistants.

 Conception de logiciel.

 Langages de développement.

 Codage du logiciel.

- 38 -
 3.4.1.1. Interface avec l'architecture système

Interface avec l'architecture système Niveau

1 2
Des exigences de sécurité logicielle ainsi que la détermination / O
d'événements attendus doivent ressortir d'analyses de sécurité au niveau
du système, au niveau fonctionnel et au niveau matériel, etc.
La liste de contraintes imposées par l'architecture matérielle sur le O O
logiciel doit être définie et documentée.
Les conséquences de toute interaction matériel/logiciel sur la sécurité
de la machine ou du système surveillé doivent être identifiées et
évaluées par le concepteur, et prises en compte dans la conception du
logiciel.
Des contraintes telles que :
 les protocoles et les formats,
 les fréquences d'entrée/sortie,
 par front montant ou descendant ou par niveau,
 données d'entrée utilisant une logique inversée, etc.
Faire la liste de ces contraintes permet de les prendre en compte au début de
l'activité de développement et réduit le risque d'incompatibilités entre logiciel et
matériel lorsque celui-là est installé sur le matériel cible.
Les conséquences de toute erreur logicielle doivent être analysées en particulier au
niveau système.

Tableau 5 : Interface avec l'architecture système

3.4.1.2. Logiciels qui peuvent être paramétrés par l'utilisateur

Les exigences suivantes concernent le développement de logiciels qui sont conçus pour permettre
aux utilisateurs finaux de fixer leurs propres paramètres. L'utilisateur final peut être soit la personne
responsable de l'intégration du produit dans le système ou l'utilisateur.

De tels logiciels peuvent avoir différents degrés de complexité : un tableau de messages ou une
option système. La définition des paramètres logiciels est limitée et définie précisément dans les
documents de spécification. Ceci inclut toute modification qui peut provoquer un doute sur la
version exacte du logiciel, puisque les modifications de ce type doivent toujours être entreprises par
le concepteur logiciel.

Certains systèmes peuvent également inclure des fonctions optionnelles qui sont sélectionnées par
l'utilisation d'options de paramétrage dans le logiciel.

- 39 -
 Logiciels qui peuvent être paramétrés par l'utilisateur Niveau
1 2
Les paramètres doivent être spécifiés formellement (type, relations, ...) sous forme R R
de configurations de mémoire. En outre, le logiciel et les paramètres doivent être
modifiables sans s'affecter l'un l'autre.
Des spécifications logicielles doivent définir les mécanismes qui peuvent être R O
utilisés pour éviter l'éventualité que des paramètres fixés par l'utilisateur puissent
affecter la sécurité du système. En ce qui concerne les paramètres modifiables, ces
mécanismes doivent fournir une protection contre :
- des valeurs initiales invalides ou non définies,
- des valeurs hors des limites fonctionnelles,
- une altération de données.
La définition des paramètres logiciels par l'utilisateur doit être maintenue dans les
limites établies par les spécifications du système approuvées par l'analyste.
En particulier, des procédures de test doivent inclure différentes valeurs de
paramètres et différents types de comportement logiciel. Le concepteur doit
s'assurer que seuls ces paramètres modifiables sont accessibles à l'utilisateur.

Tableau 6 : Logiciels qui peuvent être paramétrés par l'utilisateur

3.4.1.3. Logiciels préexistants

Niveau
Logiciels préexistants
1 2
Le concepteur doit indiquer l'utilisation de logiciels préexistants à l'analyste, et la O O
responsabilité de démontrer que le logiciel préexistant a le même niveau que les
exigences présentes incombe au concepteur.
Une telle démonstration doit être effectuée :
- soit en utilisant les mêmes activités de vérification sur les logiciels
préexistants que sur le reste du logiciel,
- soit par une expérience pratique si le logiciel préexistant a fonctionné
sur un système similaire dans un environnement d'exécution
comparable (il est nécessaire d'évaluer les conséquences d'un
changement de compilateur ou d'un format d'architecture logicielle
différent).
Le but d'indiquer l'utilisation de logiciels préexistants est d'ouvrir des
consultations avec l'analyste aussi tôt que possible concernant toute difficulté
éventuelle que ce type de logiciel pourrait causer.
L'intégration de modules source préexistants peut être la cause de certaines
anomalies ou de comportement non sûr s'ils n'ont pas été développés avec la
même rigueur que le reste du logiciel.
Des logiciels préexistants doivent être identifiés en utilisant les mêmes principes O O
de gestion de configuration que ceux appliqués au reste du logiciel.
Un contrôle de configuration parfait doit être exercé sur tous les composants du
logiciel, quelle que soit leur origine.

Tableau 7 : Logiciels préexistants

- 40 -
Le terme de logiciels "préexistants" fait référence aux modules sources qui n'ont pas été développés
spécifiquement pour le système en question et sont intégrés au reste du logiciel. Ceux-ci incluent des
logiciels développés par le concepteur pour des projets antérieurs ou des logiciels disponibles dans le
commerce (par exemple, modules pour les calculs scientifiques, séquenceurs, etc.). De tels
composants logiciels sont appelés logiciels COTS ("Commercial Off-The-Shelf", logiciel du
commerce).

Lorsqu'il utilise ce type de logiciel, et tout particulièrement dans le cas de logiciels commerciaux, le
concepteur n'a pas toujours accès à tous les éléments nécessaires pour satisfaire aux exigences
antérieures. Une coordination spécifique avec l'analyste est donc nécessaire le plus tôt possible.

3.4.1.4. Conception de logiciel

Conception de logiciel Niveau

1 2
La description de la conception du logiciel doit inclure au minimum : O O
- une description de l'architecture logicielle qui définit la structure décidée pour
satisfaire les spécifications,
- une description des entrées et sorties (par exemple sous forme d'un
dictionnaire de données interne et externe) pour tous les modules constituant
l'architecture logicielle,
- des séquenceurs et des interruptions,
- des données globales,
- une description de chaque module logiciel (entrées/sorties, algorithme,
particularités de conception, etc.),
- les bibliothèques utilisées,
- les logiciels préexistants utilisés.
Le logiciel doit être modulaire afin de faciliter sa maintenance : O O
 chaque module ou groupe de modules doit correspondre, si possible, à une
fonction de spécifications
 les interfaces entre modules doivent être aussi simples que possible
Les caractéristiques générales d'une architecture logicielle correcte peuvent être
résumées de la manière suivante : un module doit posséder un niveau élevé de
cohésion fonctionnelle et une interface simple avec son environnement.
Le logiciel doit être conçu pour limiter ces parties associées à la sécurité : O O
- architecture fonctionnelle/de données, limitation stricte des variables globales,
mise en œuvre d'opérateurs sur variables état (visibilité),
- contrôle de la disposition des tableaux en mémoire (risque de débordement de
tableau).

Tableau 8 : Conception de logiciel

- 41 -
 3.4.1.5. Langages de développement

Le but de ces exigences est de garantir que le concepteur utilise un langage de programmation et des
outils de développement qui sont bien adaptés au logiciel développé, et que ces outils n'amènent pas
l'introduction d'erreur dans le code exécutable sur la machine cible. Généralement, les langages les
plus largement utilisés incluent :
 un langage assembleur, spécifique au microprocesseur ou au microcontrôleur employé,

 un langage de programmation avancé tel que C.

Langages de développement Niveau

1 2
Le langage de programmation sélectionné doit correspondre aux caractéristiques de R O
l'application, et doit être complètement et clairement défini ou du moins, limité par
des caractéristiques clairement définies.
Les caractéristiques de l'application font référence aux facteurs tels que la taille, le
type (logiciel industriel ou scientifique, gestion, etc.), et toutes contraintes de
performance. Par exemple, COBOL ne satisfait pas les exigences de développement
d'une application de commande/surveillance sur une machine industrielle.
Toute déficience dans le langage peut être évitée en utilisant les règles de codage
appropriées.

Tableau 9 : Langages de développement

3.4.1.6. Codage logiciel

Codage Niveau
1 2
Le code source doit : O O
a) être lisible, compréhensible et soumis à des tests,
b) satisfaire des spécifications de conception du module logiciel,
c) obéir aux instructions manuelles de codage.
Les règles de codage applicables à un logiciel donné doivent être indiquées en R O
détails dans un manuel de codage et utilisées pour développer le logiciel. Le
manuel de codage doit :
 indiquer quels principes de programmation doivent être appliqués et
interdire tous aspects d'incertitude de langage
 décrire les règles pour la présentation et la documentation des codes sources
 inclure les conventions utilisées pour nommer les composants, les sous-
routines, les variables et les constantes.
Un ensemble de règles est fourni en Annexe A au présent document. Par exemple,
la présentation en alinéas de différents groupes d'instructions, l'utilisation de
lignes vierges, le contenu du titre des fichiers sources (nom d'auteur, données
d'entrée et sortie, données modifiées, etc.).

Tableau 10 : Codage

- 42 -
 3.4.2. Détection de défauts matériels

Les systèmes électroniques programmables (PES) ont la capacité de détecter des défauts intrinsèques
avant qu'un défaut ne se manifeste en tant que panne du système. Les techniques et les mesures
utilisées se concentrent sur différentes parties du matériel électronique et peuvent détecter une
quantité variable d'efforts du système. Il est considéré comme conforme à l'état de l'art de mettre en
œuvre des techniques pour la détection de défauts dans des PES utilisés dans des applications
sensibles pour la sécurité.

3.4.2.1. Couverture de diagnostic

Il est aisé d'imaginer des défauts possibles qui peuvent causer un comportement inattendu de la
machine commandée. Un bit dans une cellule de mémoire peut être bloqué sur "0" ou "1". Les
circuits de sortie peuvent être bloqués sur "ON". Un défaut logiciel peut entraîner une tâche dans une
"boucle fermée". Des interventions dans l'alimentation électrique ou des variations dans le niveau de
tension peuvent influencer l'opération du logiciel. Des données transférées sur des lignes de
communication en série peuvent être altérées par interférence. Un défaut interne à l'UC peut
provoquer une exécution incorrecte. Il existe des techniques et des mesures pour détecter de tels
défauts avant de perdre le contrôle de la machine.

La quantification de la couverture de diagnostic pour différentes méthodes de détection des défauts

en mémoire et en unités E/S est basée sur des valeurs extraites de la norme IEC 61508. Ces valeurs
sont le résultat d'études théoriques basées sur une approche probabiliste simplifiée. Le manque de
données concernant les divers types de puces à mémoire et l'hypothèse que les défauts éventuels sont
distribués également introduisent un certain nombre d'incertitudes.

Des tests simples ne détecteront pas tous les défauts matériels. Des tests élaborés détecteront de
nombreux défauts matériels, moyennant de gros efforts en traitement. La couverture de diagnostic,
DC, est définie comme la réduction par fraction de la probabilité de pannes matérielles dangereuses
résultant du fonctionnement des tests de diagnostic automatiques [IEC 61508-4, § 3.8.6] voir
formule 1. Si le test détecte tous les défauts, la couverture est de 100 %. Si aucun défauts n'est
détectable, la couverture est de 0 %.

couverture de diagnostic DC = la probabilité de pannes dangereuse s détectées [1]

la probabilité de pannes dangereuse s totales

Une autre définition de la couverture de diagnostic, DCN, (voir formule 2) est liée à la fraction du
nombre total de pannes différentes qui est détecté au cours d'un test particulier. Il peut exister de
grandes différences entre les deux manières de définir la couverture de diagnostic. L'approche basée
sur la probabilité distingue entre les défauts qui se produisent avec des probabilités différentes, alors
que l'approche basée sur les nombres ne le fait pas.

Une technique de test qui détecte des défauts survenant avec une forte probabilité aura très
probablement une DC élevé, mais peut avoir une DCN faible s'il y a un grand nombre de défauts à
faible probabilité qui ne sont pas détectés.

- 43 -
 couverture de diagnostic DCN = le nombre de pannes dangereuse s détectées [2]
le nombre total de pannes dangereuse s

Il peut être difficile de trouver des valeurs numériques pour les probabilités de défauts différents.
L'hypothèse est parfois avancée que tous les défauts ont la même probabilité. Il s'agit toujours d'une
approximation de la réalité.

Une traduction de la définition qualitative "faible/moyen/élevé" en une mesure quantitative exprimée

en pourcentages sera nécessaire. Les techniques et les mesures offrant moins de 60 % de probabilité
de détecter des défauts doivent être évités pour des composants de systèmes de commande liés à la
sécurité.
Moyenne

Faible Élevée

0 60 90 99 100

Figure 13 : Couverture de diagnostic définie comme faible, moyenne et élevée

Des incertitudes similaires sont introduites pour d'autres parties des PES. La probabilité de défauts
différents dans l'unité de traitement dépendra du type de processeur, du fabricant, du processus de
production, de la conception, etc. Il est quasiment impossible d'affirmer une probabilité qui sera
valide dans tous les cas. En supposant des probabilités égales de tous les défauts possibles, les
expressions précédentes [1] et [2] de la couverture de diagnostic deviennent équivalentes.

Des défauts dans la séquence d'instructions auront une probabilité différente en fonction du langage
de programmation, de l'expérience du programmateur, de l'effort de test, etc. Il ne sera pas facile
d'indiquer une couverture de diagnostic basée sur la probabilité pour le moniteur de séquence
d'instructions.

L'estimation la plus valable de couverture de diagnostic pour une méthode de détection des défauts
doit, à cette étape, être limitée à l'un des trois niveaux auxquels il est fait référence plus haut dans
cette section : faible, moyen ou élevé. Le niveau choisi peut être différent si la probabilité, ou le
nombre d'erreurs, est utilisée pour la définition de la couverture de diagnostic. Cependant, le niveau
ne sera pas le même si tous les défauts sont également probables.

3.4.2.2. Intervalle de test de diagnostic

Les méthodes pour la détection de défauts peuvent être utilisées à la mise sous tension pour établir si
le système électronique peut commencer à fonctionner. Les défauts doivent être détectés au
démarrage, et le début de l'exploitation ne doit pas être permis lorsque des défauts sont détectés. Un
test de mise sous tension de ce type ne détectera pas les défauts qui surviennent en cours
d'exploitation. Ainsi, il ne conviendra pas à des systèmes à intégrité de sécurité élevée ayant des
exigences strictes quant au comportement face aux défauts.

- 44 -
La détection de défauts peut également être effectuée en cours d'exploitation pour trouver les
défauts qui surviennent en cours d'exploitation. Il sera d'une importance capitale de décider pour
quelles applications ce système peut être utilisé. L'intervalle de test sera le temps maximum au cours
duquel un défaut non détecté pourra exister.

3.4.2.3. Exigences relatives aux méthodes de détection de défauts

Les exigences listées dans ce rapport se combinent pour former des principes de sécurité adéquats
pour une certaine catégorie (B, 1, 2, 3 ou 4). Différents principes de sécurité sont listés pour les
architectures différentes en catégories 3 et 4. Un système à voies doubles employant des principes de
sécurité de couverture de diagnostic moyenne peut fournir la même probabilité de panne de la
fonction de sécurité qu'un système à voie unique utilisant des principes de sécurité à couverture de
diagnostic élevée.

Certains des principes de vérification peuvent être appliqués soit à la mise sous tension soit de
manière continue en cours de fonctionnement. Ceci dépendra surtout de l'application et aucune
exigence spécifique n'est indiquée concernant le moment (ou la fréquence) où la vérification doit
avoir lieu.

Unité de traitement Catégorie

B 2 3 3 4 4
Unique Double Double Triple
Des pannes de blocage des registres et de la RAM x x x x
interne doivent être vérifiées sur l'UC.
Le décodage et l'exécution des instructions doivent x x
être vérifiés.
Tous les registres doivent être vérifiés. x x
Les défauts de l'unité de traitement doivent être x x x x
indiqués par le PES.
Couverture de diagnostic minimum - - Élevée Moyenne Élevée Moyenne

Tableau 11 : Principes de sécurité pour la surveillance de l'unité de traitement

Plages mémoires invariables Catégorie

B 2 3 3 4 4
Unique Double Double Triple
Les PES doivent être capables de détecter des x x x x x
défauts dans la mémoire invariable.
La plage d'adresses complète doit être vérifiée. x x
Les pannes de mémoire doivent être indiquées par x x x x x
les PES.
Couverture de diagnostic minimum - Faible Élevée Moyenne Élevée Moyenne

Tableau 12 : Principes de sécurité pour la surveillance de la mémoire invariable

- 45 -
 Plages mémoires variables Catégorie
B 2 3 3 4 4
Unique Double Double Triple
Les PES doivent être capables de détecter des x x x x x
défauts dans la mémoire variable.
La plage d'adresses complète doit être couverte. x x x
Les pannes de mémoire doivent être indiquées par x x x x x
les PES.
Couverture de diagnostic minimum - Faible Élevée Moyenne Élevée Moyenne

Tableau 13 : Principes de sécurité pour la surveillance de la mémoire variable

Interface et unités E/S Catégorie

B 2 3 3 4 4
Unique Double Double Triple
Les PES doivent automatiquement vérifier les x x x x
unités d'entrée et sortie.
Les défauts détectés dans la communication x x x x
interne doivent être indiqués.
Couverture de diagnostic minimum - - Élevée Moyenne Élevée Moyenne

Tableau 14 : Principes de sécurité pour la surveillance de l'interface et des unités E/S

Bus de données Catégorie

B 2 3 3 4 4
Unique Double Double Triple
Les PES doivent automatiquement vérifier la x x x x
communication interne.
Les défauts détectés dans la communication x x x x
interne doivent être indiqués.
Couverture de diagnostic minimum - - Élevée Moyenne Élevée Moyenne

Tableau 15 : Principes de sécurité pour la surveillance des chemins d'accès de données

- 46 -
 Alimentation électrique Catégorie
B 2 3 3 4 4
Unique Double Double Triple
Les PES doivent être capables de détecter des x x x x x x
baisses de tension du secteur et l'exécution du
processeur doit être arrêtée de manière
contrôlée.
Le circuit de surveillance de tension x x
d'alimentation doit être dynamique, c'est-à-dire
que la tension du secteur correcte est indiquée
par un signal dynamique.
Le circuit de surveillance de la tension du x x
secteur doit être à sécurité intégré, c'est-à-dire
qu'un défaut dans le circuit électrique doit
provoquer une alerte de panne électrique.
Les pannes d'alimentation électrique doivent être x x x x
indiquées par les PES.
Couverture de diagnostic minimum Faible Faible Élevée Moyenne Élevée Moyenne

Tableau 16 : Principes de sécurité pour la surveillance de l'alimentation électrique

Séquence d'instructions Catégorie

B 2 3 3 4 4
Unique Double Double Triple
Les PES doivent posséder un dispositif de x x x x x x
surveillance mis en œuvre dans le matériel pour
surveiller la séquence d'instructions.
Le matériel (en particulier, la base de temps) x x
utilisé pour le chien de garde doit être
indépendant du processeur qu'il est sensé
superviser.
Il doit y avoir des moyens logiciels de surveiller x x x x
la séquence d'instructions.
Le chien de garde doit être testé x x
automatiquement par le logiciel à la mise sous
tension ou à intervalles périodiques.
Le chien de garde doit être à sécurité x x
intrinsèque, c'est-à-dire qu'un défaut dans le
circuit électrique du chien de garde provoquera
une alerte de chien de garde.
Une alerte de chien de garde devra être indiquée x x x x
par les PES
Couverture de diagnostic minimum Faible Faible Élevée Moyenne Élevée Moyenne

Tableau 17 : Principes de sécurité pour la surveillance de l'exécution du programme

- 47 -
 3.4.3. Circuits intégrés complexes

Les circuits intégrés spécifiques sont utilisés dans des systèmes électroniques dédiés à la gestion de
fonction de sécurité. Ces circuits intégrés complexes peuvent intégrer plusieurs millions de
transistors et créent donc des problèmes pour l'évaluation de la sécurité de fonctionnement des
systèmes qui les incluent.

Pour les composants discrets (relais, transistors, résistances, etc.), l'analyste peut évaluer le niveau de
sécurité en simulant quasiment toutes les situations de défaut des dispositifs, en utilisant une liste
presque exhaustive de toutes les pannes possibles. Pour des circuits électroniques complexes comme
les ASIC, cette approche exhaustive est impossible. Pour évaluer les caractéristiques de sécurité
opérationnelle, il est nécessaire de connaître les modes de panne des composants utilisés, et ceci n'est
pas possible pour ces circuits. Les méthodes traditionnelles de tests de performance en présence de
défauts sont inappropriées. Il est donc nécessaire d'aborder l'évaluation non seulement en mettant à
jour les tests ultérieurs sur les produits finis mais également en étendant le champ d'investigation
depuis l'origine des défauts considérés : erreurs de spécification, conception ou production, défauts
internes ou effets externes.

Le schéma de test de validation a pour conséquence la somme des étapes de vérification

indépendante au cours du processus de mise en œuvre. La séquence complète, ininterrompue des
étapes de vérification fournit la preuve objective que le résultat final remplit les exigences initiales
pour l'utilisation prévue et la catégorie de sécurité requise.

3.4.3.1. Technologie

Le terme de "composant complexe" peut s'appliquer à une grande variété de dispositifs. L'éventail
recouvre différentes technologies de processus, différentes méthodologies de conception et de mise
en œuvre, ainsi que différents niveaux de complexité. Un certain nombre de produits typiques et de
méthodologies de conception pour les circuits intégrés sont décrits ci-dessous. Le nombre de parties
impliquées dans la conception et le processus de validation varie ainsi que la responsabilité pour les
ensembles de travail au cours du déroulement de la conception.

Circuit intégré complexe

Personalisation
Microprocesseur

Circuits Tableaux de Tableaux de mémoire

programmables mémoire prédiffusés précaractérisés

FPGA Tableaux de portes

logiques compilateur
PAL silicone
PLA Ensemble de tableaux
CPLD de mémoire
HCPLD cellules
EPLD standards
Tableaux imbriquéss
EEPLD

Figure 14 : Les familles de CIC

- 48 -
Les CIC peuvent être divisés en trois familles principales : circuits programmables, tableaux de
mémoire prédiffusés et tableaux de mémoire précaractérisés.

Les circuits programmables sont des composants constitués de matrices de portes logiques, de pistes
de connexion et de cellules complexes telles que les registres, les dispositifs bistables, etc.
L'utilisateur effectue les interconnexions entre les cellules en fonction de ses objectifs d'application en
utilisant un outil de programmation. Les arrangements de cellules différents, la complexité disponible
et les technologies d'interconnexion utilisées déterminent les différentes sous-familles des dispositifs
logiques programmables (PLD) :
 Circuits à logique à tableaux programmables (PAL, Programmable Array Logic) constitués
uniquement d'un matrice programmable ET matrice et d'un autre fixe matrice OU.

 Circuit de tableaux logiques programmables (PLA, Programmable Logic Array) constitué

de matrices programmables ET et OU.

Ces circuits peuvent très facilement intégrer des cellules plus complexes, mais sont maintenant
obsolètes.
 Circuits à dispositif logique programmable complexe (CPLD, Complex Programmable
Logic Device) et à PLD à haute capacité (HCPLD, High Capacity PLD) sont un
développement des PLD contenant un grand nombre de cellules de base très complexes.

Dans tous ces circuits PLD, les cellules sont interconnectées en tableaux de mémoire et l'utilisateur
élimine les points de connexion non désirés en brisant la piste. Cette programmation n'est pas
réversible.
 Le dispositif logique programmable effaçable (EPLD, Erasable Programmable Logic
Device) est un PLD qui peut être programmé électriquement et effacé avec une lumière UV
utilisant la technique de mémoire EPROM.

 Le dispositif logique programmable effaçable électriquement (EEPLD, Electrically Erasable

Programmable Logic Device) est un PLD qui peut être programmé et effacé électriquement
en utilisant la technique de mémoire EEPROM.

Ces deux sous-familles comprennent des PLD effaçables et reprogrammables, techniques

extrêmement utiles pour les prototypes.
 Des circuits à tableau de portes logiques programmable sur site (FPGA, Field
Programmable Gates Array) emploient deux techniques d'interconnexion : la technique de
non-fusion dans laquelle l'utilisateur établit des points de connexion en décomposant un
isolant (configuration irréversible) et SRAM pour laquelle la configuration des connexions
enregistrée dans une mémoire ROM, est automatiquement chargée dans une mémoire RAM
à l'état solide chaque fois que le circuit est activé. Les interconnexions se font par des
transistors MOS allumés par des commandes à partir de la RAM (reconfigurable). Elles
comprennent des cellules complexes telles que les registres, les multiplexeurs, etc. et
représentent une concurrence sérieuse pour la famille prédiffusée.

- 49 -
Un circuit prédiffusé est un circuit incomplet. Les couches profondes du composant sont fabriquées à
l'avance par le constructeur. L'utilisateur conçoit les interconnexions de son circuit dans des pistes
fournies à cet effet en utilisant une méthode de CAO (conception assistée par ordinateur). Le circuit
sera alors terminé par le constructeur qui crée ces connexions sur une couche finale d'aluminium.
Cette famille se subdivise en trois groupes :
 Les tableaux de portes logiques sont organisés en rangs de pistes d'interconnexion et de
cellules de base qui sont fixées en termes d'emplacement et de taille.

 Ensembles de tableaux de portes logiques ou "mers de silicium" sont des circuits à haute
densité de transistors mais sans piste. Les interconnexions se font au-dessus de ces
transistors par une couche de métal spéciale, offrant à l'utilisateur une flexibilité
considérable pour définir les fonctions et les connexions.

 Les tableaux de mémoire imbriqués offrent des solutions composites qui emploient les
meilleures caractéristiques des diverses familles : la complexité et l'optimisation de circuits
précaractérisés, le temps de développement court des circuits prédiffusés, la haute densité
des ensembles de portes logiques, etc.

Avec les tableaux de mémoires précaractérisés, l'utilisateur a une bibliothèque logicielle de cellules
standard qui sont définies et caractérisées par le constructeur. Il choisit les cellules nécessaires pour
produire les fonctions requises et pour concevoir tous les masques d'interconnexion. Ce circuit est
plus optimisé qu'un circuit prédiffusé.

La forme la plus évoluée de circuit précaractérisé est la compilation silicium. Ce circuit est optimisé
en ce qui concerne les cellules paramétrables, RAM, ROM, multiplexeurs, connexion de fonctions
logiques, etc., en utilisant une description du composant dans un langage de haut niveau.

PLD FPGA Tableau de ASIC basée ASIC basée ASIC CI standard

CPLD portes sur cellule sur noyau personnalisée

logiques
Spécifications fonctionnelles C C C C C C V
Mise en œuvre C C D D D, M D V
Emplacement et acheminement, V C V D D, M D V
configuration
Production de galettes V V V V V V V
Conditionnement V V V V V V V
test V, C V, C V, D V, D V, D V V
responsabilités V vendeur (fabricant) de CI / ASIC
C client final, développement du système et de l'application
D centre de conception ASIC
M vendeur de macro noyaux (blocs fonctionnels préconçus)

Tableau 18 : Vue d'ensemble des circuits intégrés

Les circuits intégrés standard sont fabriqués en grandes quantités et utilisés pour différentes
applications. La fonctionnalité, la validation, la production et les tests de production sont uniquement
de la responsabilité du vendeur de semi-conducteurs.

- 50 -
Des manipulations manuelles et des optimisations au niveau de la configuration sont fréquemment
utilisées pour réduire la zone requise. Comme ils ne sont pas conçus pour des systèmes liés à la
sécurité, l'évitement de défauts au cours du processus de conception est adéquat uniquement pour
des produits standard. Des modifications fréquentes dans le processus de production, la technologie
de traitement et la configuration permettent vraisemblablement une optimisation des coûts et du
rendement. Le nombre de fabricants de composés utilisant un certain procédé ou une révision de
masque n'est pas public. La conception et la production d'ASIC personnalisés sont similaires à celles
des circuits intégrés standard, avec une fonctionnalité définie par le client final.

Un ASIC basé sur des noyaux est basé sur des macro noyaux pré-configurés ou générés, connectés
par une logique supplémentaire. Des exemples de macros prédisposées sont les noyaux
microprocesseurs standard, les composants périphériques, les interfaces de communication, les blocs
analogues, les cellules à fonction E/S spécifique. Des exemples de macros générées incluent la RAM
intégrée, ROM, EEPROM ou FLASH. On suppose que les blocs générés sont corrects par
construction, basés sur des règles de conception. Les macros prédisposées ou générées sont
spécifiques à un procédé mais peuvent être portées à différentes technologies. Dans la plupart des
cas, les macro-noyaux ne sont pas identiques aux composants d'origine discrets que l'on trouve dans
le commerce (procédé différent, fourni par un tiers).

Les ASIC basés sur les cellules sont basés sur des primitives logiques (comme ET, OU, Bascule,
Verrou logique) issues d'une bibliothèque de cellules. La liste de réseau "netlist" au niveau des portes
logiques contenant les primitives logiques et les interconnexions est généralement créée à partir d'un
langage de description matérielle de haut niveau (VHDL, Verilog) utilisant des outils de synthèse.
Les caractéristiques de fonctionnement et de minutage des primitives logiques sont caractérisées
dans la bibliothèque de cellules ; ces paramètres sont utilisés pour faire fonctionner l'outil de synthèse
et sont également utilisés pour des simulations. En outre, des outils de configuration sont utilisés
pour placer les cellules et acheminer les interconnexions.

Les Modules Multi-Puces ("Multi Chip Module", MCM) sont des puces multiples (matrices) et des
composants passifs montés sur un substrat commun et assemblés en un ensemble unique. Dans la
plupart des cas, le conditionnement et la forme sont similaires à ceux d'un circuit intégré standard.
Les puces (matrices) utilisées pour la production de MCM sont généralement prévalidées mais pas
caractérisées de manière finale. Ainsi, des tests sous des conditions d'environnement doivent être
conduits au niveau des MCM. Les méthodologies de conception pour les composants individuels des
MCM sont quasiment identiques à la méthodologie de conception des systèmes construits sur des
cartes à circuits imprimés conventionnelles. Les MCM ne seront donc pas abordés plus en détail dans
ce rapport.

Une puce sur plaque ("Chip On Board", COB) a une matrice qui est liée directement sur la plaque de
circuit imprimé et scellé hermétiquement ensuite, au lieu d'utiliser des puces (matrices) dans un
conditionnement conventionnel. COB est avant tout une technologie de conditionnement différente
et n'est donc pas abordée plus en détail dans ce rapport.

- 51 -
 3.4.3.2. Défauts dans des ASIC

Pour les circuits intégrés liés à la sécurité, les différents types de produits nécessitent différents
concepts de validation. Par exemple, la configuration et l'emplacement des cellules d'un tableau de
portes logiques ou d'un FPGA sont fixes ; les composants basés sur ces structures prédéfinies sont
fabriqués en grande quantité, la structure elle-même peut donc être considérée comme éprouvée
après quelque temps. Pour les autres types de produits mentionnés dans les paragraphes précédents,
la structure est définie au cours de processus de configuration. Ainsi, en particulier pour les procédés
profonds sous-micrométriques, des interférences entre interconnexions ou cellules voisines sont
possibles, avec une influence réelle sur la fonctionnalité des puces. Il est évident que cette situation
doit être considérée au cours de tests de validation et de l'injection de défauts.

En règle générale, une application développée en utilisant un ASIC sera plus fiable qu'une application
avec des circuits standard. Tout d'abord, la fiabilité est inversement proportionnelle au nombre de
connexions entre unités et, d'autre part, une puissance faible signifie également une fiabilité meilleure.

Cependant, pour ces composants complexes :

 La connaissance des défauts et de toute corrélation cause/défaut n'est que partielle.

 La réduction des dimensions physiques des composants de base crée de nouveaux défauts.

 La complexité croissante augmente la probabilité que des fautes de conception apparaissent.

 L'étendue plus limitée des ASIC par rapport aux circuits standard signifie que
l'interprétation du retour d'informations de l'expérience est plus difficile.

3.4.3.3. Modèle de phases

Il est utile d'identifier les étapes principales qui conduisent à un composant prêt à la production. Ce
modèle de phases vise à être plus général que les deux organigrammes conceptuels basés sur le
modèle de phase issu de IEC 61508 ; les phases suivantes sont identifiées :
 Spécifications : description textuelle ou formelle des fonctionnalités du dispositif.

 Description de conception : description formelle (par exemple, équations booléennes,

schémas, (V)HDL) qui peut être automatiquement traduite en un schéma fusemap / flot
binaire (PLD, FPGA) ou liste de réseau "netlist" de niveau de porte logique (tableau de
portes logiques, ASIC).

 Mise en œuvre : transformation de la description de conception en une liste de réseau

"netlist" / schéma fusemap / flot binaire qui peut être utilisée pour produire ou programmer
le composant. Cette phase est subdivisée en deux phases : la "Mise en œuvre I" transforme
la description de conception dans les primitives du dispositif cible (blocs logiques, portes
logiques). La "Mise en œuvre II" produit les informations finales nécessaires à la production
du composant ou la programmation (fichier de flot binaire ou fusemap, base de données de
configuration).

- 52 -
  Production : production (programmation) du composant, basée sur les sorties de la phase de
mise en œuvre.

 Post Production : le composant est disponible pour intégration à un système standard et

tests de validation.

3.4.3.4. Organigrammes conceptuels

La description du travail de développement peut également faite sous forme d'un organigramme
d'activités. Des organigrammes conceptuels simplifiés pour les circuits intégrés spécifiques aux
applications (ASIC) et les dispositifs logiques programmables/tableaux de portes logiques
programmables sur site (PLD/FPGA) montrent les différentes méthodologies, les étapes de
conception et les outils typiquement utilisés pour le développement de composants complexes.

Niveau élevé /
Entrée graphique

Organigramme,
diagramme de situation et
synoptique

Entrée schématique Entrée (V)HDL Générateur de code

Schéma (V)HDL Noyaux logiciels

Générateur de Synthèse
lliste “netlist”

Netlist Description

Insertion de tests Générateur de

Noyaux

Netlist Noyaux matériels Noyau généré

Conception
Emplacement et
acheminement

Configuration, par
exemple GDS-II

Génération de masque

Production

Ensemble de
masques

Production de galettes

Conditionnement

Test de production

Composant testé

Figure 15 : Organigramme conceptuel simplifié des ASIC

- 53 -
Il est possible d'identifier plusieurs dangers potentiels pour la sécurité dans toutes les activités au
cours de la conception. La conception de composants complexes pour des systèmes de commande de
machines liés à la sécurité nécessitera une attention particulière pour des dangers tels que :
 Qualité du noyau logiciel ou des bibliothèques de macros dépendantes du vendeur.
L'exactitude n'est pas garantie.

 Défauts au cours du processus de synthèse (causés par l'outil de synthèse).

 Seuls les défauts couverts par le jeu de modèles de tests de la production sont révélés.
Ainsi, une couverture de défauts élevée est obligatoire.

 Pour des dispositifs de type PLD, on suppose que le minutage est correct par construction.
Le minutage réel n'est donc pas vérifié. Seule la programmation réussie peut être vérifiée en
lisant le schéma programmé à la production. Ceci ne garantit pas un comportement correct
du dispositif (même raisonnement que pour les dispositifs volatils).

blocs macros
configurables

Entrée graphique /
Entrée schématique Entrée (V)HDL niveau élevé

Organigramme, diagramme de
Schéma (V)HDL situation et synoptique

Équations de
Entrée booléenne transition d'état, etc. Convertisseur Synthèse Convertisseur

Équations booléennes base de données de

Données de configuration conception de listes netlist

Conception
Monteur Emplacement et
acheminement

Schéma fusemap / Flot

binaire

Programmateur

Production

dispositif PROM de
programmé configuration

Figure 16 : Organigramme conceptuel simplifié des PLD/FPGA

3.4.3.5. Retour d’expérience

Les définitions de IEC 61508-2 pour les composants de classe A et B impliquent que l'expérience
pratique doit se baser sur au moins 100 000 heures d'exploitation sur une période de deux ans avec
10 systèmes dans différentes applications. En particulier, pour les composants standard complexes,
l'utilisateur final ne sait pas si les dispositifs qui sont effectivement utilisés sont fabriqués pour la
période de temps requise avec la révision de masque actuelle et sur la ligne de procédé actuelle.

- 54 -
Pour les circuits intégrés spécifiques à une application (ASIC) complexe, les termes d'expérience ou
d'éprouvé doivent être clarifiés et associés aux différentes entrées pour le processus de conception :
 Technologie de processus.

 Règles de conception pour l'emplacement de cellules, interconnexion et configuration.

 Noyaux macros générés ou prédisposés.

 Bibliothèques de cellules, incluant des informations de configuration et des modèles de

simulation.

 Macros logiciels.

 Outils de conception : configuration, synthèse, simulation.

En outre, des règles pour l'évitement de défauts au cours du processus de conception et pour les
tests de validation après migration à une autre technologie de processus doivent être élaborées. Des
stratégies égales doivent être utilisées à la fois pour les circuits intégrés standard et les circuits
spécifiques aux applications parce que, par exemple, il n'est pas acceptable que des modifications
d'un circuit intégré standard soient acceptées en l'état alors que la même modification d'un dispositif
spécifique à une application nécessite des tests de validation supplémentaires.

3.5. Validation

3.5.1. Introduction

En général, un processus de validation est effectué pour confirmer par examen et fourniture de
preuves objectives que les exigences particulières pour une utilisation spécifique prévue sont
remplies [IEC 61508-4, § 3.8.2]. Lorsque la validation est associée à des composants liés à la
sécurité d'un système de commande, le but est de déterminer le niveau de conformité de leurs
spécifications au sein des spécifications d'exigences de sécurité globales des machines [pr EN 954-2
1999].
La conduite d'un processus de validation peut être une tâche laborieuse, en particulier pour les
systèmes compliqués, qui ont des demandes de sécurité élevées. Cependant, bien que le processus
puisse être laborieux, il est aussi nécessaire. La validation est souvent nécessaire pour prouver :
 aux clients que le produit peut s'appliquer à l'objectif prévu,

 aux autorités que le produit est suffisamment sûr et fiable pour l'objectif prévu,

 au fabricant que le produit est prêt pour le marché,

 les raisons de solutions spécifiques,

 la qualité du produit.

- 55 -
Le processus de validation s'est étendu pour répondre aux besoins courants à mesure que la
technologie s'est développée. Des systèmes simples peuvent être analysés (AMDE) et testés
(injection de défauts) de manière très détaillée. Des systèmes à complexité modérée peuvent être
analysés de manière très détaillée, mais les tests ne peuvent couvrir le système complet. Des systèmes
très complexes ne peuvent être analysés totalement en détail et des tests détaillés ne sont pas
possibles non plus. Un certain nombre de méthodes différentes sont nécessaires dans le processus.
Des analyses sont nécessaires au moins au niveau du système et au niveau détaillé des composants,
mais les exigences liées à différentes phases du cycle de vie doivent également être remplies. Ceci
signifie que des attributs tels que le contrôle de la qualité, des méthodes de conception correctes et la
gestion deviennent plus importants puisque la plupart des pannes ou erreurs sont liées à ce genre de
problèmes.

La confiance est un facteur très important lié au processus de validation. L'utilisateur de documents
de validation doit faire confiance à la qualité de la validation, sans quoi la validation n'a aucun sens.
Les activités de validation sont bien effectuées pour convaincre quelqu'un que le produit est
correctement conçu et fabriqué. Une manière d'accroître la confiance est d'effectuer le processus de
validation en fonction d'instructions et d'exigences existantes et d'impliquer des experts objectifs dans
le processus de validation.

3.5.2. Processus de validation

Le processus de validation de sécurité consiste en la planification et la validation elle-même. Le

même processus peut également être appliqué à des sous-systèmes. Une liste de contrôle ou un autre
guide est nécessaire dans le processus pour inclure toutes les actions nécessaires au plan de
validation de sécurité.

DÉBUT

Liste des Considérations Plan de Principes de

défauts
de conception validation validation

Documents Analyse

Critères pour
exclusions de défauts
L'analyse est-elle Non
Tests
suffisante ?
Non
Oui
Oui
Enregistrement de Les tests sont-ils
validation complets ?
FIN

Figure 17 : Vue d'ensemble du processus de validation [prEN 954-2 1999]

- 56 -
Tout d'abord, le plan de validation est établi en fonction de principes de validation connus. Puis le
système est analysé en fonction du plan de validation et des critères connus et des considérations
conceptuelles. Les tests sont menés conformément au plan de validation et des résultats de l'analyse.
Toutes les phases doivent être enregistrées afin d'avoir une preuve fiable du processus de validation
ainsi que les documents d'aide à des modifications futures.

3.5.2.1. Planification de validation

La planification de validation de sécurité est effectuée pour faciliter et souligner la qualité de la

validation de sécurité. La planification indique l'organisation et, en ordre chronologique, les activités
de tests et de vérification nécessaires au processus de validation. Une liste de contrôle est nécessaire
dans le processus de planification afin d'inclure toutes les analyses et les tests essentiels dans le plan
de validation de sécurité. Cette liste de contrôle peut être constituée à partir de IEC 61508-1,
prEN 954-2 ou la méthode Nordtest. De grands systèmes de commande peuvent inclure des sous-
systèmes distincts, qu'il est pratique de valider séparément.

L'entrée principale pour la planification de validation de sécurité est les exigences de sécurité.
Chaque exigence doit être testée dans le processus de validation et les critères de réussite doivent
être déclarés dans le plan. Il est également important de déclarer la ou les personnes qui prennent les
décisions si un événement inattendu se produit, ou qui a la compétence d'effectuer la validation. En
conséquence, la planification de validation de sécurité fournit des directions sur la manière d'effectuer
une validation de sécurité.

3.5.2.2. Validation

Une validation de sécurité s'effectue conformément au plan de validation de sécurité. En

conséquence de la validation de sécurité, il est possible de voir que le système lié à la sécurité
respecte les exigences de sécurité puisque toutes les exigences de sécurité sont validées. Lorsque des
divergences se produisent entre les résultats attendus et réels, on doit décider s'il faut émettre une
requête pour modifier le système ou les spécifications et les applications éventuelles. Il faut
également décider s'il faut continuer et effectuer les modifications nécessaires plus tard ou effectuer
les modifications immédiatement et commencer le processus de validation à une phase antérieure.

3.5.2.3. Validation par analyse

Différentes techniques d'analyse sont nécessaires dans différentes phases de la conception. D'abord,
des techniques d'identification des dangers et d'analyse des risques sont utiles comme, l'analyse des
risques type HAZOP, l'analyse préliminaire des dangers PHA. Il existe de nombreuses techniques
pour la vérification logicielle et pour une approche probabiliste pour déterminer l'intégrité de
sécurité. En vérification logicielle, les erreurs logicielles sont recherchées systématiquement en
utilisant une analyse de flux de données, une analyse de flux de contrôle, une AMDE logicielle, ou
une analyse de circuit de fuite. En approche probabiliste, on s'attend à ce que le processus de
vérification soit déjà effectué et des valeurs statistiques sont utilisées afin de calculer une valeur
probabiliste pour exécuter le programme correctement.

- 57 -
Il existe également des méthodes pour vérifier les conceptions de composants comme un ASIC. Ce
chapitre, cependant, se concentre sur des techniques d'analyse qui sont utilisées dans l'analyse des
systèmes de commande.

Il existe deux types de techniques basiques pour l'analyse de systèmes :

 Les approches descendantes (déductives), qui commencent avec un ou plusieurs
événements supérieurs de niveau défini et dont on conclut des facteurs déclenchants.

 Les approches ascendantes, qui commencent avec des pannes uniques et dont on conclut les
conséquences au niveau du système.

La combinaison des approches ascendantes et descendantes est souvent une approche efficace.
L'analyse descendante fournit la vue globale et peut concentrer l'analyse à des zones qui sont plus
significatives du point de vue de la performance globale. Les approches ascendantes peuvent alors
être centrés sur les composants les plus sensibles. L'analyse ascendante vise à découvrir "le diable qui
se cache dans les détails".

 AMDE : lorsque la sécurité et la performance d'un système de commande sont évaluées,

l'analyse des modes de défaillance et effets (AMDE) est l'outil le plus communément utilisé.
Dans l'AMDE, tous les composants, éléments ou sous-systèmes du système contrôlés sont
listés. Elle est principalement destinée à des pannes aléatoires uniques puisqu'elle considère
tous les composants (individuellement ou en blocs) de manière systématique.

 FTA : l’objectif de cette méthode est d'identifier des combinaisons de pannes de composants
et d'erreurs humaines qui peuvent résulter de l'événement supérieur. L'arborescence de
défauts est exprimée en un modèle graphique qui indique des combinaisons de pannes de
composants et d'autres événements qui peuvent résulter dans l'événement supérieur.

Habituellement, les analyses à la fois au niveau modules/système et au niveau des composants sont
nécessaires à la validation des systèmes complexes. Des analyses au niveau système/modules sont
conduites afin de déterminer les composants sensibles du système et des analyses au niveau des
composants sont conduites pour ces composants du système.

3.5.2.4. Méthodes de tests

Les stratégies de la boîte noire (BB, Black Box) et de la boîte blanche (WB, White Box) sont deux
approches de base utilisées pour la modélisation des systèmes, qui peuvent être appliquées dans toute
phase du processus de conception. Elles sont caractérisées selon l'aspect auquel l'analyste, le
concepteur ou le testeur prête attention, à savoir, au fonctionnement externe du système ou aux
détails du fonctionnement interne.

En général, on dit qu'une approche fonctionnelle (ou BB) est utilisée en se référant à un système,
lorsque le système est considéré dans son ensemble, en soulignant son comportement perçu externe.

- 58 -
D'autre part, dans le cadre de l’approche structurelle (ou WB), un système est défini comme un
ensemble de composants liés ensemble afin d'agir réciproquement ; chaque composant est à son tour
un autre système. La récursion s'arrête lorsqu'aucune autre structure interne ne peut être discernée,
ou n'est pas intéressante et peut être ignorée.

Dans le domaine des tests, les approches fonctionnelles et structurelles sont utilisées pour créer des
modèles décrivant les aspects spécifiques du système. Le test a pour objet de vérifier si ces aspects
respectent les exigences ou non, en d'autres termes, de couvrir le modèle dans la mesure du possible.
A cet effet, le testeur utilise différents critères de couverture qui représentent les critères de sélection
pour les données d'entrée de test.

Ainsi, nous trouvons, pour les tests logiciels, des modèles structurels comme l'organigramme de
commande (en plus du listage de code source) et des critères de couverture comme décision ou tests
des instructions et tests de branchement, essentiellement pour les tests au niveau de
l'unité/composant. Et dans le cas du matériel, des modèles structurels comme un diagramme logique
topologique et des critères de couverture comme la sensibilisation à chemin unique, pour les tests au
niveau du composant.

Dans les tests fonctionnels, les données de test sont uniquement dérivées des spécifications. Si on
souhaite utiliser cette approche pour trouver tous les défauts d'un système, le critère est représenté
par les tests d'entrée exhaustifs (c'est-à-dire l'utilisation de chaque condition d'entrée possible comme
cas de test). Par conséquent, pour tester un système, on devrait produire un nombre considérable de
cas de test, et ceci sans prendre en considération les cas de test supplémentaires dus aux exigences
spéciales des systèmes de sécurité sur le comportement en cas de défaut (catégorie).

Dans les tests structurels, le testeur dérive des données de test d'un examen de la logique interne du
système (souvent au détriment des spécifications). Les tests structurels sont intrinsèquement finis.
Contrairement aux tests fonctionnels, on suppose que les tests structurels ne peuvent pas réaliser un
test complet du système. En outre, un test structurel ne garantit en aucun cas qu'un système
correspond à sa spécification (en raison de conception erronée, de pièces manquantes, etc.).

Pour un critère de sélection spécifique, les données d'entrée de test peuvent être générées
conformément à deux procédures différentes : choix déterministe ou choix probabiliste. Pour les
systèmes de commande électroniques liés à la sécurité, à appliquer dans le secteur des machines, il
semble qu'un test déterministe fournisse suffisamment de tests, sans qu'il soit nécessaire d'appliquer
des tests statistiques.

Une stratégie de test doit considérer d'autres aspects essentiels comme la phase de cycle de vie, le
niveau d'abstraction et les objectifs de test (vérification et évaluation), en plus du type de modèle de
système (fonctionnel ou structurel), des critères de sélection des donnée de test et de la procédure de
génération des entrées.

- 59 -
Ni les tests fonctionnels ni les tests structurels ne s'avèrent être des stratégies absolument infaillibles :
les deux ont des limites et les deux ciblent des défauts différents. On propose d'associer des éléments
des tests BB et WB pour en déduire une stratégie de test raisonnable mais pas hermétique,
raisonnable dans le sens d'une relation acceptable entre le nombre de cas de tests et les garanties
recherchées (exigences de réduction de risques).

Tests d'injection de défauts

Conformément à la norme EN 954, une des méthodes de test pour valider la sécurité des systèmes de
commande est l'injection de défauts. En général, l'injection de défauts est une technique privilégiée
pour valider une fonction pertinente des systèmes de sécurité : le comportement en cas de défaut.
Les méthodes d'injection de défauts physiques et d'injection de défauts par logiciel fournissent des
données précises sur les performances réalisées par un système réel proche du système final.

L'injection de défauts est un complément indispensable aux autres méthodes de validation

actuellement disponibles (techniques analytiques, tests fonctionnels et basés sur la structure, tests
symboliques). Cette complémentarité peut parvenir à l'établissement d'une relation étroite avec des
modèles analytiques (par exemple, les modèles Markov), en assistant la caractérisation du modèle
analytique initial (une meilleure compréhension des processus de panne, généralement décrits par des
modèles macrocospiques, en affectant des valeurs aux paramètres de couverture des mécanismes de
commande des pannes) et en validant voire en mettant au point le modèle analytique.

La validation peut être perçue comme un processus visant à supprimer les défauts de conception
résiduels et à évaluer les performances réalisées même au-delà de l'hypothèse spécifiée.

3.5.3. Vérification et validation du logiciel

3.5.3.1. Évaluation du logiciel de sécurité

Le problème soulevé par l'évaluation du logiciel est d'obtenir une confiance justifiée dans le
comportement du logiciel. Le logiciel est souvent analysé conformément à la méthode utilisée pour
son développement. L'évaluation se base ensuite sur un large choix de critères tels que sa structure,
son processus de développement, ou la manière dont il a été rédigé, même si, en fait, seul son
comportement doit être évalué. C'est pourquoi il est relativement difficile de distinguer les méthodes
de développement et les méthodes d'évaluation. Ces deux types de méthodes se chevauchent de plus
en plus.

Enfin, il est intéressant de remarquer qu'il n'y a pas de méthodes spécifiques pour les logiciels
sensibles. Les méthodes utilisées pour le logiciel sensible et celles utilisées pour les logiciels
traditionnels diffèrent par les exigences des normes. La principale différence, en fait, réside dans le
budget et le temps consacrés.

L'évaluation du logiciel peut avoir des significations très diverses. En général, on distingue souvent
deux niveaux d'évaluation : la validation et la vérification.

- 60 -
 3.5.3.2. Vérification du logiciel

Les activités de vérification ont pour objet de démontrer que les produits logiciels découlant d'une
phase donnée du cycle de développement sont conformes aux spécifications établies durant les
phases précédentes et à toutes normes ou règles applicables. Elles permettent également de détecter
et de représenter toutes les erreurs pouvant être introduites au cours du développement du logiciel.

Les activités de vérification du logiciel contiennent des séries de test et d'analyse. Outre les tests, les
activités de vérification peuvent reposer sur des techniques telles que révisions, inspections,
contrôles, mesures de vérification et vérification de code. Dans certains cas, les révisions et les
analyses peuvent remplacer certains tests (par exemple dans le cas où un test ne peut pas être réalisé
parce qu'il entraînerait la détérioration d'un composant matériel). Les révisions internes permettant au
concepteur de s'assurer, aux points clé de l'avancement du développement, que le produit atteindra
ses objectifs.

Les tests de logiciel peuvent être réalisés à différentes phases du cycle de vie :
 Tests de module au niveau de chaque individu. Ces tests se concentrent sur les modules
logiciels et leur conformité par rapport à la conception détaillée. Cette conformité peut
également être démontrée en utilisant des techniques statiques (relecture du code). Cette
phase de la procédure de vérification permet la détection du type suivant d'erreurs :
 incapacité d'un algorithme à satisfaire les spécifications logicielles,
 opérations de boucle incorrectes,
 décisions logiques incorrectes,
 incapacité à calculer correctement les combinaisons valides de données d'entrée,
 réponses incorrectes aux données d'entrée altérées ou manquées,
 violation des limites de tableau de mémoire,
 séquences de calcul incorrectes,
 précision, exactitude ou performance insuffisantes d'un algorithme.
 Tests d'intégration de logiciel. Ces tests (équivalents à la vérification de conception de
logiciel) se concentrent sur l'assemblage correct des modules logiciels et sur les relations
réciproques entre les composants logiciels. Les tests d'intégration de logiciel forment la
principale composante de cette vérification. Elle peut être utilisée pour révéler des erreurs
du type suivant :
 initialisation incorrecte des variables et des constantes,
 erreurs du transfert des paramètres,
 toute altération de données, spécialement les données globales,
 résolution numérique de bout en bout insuffisante,
 mise en séquence incorrecte des événements et des opérations.

- 61 -
  Tests de validation. Ces tests (équivalents à la vérification de spécification logicielle) ont
pour objet de détecter les erreurs associées au logiciel dans l'environnement système cible.
Les tests de validation sont la principale composante de la vérification de spécification
logicielle. Les erreurs détectées par ce type de vérification incluent :
 tout mécanisme incorrect de traitement des interruptions,
 respect insuffisant des exigences de temps d'exécution,
 réponse incorrecte du logiciel fonctionnant en mode transitoire (démarrage, flux d'entrée,
commutation en mode dégradé, etc.),
 conflits d'accès à différentes ressources ou problèmes organisationnels dans la mémoire,
 incapacité des tests intégrés à détecter les défauts,
 erreurs de l'interface logicielle/matérielle,
 débordements de pile.

3.5.3.3. Exigences de vérification de logiciel

Les exigences générales de vérification incluent les éléments suivants :

 La stratégie de vérification de logiciel utilisée à différentes étapes du développement de
logiciel et les techniques et outils utilisés pour cette vérification doivent être décrits dans un
Plan de test avant utilisation. Cette description doit, au minimum, inclure :

 l'identification du logiciel et de ses composants liés à la sécurité qui seront soumis à

une procédure de validation avant utilisation,

 l'organisation des activités de vérification (intégration, validation, etc.) et de toute

interface avec les autres activités de développement,

 l'indépendance de la vérification (si applicable) : la stratégie de vérification doit être

développée et mise en œuvre, et les résultats des tests doivent être évalués de
manière indépendante (par un individu, un service ou une organisation) par rapport
à la taille de l'équipe de développement,

 méthodes et outils de vérification utilisés (types de tests, etc.),

 environnement de la vérification (équipement de test, émulateurs, etc.),

 manière dont les résultats des tests ont été vérifiés,

 une matrice de traçabilité démontrant la correspondance entre les tests à

entreprendre et les objectifs des tests définis.

 La vérification d'une nouvelle version logicielle doit inclure des tests de non-régression.

 Les directives pour établir des procédures de test doivent inclure une description des
données d'entrée à utiliser (valeur), une description de la sortie prévue (valeur) et des
critères sur lesquels les résultats des tests seront jugés acceptables (tolérance).

- 62 -
  Les tests formalisés dans les rapports doivent pouvoir être de nouveau réalisés (par
exemple, en présence de l'analyste).

Les exigences de vérification incluent également des exigences de révision et de vérification de

code. Les révisions internes aux points clé du processus de développement permettent au concepteur
de s'assurer que le produit atteindra les objectifs fixés. Une révision de spécification externe (avec
l'analyste) doit se dérouler à la fin de la phase de spécification logicielle et respectivement une
validation externe à la fin de la phase de validation. Le résultat de chaque révision doit être
documenté et archivé. Il doit inclure une liste de toutes les actions décidées dans le processus de
révision et la conclusion de la révision (décision de passer ou non à l'activité suivante). Les activités
définies dans la révision doivent être surveillées et traitées.

Les exigences de test logiciel incluent les exigences générales de vérification pour la spécification
logicielle (tests de validation), la conception logicielle (tests d'intégration logicielle) et la conception
détaillée (tests de module). Les objectifs de test doivent être adaptés au niveau d'intégrité de sécurité
du logiciel, au type du logiciel et aux facteurs spécifiques en jeu pour l'adoption d'un produit logiciel
donné. Ces critères déterminent les types de test à entreprendre (tests fonctionnels, tests dans les
limites, tests hors limite, tests de performance, tests de charge, tests de panne d'équipement externe,
tests de configuration) ainsi que la gamme d'objets devant être couverts par les tests (tests de mode
fonctionnel, tests de fonction de sécurité, tests de chaque élément de la spécification, etc.).

Les tests de validation doivent être effectués en conditions représentatives des conditions
opérationnelles du système. La couverture de ces tests doit être explicite dans une matrice de
traçabilité et doit démontrer que chaque élément de la spécification, incluant les mécanismes de
sécurité, est couvert par un test de validation et qu'il est possible de vérifier le comportement en
temps réel du logiciel dans tout mode opérationnel.

Les tests d'intégration doivent être en mesure de vérifier la mise en séquence correcte de
l'exécution du logiciel, l'échange de données entre les modules, le respect des critères de performance
et la non altération des données globales. La couverture de test doit être indiquée de manière
explicite dans une matrice de traçabilité indiquant la correspondance entre les tests à entreprise et les
objectifs des tests définis.

Les tests de module doivent vérifier, en utilisant les données d'entrée, que les modules remplissent
les fonctions spécifiées à la phase de conception détaillée. La couverture de test doit être indiquée de
manière explicite dans une matrice de traçabilité qui démontre la correspondance entre les tests à
entreprendre et les objectifs des tests définis.

3.5.3.4. Validation de logiciel sensible

Trois types de langage de spécification peuvent être distinguées : spécification en langage ordinaire,
spécification semi-formelle et spécification formelle. Les spécifications informelles rédigés en langage
ordinaire sont généralement incomplètes, incohérentes, ambiguës, contradictoires et erronées. En
conséquence, il semble raisonnable de ne pas les utiliser pour le logiciel de sécurité.

- 63 -
Contrairement au langage ordinaire, les spécifications mises en œuvre par des méthodes formelles
sont précises et la sémantique des notations est clairement définie. Si l'on connaît la représentation
utilisée, les méthodes formelles sont un bon moyen de communication et de documentation. En fait,
les méthodes formelles sont plus qu'un outil de représentation ; elles sont également une technique de
préparation des spécifications, ce qui contraint le concepteur à procéder à des abstractions et aboutit
finalement à une meilleure compréhension et modélisation des spécifications. Il est parfois même
possible d'effectuer des simulations. L'utilisation d'une méthode formelle nécessite des
investissements considérables en temps et en formation. Cependant, les méthodes formelles sont une
étape significative vers le développement et l'évaluation de logiciel sensible.

3.5.4. Validation du matériel

3.5.4.1. Validation des principes de détection de défaut

Les systèmes électroniques programmables PES sont en mesure de détecter les défauts se trouvant
en eux avant qu'un défaut ne se manifeste comme une panne du système. Les techniques et mesure
utilisées se concentrent sur les différentes parties du matériel électronique et peuvent nécessiter
différents niveaux d'effort du système. On considère que l'état actuel de la technique consiste à
mettre en œuvre des techniques pour la détection de défauts dans les PES utilisés dans les
applications sensibles pour la sécurité.

Tous les systèmes sensibles pour la sécurité doivent entreprendre des mesures de base pour détecter
les défauts, et éventuellement contrôler les pannes qui peuvent survenir. La norme EN 954-1 spécifie
5 catégories pour le comportement du système en défaut. Des principes de sécurité de base doivent
être mis en œuvre pour les catégories B, 1, 2, 3 et 4. Pour les catégories 1, 2, 3 et 4, des principes de
sécurité éprouvés doivent également être mis en œuvre. La présence et les performances des
principes de sécurité doivent être validées.

Méthodes de détection des défauts

Il y a plusieurs aspects dans un système électronique programmable qui peuvent être auto-contrôlés
de manière automatique. Le tableau suivant donne des exemples des différentes techniques.

- 64 -
 Composant Techniques
Unité de traitement Autotest de l'exécution du jeu d'instruction.
Autotest des registres par modèle ou bit mobile.
Comparaison réciproque par logiciel entre deux unités de traitement.
Plages de mémoire Somme de contrôle
invariables Signature 8 bits
Signature 16 bits
Réplication
Plages de mémoire variables Test RAM "checkerboard" ou "march"
Test RAM "walkpath"
Test RAM "galpat"
Unités E/S et interface Sortie parallèle à voies multiples
Sorties surveillées
Comparaison d'entrée/vote
Chemin d’accès de données Inspection utilisant des modèles de test
Redondance de transmission
Redondance d'informations
Alimentation Protection surtension avec arrêt de sécurité
Surveillance de tensions secondaires
Mise hors tension avec fermeture de sécurité
Séquence d'instructions Un chien de garde sur puce avec base de temps séparée sans fenêtre de temps, par
exemple microcontrôleur Motorola 68HC11
Un chien de garde avec base de temps séparée sans fenêtre de temps, par exemple un
circuit intégré de superviseur microprocesseur Maxim
Surveillance logique de la séquence de programme mise en œuvre dans le logiciel
Combinaison d'une surveillance temporelle et logique de la séquence de programme

Tableau 19 : Méthodes de détection des défauts

3.5.4.2. Tests de validation du matériel

Désormais, les composants complexes, comme les microprocesseurs, les mémoires (RAM, EPROM,
Flash), la logique programmable (PLD (Programmable Logic Device, dispositif à logique
programmable), FPGA), les ASIC (Application Specific Integrated Circuits, circuits intégrés
spécifiques à des applications) et autres circuits à haute intégration peuvent être utilisés comme blocs
structurels pour l'électronique liée à la sécurité. En raison de l'intégration à grande échelle, il est
possible aujourd'hui d'intégrer un système complet – qui nécessitait une carte ou un assemblage de
cartes il y a quelques années – en une seule puce.

Des tests de validation bien connus et représentant les dernières avancées dans ce domaine peuvent
être appliqués au niveau du (composant) système. Ces tests de validation de sécurité pour systèmes
électroniques sont affectés aux catégories de sécurité (CAT 1-4) introduites dans EN 954-1.

- 65 -
 Technique/mesure Cat 2 Cat 3 Cat 4
Tests fonctionnels HR HR HR
élevé élevé élevé
Tests fonctionnels en conditions environnementales HR HR HR
élevé élevé élevé
Tests d'immunité aux interférences HR HR HR
élevé élevé élevé
Tests d'injection de défauts HR HR HR
élevé élevé élevé
Tests fonctionnels élargis – HR HR
faible faible élevé
Test d'immunité aux surtensions – – –
faible faible moyen
Tests de boîte noire R R R
faible faible moyen
Tests statistiques – – R
faible faible moyen
Tests du "pire des cas" – – R
faible faible moyen

Tableau 20 : Tests de validation de sécurité pour systèmes électroniques

Notation :

évaluation qualitative pour cette méthode
(première ligne)
couverture de test requise de cette méthode
(deuxième ligne)
HR la méthode est très recommandée pour cette catégorie de sécurité
R la méthode est recommandée pour cette catégorie de sécurité
– la méthode n'est pas requise mais peut être utilisée
élevé3 une couverture de test de niveau élevé est requise
moyen un niveau moyen de couverture de test est requis
faible un niveau acceptable de couverture de test est requis

L'analyse détaillée de ces méthodes existantes révèle un certain nombre de limites possibles par
rapport à la validation d'un composant complexe :
 Complexité : le composant peut être beaucoup trop complexe pour une validation
adéquate ; il n'est pas possible d'atteindre les chiffres de couverture pour la catégorie
indiquée.

 Capacité de commande ou "contrôlabilité" : les interconnexions et la logique à l'intérieur du

composant ne sont pas directement contrôlables.

 Capacité d'observation ou "observabilité" : la réaction aux stimuli d'entrée peut ne pas être
observable ; la fixation de sondes est soit impossible (signaux internes) soit affecte les
résultats des tests.

En outre, un inconvénient supplémentaire des tests de validation énumérés est le fait qu'ils soient
uniquement applicables à un stade tardif du processus de développement parce qu'un matériel "réel"
est requis pour exécuter la plupart des tests. Le système qui est utilisé au cours du test de validation
doit être le plus proche possible de celui qui sera utilisé sur le terrain, autrement le résultat du test de
validation n'est pas du tout significatif.

3
"élevé" remplace le terme trompeur "obligatoire" utilisé dans les tableaux des normes existantes, par exemple dans la norme IEC 61508.

- 66 -
Pour les composants complexes, les tests de validation doivent aller "au-delà de la surface" du
composant et sont recommandés à un stade beaucoup plus avancé du processus de développement.
Par exemple, les tests fonctionnels doivent commencer au niveau du module – en utilisant des
modules à complexité très limitée – et doivent accompagner l'intégration hiérarchique (ascendante)
des modules à des blocs structurels plus complexes, étape par étape, jusqu'à ce que la fonctionnalité
complète d'un "composant complexe" soit atteinte et que toutes les exigences d'application et de
sécurité soient satisfaites.

Le Tableau 21 illustre un exemple des phases qui peuvent être identifiées comme des étapes majeures
dans le processus de conception d'un composant complexe (PLD, FPGA, Tableau de portes logiques
ou ASIC).

Phase Sortie Sortie (Gate Niveau de détail utilité pour vérification

(PLD/FPGA) Array, ASIC) (formelle ou simulation)
Spécification Documents de spécification (textuels description de "haut niveau" partielle (uniquement pour ces
pures ou semi-formels, par exemple en avec niveau de détail faible parties décrites comme semi-
utilisant des organigrammes et formelles)
diagrammes d'état, pseudo-code)
Description de Description formelle de la composants (virtuels) blocs, aspects fonctionnels (niveau RTL)
conception fonctionnalité du périphérique,
aucune information explicite sur le
utilisable pour traduction automatique. procédés de
comportement temporel
RTL (niveau de transfert de
registre "register transfer
level")
Mise en œuvre I liste "netlist" des liste "netlist" de primitifs FPGA, portes tous les aspects fonctionnels
primitives, base niveau de porte logiques ASIC ;
de données logique interconnexions (Niveau de porte logique)
(propriété) Niveau de porte logique temporisation estimée

Mise en œuvre II Schéma Fusemap base de données de emplacement et tous les aspects fonctionnels
/ flot binaire configuration (par interconnexion physique
exemple GDS-II) (Niveau de porte logique)
temporisation effective
Production périphérique périphérique Composant caractéristiques de périphérique
programmé (ou conditionné et testé (fonctionnalité globale,
PROM de temporisation)
configuration)
Post Production Carte / Système "boîte noire" tests de boîte noire uniquement

Tableau 21 : Modèle de phase

Pour aider à décider quel niveau de test de validation est requis au cours du processus de conception
et de mise en œuvre, on propose la classification suivante qui est basée sur l'aptitude aux tests ou
"testabilité" :
 Un composant est de complexité de test faible s'il convient d'exécuter les tests de validation
standard sur le composant final et d'atteindre la couverture de test requise. Pour ces
composants "simples", aucune modification de l'approche de validation standard n'est
requise ; néanmoins il peut être conseillé d'exécuter certains tests de validation au cours du
processus de conception.

- 67 -
  Un composant est de complexité de test moyenne si l'exécution de tests de validation
standard sur le composant final atteint une couverture de test pour au moins un test, qui est
inférieure d'un niveau à celle requise (couverture "moyenne" des tests fonctionnels au lieu
de la couverture "élevée" requise). Pour ces composants, l'exécution d'une partie des tests
de validation au cours du processus de conception et de mise en œuvre est requise, pour
améliorer la couverture de test.

 Un composant est d'une complexité de test élevée si l'exécution de tests de validation

standard sur le composant final atteint une couverture de test pour au moins un test, qui est
inférieure de deux ou plusieurs niveaux à celle requise (par exemple couverture "faible" des
tests fonctionnels au lieu de la couverture "élevée" requise). Pour ce niveau de complexité,
une connaissance détaillée du composant et de son utilisation prévue est requise pour
trouver une stratégie de test adéquate. Ainsi, aucune recommandation générale n'est
donnée.

Cat 1,2 Cat 3 Cat 4

Technique / mesure
Durant le Post Durant le Post
Durant le flux Post
flux Production flux Production
conceptuel Production
conceptuel conceptuel
HR HR HR
Tests fonctionnels élevé élevé élevé
élevé moyen élevé moyen élevé moyen
Tests fonctionnels en HR HR HR
conditions élevé élevé élevé
environnementales élevé moyen élevé moyen élevé moyen
Tests d'immunité aux HR HR HR
interférences moyen élevé élevé
– moyen – élevé – élevé
Tests d'injection de HR HR HR
défauts élevé élevé élevé
élevé moyen élevé moyen élevé moyen
– HR HR
Tests fonctionnels élargis faible faible élevé
faible faible faible faible élevé moyen
Test d'immunité aux – – –
surtensions faible faible moyen
– faible – faible moyen faible
R R R
Tests de boîte noire faible faible moyen
– faible – faible moyen faible
Tests statistiques – – R
faible faible moyen
faible faible faible faible moyen faible
Tests du "pire des cas" – – R
faible faible moyen
faible faible faible faible moyen faible

Tableau 22 : Tests de validation pour les composants à complexité de test moyenne

Nota : Pour l'interprétation de ce tableau, se reporter aux définitions ci-après.

Lorsque les tests de validation sont avancés dans le flux conceptuel, les étapes ultérieures doivent
être vérifiées de manière plus approfondie, afin de garantir que les résultats de la validation sont
encore valables pour le composant final.

- 68 -
4. APPLICABILITÉ DES NORMES EN 954 ET IEC 61508 SUR LES MACHINES

4.1. Introduction

Ce chapitre a pour objectif de comparer les méthodologies et exigences de deux normes, à savoir,
IEC 61508 « Sécurité fonctionnelle des systèmes électriques/électroniques/électroniques
programmables liés à la sécurité » et EN 954 « Sécurité des machines - Composants liés à la sécurité
des systèmes de commande ». Cette étude a été réalisée afin d'établir si ces deux normes définissent
les mêmes exigences ou des exigences différentes lorsqu'elles sont appliquées sur des systèmes de
commande de machine.

Les deux normes proposent une approche structurée de la conception des systèmes de commande
liés à la sécurité, mais diffèrent dans le sens où la norme EN 954 est conçue pour traiter tous les
types de technologies de système de commande tandis que la norme IEC 61508 a été principalement
(mais non exclusivement) conçue pour s'appliquer aux systèmes de commande
électriques/électroniques/électroniques programmables (E/E/PE). Les normes exigent que les
fonctions liées à la sécurité du système de commande soit classées ; la norme IEC 61508 exige qu'un
niveau d'intégrité de sécurité (SIL, Safety Integrity Level) soit attribué au système de commande
tandis que la norme EN 954 utilise un concept de performance de sécurité et classe le système dans
une catégorie parmi cinq. Il y a une différence significative dans la manière dont les SIL et les
catégories sont dérivées et définies. Les problèmes entraînées par cette différence constituaient la
base des tâches réalisées, particulièrement lorsque les deux classifications sont comparées en vue de
développer une stratégie pour les lier.

La norme IEC 61508 utilise une approche de cycle de vie de sécurité afin d'assurer que la conception
d'un système de commande CES lié à la sécurité est réalisée de manière systématique. Ce cycle de
vie, en tant que structure technique, a été examiné pour évaluer s'il convient à la conception des
systèmes de commande de machine.

4.2. Exigences communes et différences entre les normes EN 954-1 et IEC 61508

Les éléments ci-après sont considérés comme des facteurs de comparaison entre les normes
EN 954-1 et IEC 61508 utilisant le modèle de cycle de vie de sécurité comme structure technique.

Généralités
 La norme EN 954-1 ne prend pas la vue hiérarchique orientée sur le système qui est une
caractéristique forte de IEC 61508.

 La norme IEC 61508 se réfère aux systèmes liés à la sécurité, qui sont considérés comme
"intégrant" l'équipement sous contrôle pour fournir un niveau de sécurité. La norme
EN 954-1 se réfère aux composants liés à la sécurité des systèmes de commande.

- 69 -
  La norme IEC 61508 exige la production de documentation à chaque phase du cycle de vie
de sécurité. Les seuls documents spécifiques exigés par la norme EN 954-1 sont le plan de
validation et le rapport de validation.

 La norme IEC 61508 a une forte structure formelle avec des objectifs clairement définis et
des exigences spécifiées pour chaque phase du cycle de vie de sécurité. La norme EN 954-1
est beaucoup moins structurée et un examen minutieux est nécessaire pour extraire les
exigences clés.

Domaine d'application
 La norme EN 954-1 s'applique aux composants liés à la sécurité des systèmes de
commande, quel que soit le type de technologie utilisée. IEC 61508 est principalement
concernée par les systèmes CES.

 La norme IEC 61508 traite du cycle de vie entier, de la phase de conception au

déclassement des installations. La norme EN 954 se restreint à la phase de conception.
4
 La norme IEC 61508 prend en considération le système entier comprenant l'EUC , le ou les
système(s) lié(s) à la sécurité et les installations de réduction de risques externes. La norme
EN 954-1 est uniquement concernée par les "composants liés à la sécurité des systèmes de
commande".

Compétence des personnes

 Traitée par la norme IEC 61508, non par la norme EN 954-1.

Gestion de sécurité
 Traitée par la norme IEC 61508, non par la norme EN 954-1.

Concept
 Traité par la norme IEC 61508, non par la norme EN 954-1.

Analyse des dangers et des risques

Les deux normes exigent :

 La réalisation d’une analyse des dangers et des risques ;

 La considération de l'élimination des dangers ;

 L'inclusion des conditions de défaut, de la mauvaise utilisation raisonnablement prévisible et

des facteurs humains ;

 L'identification des évènements entraînant des dangers ;

 L'évaluation des fréquences (ou probabilités) des événements dangereux ;

4
EUC « Equipment Under Control » : Equipement commandé.

- 70 -
  L'identification des conséquences possibles ;

 L'évaluation du risque associé à chaque évènement dangereux ;

 L'identification de la réduction de risques nécessaire, pour chaque danger.

Différences
 La norme IEC 61508 se rapporte aux "événements dangereux des EUC". La norme
EN 954-1 se rapporte au temps/fréquence de l'exposition au danger.

 La norme IEC 61508 permet des techniques quantitatives ou qualitatives. La norme

EN 954-1 place l'accent sur les techniques qualitatives/empiriques.

 La norme IEC 61508 exige qu'un "niveau de sécurité" (basé sur le risque tolérable) soit
identifié pour chaque danger. La norme EN 954-1 se rapporte simplement à la réduction de
risques appropriée.

 La norme IEC 61508 exige que les informations et les résultats de l'analyse de danger et de
risque soient documentés. La norme EN 954-1 n'a aucune exigence de documentation.

Spécification des fonctions de sécurité

 La norme IEC 61508 exige une spécification de toutes les fonctions de sécurité incluses
dans la "combinaison totale des systèmes liés à la sécurité et des installations de réduction
de risques externes". La norme EN 954-1 exige uniquement la spécification des fonctions de
sécurité à fournir dans le système de commande.

 La norme IEC 61508 exige une spécification et description fonctionnelles des SIL. La
norme EN 954-1 exige uniquement une description fonctionnelle.

 La norme EN 954-1 énumère les fonctions de sécurité communes et les caractéristiques

associées applicables aux machines.

 La norme IEC 61508 permet que les fonctions de sécurité soient attribuées entre les
systèmes liés à la sécurité et les installations de réduction de risques externes. La norme
EN 954-1 traite uniquement ces fonctions de sécurité mises en œuvre par les "composants
liés à la sécurité".

Spécification des exigences de performance pour les systèmes de commande

 La norme IEC 61508 spécifie un processus formel par lequel, pour chaque danger, la
réduction de risques nécessaire est dérivée du risque EUC et du niveau de sécurité. Il est
ainsi nécessaire de spécifier comment le niveau de sécurité (et la réduction de risques
associée) sera atteint. Ceci est effectué en décrivant ce que les systèmes liés à la sécurité
feront (c'est-à-dire les fonctions de sécurité) et avec quelle probabilité ils le feront comme
requis (c'est-à-dire l'intégrité de sécurité). À ce stade, les systèmes liés à la sécurité peuvent
prendre la forme d'installations externes ou de systèmes de commande (de toute
technologie). Les systèmes individuels liés à la sécurité doivent être spécifiés en termes de
fonctionnalité et d'efficacité (par rapport à une technologie spécifique) afin que toutes les
fonctions de sécurité soient mises en œuvre avec le niveau requis d'intégrité de sécurité (en

- 71 -
 prenant en considération l'effet total de tous les systèmes liés à la sécurité désignés). Il
convient de noter que le niveau d'efficacité des systèmes individuels liés à la sécurité est
également mesuré par le paramètre d'"intégrité de sécurité". IEC 61508 exige que les
informations et les résultats du processus d'attribution des exigences de sécurité soient
documentés.

 La norme EN 954-1 exige que les mesures de réduction de risques par des moyens de
contrôle soient "décidées" et spécifiées en termes de fonctionnalité et de catégorie. La
méthodologie pour traduire la réduction de risques (associée à des dangers particuliers) en
exigences de performance des composants liés à la sécurité des systèmes de commande n'est
pas spécifiée.

 La norme IEC 61508 exige que l'efficacité des systèmes de commande liés à la sécurité soit
classée conformément à l'intégrité de sécurité. L'intégrité de sécurité est une mesure
quantifiée de l'efficacité d'un système de commande lié à la sécurité et englobe la fiabilité du
matériel ainsi que le contrôle/évitement de pannes dues au défauts systématiques.

 La norme EN 954-1 exige que les composants liés à la sécurité des systèmes de commande
soient classés en catégorie conformément à la résistance aux défauts. Les mesures de
performance associées aux catégories sont une description des mesures prises pour éviter
ou contrôler les pannes et ne sont pas quantifiées.

 La norme IEC 61508 exige que les fonctions globales de sécurité et les exigences d'intégrité
de sécurité soient documentées dans une "Spécification d'exigences globales de sécurité"
(Overall Safety Requirements Specification). Les exigences correspondantes pour les
systèmes individuels CES liés à la sécurité sont documentées dans les "Spécifications
d'exigences de sécurité CES" (CES Safety Requirements Specifications).

Conception
 Les deux normes exigent que la conception remplisse les exigences de sécurité spécifiées,
mais la norme IEC 61508 exige que la documentation de conception identifie et justifie les
techniques et mesures choisies pour réaliser les SIL. Avec IEC 61508, des tableaux étendus
de techniques et mesures recommandées (pour le matériel et le logiciel) sont fournis.
EN 954-1 exige simplement une liste des caractéristiques de conception qui fournissent le
raisonnement de conception pour la catégorie réalisée.

 La norme IEC 61508 recommande des contraintes architecturales, EN 954-1 ne traite pas
de l'architecture (autres que celles pouvant être nécessaires pour réaliser le comportement
en cas de défaut conformément à la catégorie).

Comportement en conditions de défaut

 Les deux normes exigent la considération du comportement en conditions de défaut. Dans
la norme IEC 61508, les exigences de défaut dépendent de SIL, de l'étendue de la
couverture de diagnostic, de la connaissance des modes de défaillance de composant, de la
testabilité des composants et de la connaissance de la fiabilité des composants. Dans
EN 954-1, les exigences de défaut sont dictées uniquement par le choix de catégorie.

- 72 -
Couverture de diagnostic
 La norme IEC 61508 émet des recommandations en ce qui concerne le niveau de
couverture de diagnostic fourni par les techniques et les mesures utilisées pour contrôler les
pannes. La norme EN 954-1 accepte de la même manière que tous les défauts ne puissent
pas être détectés. Dans la catégorie 3, les mesures exigées pour la détection de défauts
doivent être classées conformément à la conséquence et à la probabilité de panne et à la
technologie utilisée. Dans la catégorie 4, l'incapacité à détecter certains défauts conduit à
l'exigence d'indiquer qu'une accumulation de défauts n’entraîne pas une perte de la fonction
de sécurité.

Vérifications de contrôle
 La norme IEC 61508 exige que des vérifications de contrôle soient entreprises afin que la
probabilité de panne sur demande reste dans le niveau spécifié d'intégrité de sécurité. Les
vérifications de contrôle ne sont pas traitées par la norme EN 954-1.

Intégration
 L'intégration (logiciel, matériel, modules, capteurs, actionneurs) des systèmes CES est
traitée par la norme IEC 61508, non par EN 954-1.

Exploitation & maintenance

 Les deux normes exigent des informations pour l'exploitation et la maintenance.

Validation
 Les deux normes exigent une validation pour démontrer que les fonctions de sécurité ont
été mises en œuvre conformément aux spécifications.

Modification
 Traitée par IEC 61508, non par EN954-1.

Vérification
 Exigée par IEC 61508, non par EN 954-1.

Évaluation de sécurité de fonctionnement

 Exigée par IEC 61508, non par EN 954-1.

Déclassement des installations

 Traitée par IEC 61508, non par EN 954-1.

- 73 -
 4.3. Difficultés pratiques rencontrées pour la validation d’une machine

Le second point de l’étude consistait à examiner l'application rétrospective des normes EN 954-1 et
IEC 61508 sur des machines existantes comme partie d'un exercice de validation de système de
commande de machine. L'objectif fondamental de cet exercice n'était pas d'évaluer, ni de tester, la
machine mais d'identifier les différences entre les approches prises par les deux normes.

4.3.1 Sélection du système de commande de machine lié à la sécurité à valider

Les exigences du système de commande lié à la sécurité étaient les suivantes :

 il a une complexité technique suffisante dans la configuration de son ou ses systèmes de
commande pour permettre une application suffisante de l'une ou l'autre des normes ;

 il doit inclure un système électronique programmable ;

 il s'agit d'une application pratique dans une machine existante ;

 le fabricant, ou son concepteur, doit être facilement joignable, si nécessaire, pour élucider
les critères de conception ou les détails de son exploitation ; et

 le fabricant doit être disposé à coopérer au projet et à fournir le matériel technique

nécessaire pour permettre la réalisation de la validation.

Il a été décidé qu'une machine appropriée pour cet exercice serait une presse hydraulique fabriquée
au Royaume Uni. Les détails techniques de la machine examinée sont les suivants :
 Contrôleur à commande numérique directe DNC ("Direct Numerical Control") à axes
multiples ;

 Fonctionnement hydraulique avec servo-commande individuelle de la position de chaque

extrémité du faisceau avec commande à pression hydraulique;

 Tailles de 30 à 3 000 tonnes, particulièrement 100 tonnes sur la machine examinée ; et

5
 Rideau photoélectrique permettant une protection photoélectrique normale ou une
protection en association avec amorçage de course à rupture unique ou double.

4.3.2 Événements dangereux considérés

Un examen complet du système du commande de la machine n'aurait pas été en mesure de produire
des résultats supplémentaires à ceux obtenus par une analyse limitée. Par conséquent :
 pour éviter la répétition de l'analyse, l'exploitation de la machine a été considérée
uniquement en mode manuel (c'est-à-dire que les modes d'amorçage à rupture unique ou
double n'ont pas été considérés.) ; et

5
Un système photoélectrique est familièrement désigné comme une protection photoélectrique, en dépit du fait qu'il n'empêche pas d'accéder à la zone
dangereuse et parfois comme une protection intangible. Un terme plus précis est un périphérique de protection optoélectronique actif AOPD (Active Opto-
electronic Protective Device). Cependant, comme le terme de protection photoélectrique est plus communément utilisé et compris, ce terme sera utilisé tout
au long de ce document.

- 74 -
  les dangers les plus importants associés à la machine ont été déterminés afin de définir le
domaine de l'évaluation.

Les événements dangereux identifiés comme étant dans le domaine de l'examen étaient les suivants:
[1] Course aberrante : Une course non amorcée se produit, qui ne peut pas être évitée
en obscurcissant la protection photoélectrique (désignée comme une course non
protégée).

[2] Fonction incorrecte d’inhibition : La position de la fonction d’inhibition change de

manière anormale si bien que la fonction d’inhibition de la protection
photoélectrique s'active lorsque l'outil se trouve à plus de 6 mm au-dessus de la
pièce ou lorsque la défaillance de la protection se produit en mode non sécurisé
"mode dangereux".

[3] Panne du verrouillage de la porte logique arrière. Si ce verrouillage devait être en

panne, il serait possible d'accéder à l'arrière des parties travaillantes de la machine.

L'exercice de validation a été réalisé de manière séparée pour chaque norme avec l'intention de
minimiser les "incohérences" entre les examens respectifs.

Afin de faire en sorte que l'exercice soit le plus réaliste possible, il a été décidé d'adopter une
approche, aussi proche que possible, qui suivrait ce que l'on attend d'un concepteur de machine face
à l'utilisation des normes dans un environnement de travail (c'est-à-dire pas nécessairement comme
les concepteurs des normes l'auraient prévu).

4.3.3 Points découlant de l'application de EN 954-1

[1] La norme est censée s'appliquer au cours de la conception d'un système de

commande et non au cours de l'exercice de validation. En conséquence, certaines
étapes de la méthodologie n'étaient pas appropriées. Pour atteindre une sécurité
adéquate en utilisant la norme EN954, il faut donner des conseils sur la validation.

[2] Lorsque la norme ne donne pas de directions pour la validation, d'autres approches
peuvent être prises en compte pour suivre le processus de validation du début à la
fin. Il y a un grand nombre d'exigences mineures et de "renonciations". Par
exemple, les exigences fondamentales des diverses catégories sont simples à suivre
et font référence à la tolérance aux défauts.
Cependant, après avoir établir les exigences pour la catégorie 3, on remarque qu'il
n'est pas nécessaire de détecter TOUS les défauts uniques mais seulement
CERTAINS. Il faut prendre une décision subjective quant aux défauts qui doivent
ou ne doivent pas être détectés.
[3] La norme EN 954-1 a été conçue comme une norme avec un moyen pratique
d'évaluation et de mise en œuvre. Malheureusement, ce qui semble à première vue
être une méthode très pratique (c'est-à-dire basée sur une simple analyse de la
tolérance aux défauts) devient très subjective en pratique.

- 75 -
 L'Annexe B de la norme EN 954-1 est la seule manière de déterminer la catégorie
requise pour un système, en dehors de l'examen d'un système existant. A cause de
la nature subjective de l'Annexe B, différents évaluateurs peuvent arriver à
différentes conclusions en déterminant la catégorie puisqu'il n'y a pas de moyen
absolu de déterminer objectivement la catégorie requise pour un système
particulier.
On aurait pu donner des conseils plus détaillés aux utilisateurs de cette annexe. Par
exemple, la recherche aurait pu établir la probabilité pour l'opérateur d'éviter les
dangers dans une variété d'applications industrielles et sous des conditions
variables, ainsi que les données présentées sous forme de tableaux dans la norme.
Pour atteindre une réduction de risques donnée, il faudrait conduire une
considération plus étroite des pannes/défauts systématiques, du MTTFd , de la
couverture de diagnostic et des pannes de cause commune.
[4] Les principes de la norme EN 954-1 sont basés sur des pannes de composants
uniques/multiples conduisant à la réalisation d'un danger. Ceci, à première vue,
semble être une manière très simple de définir l'intégrité des fonctions de sécurité.
Cependant, l'examen du système de commande indique qu'il existe de nombreuses
pannes de composants qui, en combinaison, pourraient conduire au danger.
Cependant, la plupart de ces pannes sont considérées improbables, très
improbables, voire incroyables et pourraient être très différentes en utilisant
différentes technologies. Parce que la décision d'exclure de telles pannes de
l'analyse peut être une tâche subjective, il est recommandé, lorsqu'ils sont connus,
de considérer les taux de pannes à partir des bases de données ou de l'expérience
pratique. Ceci aidera à minimiser la subjectivité dans la validation.

[5] EN 954-1 ne donne pas de moyen d'évaluer ou d'assurer l'intégrité des logiciels.

[6] Pour justifier que la presse a été conçue en utilisant les principes de la norme
EN 954-1 et validée conformément à ses spécifications de sécurité, un rapport de
validation et le dossier de construction technique doivent être mis à la disposition
de l'évaluateur.

[7] EN 954-1 mentionne la maintenance mais ne le fait que très faiblement. Dans tout
système de protection lié à la sécurité (qui peut n'être appelé à fonctionner que de
manière peu fréquente), la conduite régulière de tests d'épreuve manuels (en
l'absence de diagnostic automatique) est un facteur important pour maintenir
l'intégrité, qui variera de manière à peu près linéaire avec la fréquence des
vérifications de contrôle manuelles. Dans le secteur des machines aujourd'hui, une
telle approche est rarement suivie.

[8] EN 954-1 est une norme de conception et ne donne donc pas de conseil sur la
fabrication du système conçu. Un système bien conçu qui est mal fabriqué pourrait
avoir une intégrité réduite. Par exemple, un système à voies multiples, dont le
câblage a été isolé afin d'éviter des pannes de cause commune, pourrait avoir le
câblage fuselé en une gaine isolante unique, provoquant un potentiel de pannes de
cause commune. On a noté que l'étape de validation, c'est-à-dire les tests du type,
ne pouvaient prévoir des variations entre les articles fabriqués résultant, par
- 76 -
 exemple, d'une étape de fabrication mal spécifiée. Il est essentiel que le système
qualité de l'usine assure l'absence d'altération de l'échantillon de test approuvé.

[9] En supposant que des sous-systèmes sont des composants uniques et en appliquant
le principe d'exclusion des défauts, il est possible de déterminer une catégorie sans
avoir recours aux calculs complexes. Cependant, le taux de panne d'un sous-
système complexe peut être considérablement supérieur à que celui d'un composant
unique. La catégorie d'un sous-système à voies doubles ne peut être considérée
comme équivalente à un système à voie double au niveau des composants, par
exemple, un verrouillage basé sur 2 relais ne peut être comparé à un verrouillage
basé sur 2 contrôleurs logiques programmables complexes (PLC), même si les
deux verrouillages atteignent la catégorie 3. Ainsi, deux systèmes ayant chacun la
même catégorie peuvent être considérés comme équivalents seulement s'ils
utilisent la même technologie et un nombre de composants comparables.

[10] Un certain nombre de facteurs altérera considérablement la hiérarchie des

catégories6 . Par exemple :

 la norme se base sur un comportement du système en présence de défauts. La

technologie moderne permet l'incorporation de diagnostics automatiques
sophistiqués dont la couverture avoisine 100 %. Un système à voie unique avec
des diagnostics sophistiqués peut avoir une intégrité supérieure à un système à
voies multiples sommaire. Bien que la norme permette l'exclusion de défauts, elle
ne donne pas de conseils quant à la manière dont ce problème doit être abordé.

 un système extrêmement fiable, basé sur une technologie simple (par exemple, une
barre de blocage mécanique), auquel, à cause de son statut à voie unique, on
assignerait une catégorie 1 peut, en pratique, avoir une intégrité comparable, ou
même supérieure, à celle d'un système de catégorie 4 employant une technologie
complexe et donc difficile à valider.
La possibilité d'effectuer une évaluation trompeuse peut être minimisée en
considérant des aspects probabilistes pour estimer le montant réel de la réduction
des risques.

4.3.4 Points découlant de l'application de la norme IEC 61508

[1] Le premier obstacle, et sans doute le plus important, en utilisant la norme

IEC 61508 impliquait la détermination de ce qu'est un niveau de risque acceptable.
Ceci peut nécessiter un processus itératif afin d'obtenir une valeur acceptable, qui
dépendra d'un certain nombre de facteurs, comme :

 ce qui a pu être établi comme bonne pratique technologique habituellement

reconnue dans l'industrie concernée ;

 la rentabilité de l'amélioration de la sécurité au-delà d'un niveau particulier (par

exemple, la loi de diminution des retours") ; et

6
Bien que la norme affirme clairement le contraire, il semble inconcevable que la hiérarchie n'ait pas été développée sur la base de l'existence d'une relation
monotone entre l'intégrité des composants liés à la sécurité et la Catégorie.

- 77 -
  ce que des concurrents et d'autres organisations utilisant des types d'équipements
similaires ont considéré praticable.
Les taux d'accidents existants impliquant des presses (obtenus de sources internes
au HSE), bien qu'incomplets, ont été utilisés dans cet exercice de validation pour
établir un niveau de risque acceptable. De telles informations ne seront pas faciles à
obtenir par les intervenants en charge de la conception et de la validation dans le
domaine des machines et d'autres méthodes peuvent être plus appropriées.
En outre, il peut être peu judicieux dans certaines circonstances de citer des taux
acceptables ou tolérables d'un niveau particulier d'accidents corporels. Il peut donc
s'avérer nécessaire pour des SIL cibles d'être déterminés par des moyens opaques,
éventuellement qualitatifs, pour les divers secteurs d'industrie. La détermination de
SIL cibles est une tâche sensible et pas nécessairement facile qui serait
considérablement facilitée par la disponibilité d'une méthodologie adaptée,
éventuellement spécifique à une industrie, pour la traiter. Il peut être nécessaire,
dans la première affectation d'un SIL, de considérer tout l'éventail de SIL possibles.
[2] La norme IEC 61508 semble avoir été conçue en vue des industries de procédé. En
conséquence, la détermination de SIL dépend de la réduction de risques fournie par
des systèmes de protection liés à la sécurité qui opèrent en parallèle avec le
système de contrôle de l'EUC et mettent l'EUC dans un état de sécurité si une
panne du système de commande se produit. Un état de sécurité peut donc être la
continuation du processus, alors que dans le secteur des machines, l'état de sécurité
est habituellement l'arrêt des mouvements dangereux.
De nombreux systèmes de commande des machines se basent traditionnellement
sur une technologie de relais, et puisque les machines sont surtout cycliques dans
leur fonctionnement, il est possible de tester la plupart, voire tous les composants
individuels dans un système de commande à tous les cycles de la machine et
d'employer la redondance. Ceci conduit à une tolérance aux défauts de 1, ou plus,
avec un intervalle court entre les tests et, en conséquence, les systèmes de
commande ont une intégrité élevée.
Donc, dans le cas des fonctions de sécurité de nombreuses machines, le concept de
réduction des risques, tel qu'utilisé dans IEC 61508, est inapproprié et un SIL doit
être calculé à partir du taux de panne du système de commande.
[3] Parce que la norme IEC 61508 est récente (non publiée sous forme finale au
moment de l’évaluation) peu de fabricants, s'il s'en est trouvé, l'ont utilisée. Ainsi, il
était difficile pour le fabricant de la presse examinée de fournir la documentation
préparée pour prouver la conformité à IEC 61508. Ceci était particulièrement vrai
en ce qui concerne les procédures de qualité utilisées dans la conception de la
machine. Cette documentation est nécessaire ; sans quoi, il n'est pas possible de
déterminer si les exigences de qualité ont été satisfaites dans la conception. Il est
important d'effectuer toutes les évaluations au cours de toutes les étapes du cycle
de vie.

Il est recommandé que la documentation formelle et détaillée pour l'installation, la

mise en service, l'exploitation et la maintenance soient fournies par le fabricant. Les

- 78 -
 documents traitant des procédures de conception, par exemple, l'assurance qualité,
doivent être mis à la disposition de l'évaluateur pour la validation. Ceci est
nécessaire pour tous les systèmes quelle que soit leur origine.

[6] Pour une évaluation quantitative, de bonnes données de taux de panne sont
nécessaires. Les données sont disponibles sur les modes de défaillance les plus
fréquemment rencontrés de la plupart des composants, par exemple, incapacité
d'excitation d'un relais. Cependant, dans des systèmes liés à la sécurité, de
nombreux composants sont testés automatiquement pour s'assurer que les modes
de défaillances fréquemment rencontrés sont révélés. Donc, les modes de
défaillances restants, sur lesquels les données sont probablement insuffisantes (par
exemple, la panne d'un contact à relais unique ou un relais passant spontanément
de l'état non excité à l'état excité en conséquence, par exemple, de la rupture d'un
ressort), sont ceux qui posent problème. Il peut être utile d'utiliser l'expérience
d'applications dans d'autres secteurs pour réaliser des estimations plus
représentatives de ces données.

[7] Afin de déterminer la probabilité d'accident corporel si la fonction de sécurité

pertinente devait tomber en panne, un certain nombre d'hypothèses doivent être
avancées. Par exemple, dans le cas d'un événement dangereux 1, on supposait que
l'opérateur plaçait ses mains dans la presse une fois par minute. Une hypothèse
différente modifierait le SIL cible et la validation. Une conception idéale serait que
les mains de l'opérateur ne soient JAMAIS placées dans la presse, mais ceci est
souvent impossible.

[8] Comme le résultat de l'analyse quantitative utilisant IEC 61508 dépend

probablement d'un certain nombre d'hypothèses extrêmement subjectives, il sera
possible de personnaliser le résultat de l'analyse pour qu'il convienne à ses propres
besoins particuliers. Certaines de ces hypothèses seront difficiles à remettre en
cause. L'utilisation de l'expérience d'applications dans d'autres secteurs peut
améliorer ces hypothèses.

[9] Toutes données de taux de panne utilisées doivent avoir un niveau de confiance
statistique d'au moins 70 %. Ce niveau de confiance ne sera probablement pas
réalisé en pratique, pour les raisons décrites dans le paragraphe précédent. En
pratique, mieux vaut utiliser les meilleures données disponibles que ne pas effectuer
d'évaluation de fiabilité quantitative ; si nécessaire, des hypothèses basées sur le
pire des cas pourraient être avancées.

[10] Les intervalles de test hors ligne utilisés dans l'exercice de validation étaient basés
sur les recommandations du fabricant. Ces informations importantes doivent
toujours être disponibles, peut-être par étiquetage direct sur les machines.

[11] À première vue, les exigences de documentation de IEC 61508 semblent

écrasantes. Cependant, ceci n'est pas nécessairement le cas. Ce que la norme
demande, en fait, c'est que le développement, etc. soit décomposé en étapes
discrètes (c'est-à-dire le cycle de vie), qu'on accorde une attention particulière à
chacune de ces étapes, et que les résultats soient reportés sur papier pour
utilisation à des étapes ultérieures et pour démontrer que le système est adéquat.
- 79 -
 Considéré sous cet angle, le cycle de vie de la norme IEC 61508 n'est pas différent
de tout autre processus bien organisé. Les exigences de documentation
s'accroîtront clairement avec la complexité du système.

[12] L'application d'une analyse des risques quantifiée aux machines est plus complexe
par rapport à son application à des commandes automatiques de procédés
industriels à cause des interactions synchrones entre les personnes en danger, les
systèmes de commande et la nature cyclique du fonctionnement de la machine.
Dans de telles situations, un calcul (par exemple de la probabilité de panne à la
demande) impliquant des conditions en condition stable comme celui qui serait
applicable au système de commande d'une installation de traitement, ne sera sans
doute pas réaliste. Au contraire, le minutage des tests automatiques et des périodes
de risque élevé par rapport au cycle de la machine doit être considéré en détail dans
ces calculs.

[13] Une compréhension complète de l'exploitation du système est nécessaire pour que
la validation ait un sens. Ceci est vrai d'une évaluation effectuée en utilisant soit
EN 954-1, soit IEC 61508 ; cependant, dans le cas de cette dernière, où une
analyse quantitative est effectuée, de grandes variations dans le taux de panne
calculé pourraient résulter d'erreurs mineures dans la détermination des
fonctionnalités.

[14] À première vue, l'utilisation des contraintes d'architecture sur l'intégrité de sécurité
du matériel semble avoir un certain nombre de défauts, par exemple :

 la couverture de diagnostic (fraction de sécurité intrinsèque) est utilisée comme

paramètre pour déterminer le SIL ; cependant, dans le cas de diagnostics
automatiques, la vitesse à laquelle les diagnostics sont effectués est ignorée ;

 la couverture de diagnostic peut ne pas être pertinente dans le calcul de la

contrainte d'architecture ; en fait, ce qui peut être le plus important, par exemple,
est de savoir si la sortie PES utilisée par la fonction est surveillée ;

 on ne prend pas en compte le fait que certains systèmes à voie unique puissent être
intrinsèquement fiables et qu'ils se conduisent donc aussi bien qu'un système à
voies multiples ;

 la fraction de sécurité intrinsèque pour un composant unique (par exemple, une

cale mécanique) peut être encore plus difficile à déterminer que la couverture de
diagnostic d'un système programmable ;

 tout ce à quoi la couverture de diagnostic pourrait conduire (en supposant une

fréquence de répétition appropriée) est une réduction effective du taux de panne.
Donc, un système ayant un taux de panne de 1 sans diagnostic n'est pas différent
dans les faits d'un système ayant un taux de panne de 1 et une couverture de
diagnostic de 99 % ; cependant, le premier serait sévèrement pénalisé par la
contrainte d'architecture ; et

 on ne prend pas en compte les vérifications de contrôle manuelles.

- 80 -
 Cependant, les contraintes d'architecture doivent être considérées comme un
moyen de s'assurer que l'analyse quantifiée n'a pas été utilisée de manière abusive
ou erronée. Par exemple, dans le cas des calculs pour cette presse :
 un certain nombre d'hypothèses ont été avancées ;

 les calculs sont inexorablement liés à l'architecture, l'auto-surveillance et l'opération

cyclique de la presse ; et

 le manuel pour la presse indique qu'un contrôle quotidien doit être effectué sur le
verrouillage de porte logique arrière. La fréquence de ce contrôle aura un impact
considérable sur l'intégrité du verrouillage. Si aucun contrôle n'était effectué en
pratique, l'intégrité réelle (et non celle calculée) du verrouillage serait
considérablement réduite.
Des contraintes d'architecture sont censées appliquer un plafond sur le SIL qui
peut être affecté à tout système particulier afin d'empêcher toute mauvaise
utilisation involontaire (ou délibérée) de l'analyse quantitative. En conséquence, les
contraintes d'architecture garantiront que le niveau d'intégrité ne peut être
significativement augmenté au-delà du niveau réellement réalisable pour tout
système particulier. Ceci empêchera qu'on n'avance des SIL augmentés et, en
conséquence, assurera le maintien d'un niveau de sécurité approprié.
[17] L'utilisation des Tableaux 2 et 3 de la Partie 2 de IEC 61508 pour combiner les
contraintes d'architecture de plusieurs sous-systèmes nécessite des clarifications.

4.4. Conclusions de l'exercice de validation du système de commande

[1] Les systèmes de sécurité actuels des machines ne sont pas développés à partir de
rien. Au contraire, au cours du développement d'une nouvelle machine, l'expérience
gagnée de machines précédentes est légèrement modifiée pour apporter des
améliorations à la conception globale. Donc, des exigences de sécurité ont peu de
chances d'être développées pour une machine spécifique. Les systèmes de sécurité
de nouvelles machines seront conçus pour ne pas être pires que ceux de machines
existantes. L'utilisation de la norme IEC 61508 nécessitera un changement radical
du processus de conceptions/développement des machines dans le sens où la
sécurité doit être abordée en utilisant une approche absolue plutôt que relative.

[2] La norme IEC 61508 utilise un calcul quantitatif du taux de panne global, ainsi que
des techniques qualitatives pour déterminer le niveau d'intégrité de sécurité. La
norme EN 954-1 tente d'éviter le calcul quantitatif en utilisant une méthodologie
simple - le graphique de risques. Malheureusement, l'application de la
méthodologie n'est utilisable que dans les systèmes les plus simples, et nécessite
l'application subjective d'une connaissance d'ingénierie.

[3] IEC 61508 couvre toutes les étapes du cycle de vie d'un système. EN 954-1
considère seulement la conception (et la validation de la conception).

- 81 -
[4] Le problème le plus important en utilisant une approche quantitative de l'évaluation
des risques, telle que décrite en la norme IEC 61508, est la disponibilité de données
appropriées. Deux types de données sont nécessaires :
 Données de taux de panne pour les composants et les sous-systèmes. Il peut être
nécessaire d'utiliser des données à partir de composants génériques ; cependant,
des données peuvent être obtenues (ou estimées) pour la plupart des composants,
bien qu'il soit probable que quelques hypothèses soient nécessaires.

 Niveaux de risque acceptable. Le niveau de risque acceptable est un paramètre

social et difficile à déterminer étant dépendant du risque perçu, plutôt que réel. Les
directions de la norme IEC 61508 utilisent la valeur ALARP mais n'aident pas à
déterminer ce que cette valeur devrait être. La norme a avancé l'hypothèse que des
taux de danger existants étaient acceptables mais cette hypothèse doit être valable
dans tous les cas. Elle considère que ce problème peut présenter le plus de
difficultés dans l'utilisation de la norme IEC 61508 jusqu'à ce que des documents
de directions spécifiques à une industrie, basés sur la norme IEC 61508,
fournissent des directions dans ce domaine. Cependant, la publication de telles
directions pourrait alerter les industries à risque.

[5] Il fallait avancer un certain nombre d'hypothèses afin d'effectuer l'analyse

quantitative décrite dans la norme IEC 61508. Celle-ci était subjective et avait un
effet significatif sur les SIL. Il peut y avoir une forte dépendance sur des
hypothèses basiques (et éventuellement subjectives) dans l'analyse quantitative de
nombreux autres systèmes. Certaines de ces hypothèses seront difficiles à remettre
en cause et pourraient conduire à des prédictions de taux de panne altérées pour
répondre aux besoins d'autres ordres du jour.

[6] Si une méthodologie permettant aux SIL cibles d'être déterminés sans subjectivité
significative n'est pas disponible, l'incertitude du résultat de l'analyse quantitative
utilisée dans la norme IEC 61508 peut être grande. Il faut donner une priorité
absolue à la production d'une telle méthodologie, sans quoi il ne sera pas possible
d'exploiter complètement les directions fournies par la norme IEC 61508.

[7] En général, les systèmes de commandes électriques liés à la sécurité existants pour
les machines n'ont pas été conçus en utilisant les directions contenues dans la
norme IEC 61508 (dont toutes les parties n'étaient pas publiées au moment de la
rédaction du présent rapport) et, en conséquence, la documentation convenable,
nécessaire afin de vérifier les diverses étapes du cycle de vie de sécurité, n'est sans
doute pas disponible. La documentation, sous forme convenable à des fins
d'évaluation sera disponible seulement lorsque la norme IEC 61508 gagnera en
crédibilité dans la fabrication de machines. Jusque là, il sera difficile d'effectuer des
évaluations de systèmes de commande électriques liés à la sécurité pour les
machines, en particulier par rapport à l'analyse quantitative.

[8] La norme IEC 61508 oblige le fabricant de planifier le cycle de vie global de
manière structurée en exigeant une documentation adéquate. À première vue, les
exigences de documentation pour un système simple de commande des machines
semblent excessives.

- 82 -
 [9] Parce que le manque/l'incompatibilité des documents peut empêcher une
détermination adéquate des mesures qualitatives lorsqu'un examen rétrospectif est
effectué sur une machine conçue avant la publication de la norme IEC 61508, il ne
sera pas possible de déterminer si des mesures convenables ont été mises en place
(ou pas) pour traiter des pannes systématiques. Une évaluation quantitative
rétrospective utilisant la norme IEC 61508 peut donc s'avérer inexacte puisque le
taux réel de panne peut être dominé par des pannes systématiques, qui ne peuvent
probablement pas être prédites quantitativement. Malheureusement, ceci conduira
à une sous-estimation du taux de panne, c'est-à-dire que l'estimation indiquera
qu'un système est plus sûr qu'il ne l'est réellement.

[10] La norme IEC 61508 suit une approche scientifique en faisant correspondre
l'intégrité du système au risque. Elle utilise également, chaque fois que cela est
possible, une quantification mais reconnaît qu'il est possible de suivre des mesures
qualitatives lorsque des mesures quantitatives ne peuvent être utilisées. Cependant,
les mesures qualitatives ont été déterminées (en utilisant un jugement d'ingénierie)
pour être appropriées au SIL. Ceci doit être comparé à l'approche suivie par la
norme EN 954-1, qui est basée sur la tolérance aux défauts.

[11] Les principes de IEC 61508 exigent que la méthodologie suivie comprenne toutes
les phases du cycle de vie d'un système, par exemple, concept, conception, mise en
œuvre, etc. Si la méthodologie n'a pas été utilisée par le fabricant, une évaluation
ultérieure utilisant IEC 61508 sera inévitablement difficile à cause des informations
manquantes. Cependant, si IEC 61508 avait été suivie dès le départ, les
informations pertinentes seraient disponibles, facilitant la validation.

4.5. Techniques et mesures pour la validation de machines

Les découvertes et conclusions mentionnées ci-dessus indiquent comment résoudre certaines des
difficultés pratiques que l'on peut rencontrer en utilisant les normes EN 954 et IEC 61508. Ces
problèmes, dérivés des divergences qui existent entre les normes EN 954 et IEC 61508, nécessitent,
afin d'établir une base saine pour la validation des systèmes de commandes liés à la sécurité dans les
machines, que l'on considère les points suivants :
 Un correspondance linéaire des niveaux d'intégrité de sécurité de la norme IEC 61508 avec
les catégories de la norme EN954-1 ne pouvait être établie. Ceci était avant tout dû au fait
que les définitions de catégorie de la norme EN954-1 ne plaçaient pas d'exigences
quantifiables concernant les taux de panne des fonctions de sécurité.
Cependant, on peut affirmer que, dans une technologie donnée, la catégorie 1 aura
probablement un niveau d'intégrité de sécurité supérieur à la catégorie B et la catégorie 4
aura le niveau d'intégrité de sécurité le plus élevé.
 L'approche qualitative de la norme EN 954-1 est souhaitable du point de vue du secteur des
machines.

- 83 -
 Les principes de la norme IEC 61508 (cycle de vie de sécurité et niveaux d'intégrité de
sécurité) peuvent être appliqués aux systèmes de commande E/E/PE dans les machines.
IEC 61508 pourrait compléter la norme EN 954-1 pour les systèmes E/E/PE, mais une
approche qualitative conduisant à un niveau d'intégrité de sécurité devrait être développée.

 La structure non hiérarchique des catégories de la norme EN 954-1 est souvent mal
interprétée en une structure hiérarchique. Ceci est dû au fait qu'il faut analyser avec
attention les définitions de catégories pour comprendre leur signification complète. Une
annexe informative interprétant les catégories pour différentes technologies peut être utile.

 Bien que lesdites catégories soient difficiles à associer au risque, la norme EN 954-1, en tant
que document, fournit des informations extrêmement utiles pour des stratégies de
conception pour la sécurité et les exigences pour les fonctions de sécurité.

 La norme IEC 61508 couvre toutes les phases de la vie d'un équipement, du concept
jusqu'au déclassement des installations. Dans le secteur des machines, il est très rare qu'une
seule partie soit responsable sur tout le cycle de vie. On considère qu'il est nécessaire de
délimiter les responsabilités. Ceci est particulièrement vrai dans le cas de fabricants qui
produisent des machines ou des composants de sécurité pour utilisation dans diverses
applications où il peut ne pas être pratique pour le fabricant d'entreprendre une analyse
complète des dangers et des risques et d'identifier des fonctions de sécurité convenables
pour toutes les applications à une étape précoce dans le cycle de vie de sécurité. Dans de
tels cas, il faut mettre l'accent sur les fabricants pour qu'ils fournissent des informations
convenables et suffisantes (y compris le SIL) afin que les utilisateurs puissent correctement
prendre en compte les caractéristiques de performance de l'équipement dans l'application
finale.

 Les intervenants en charge du développement et de la validation doivent avoir une

considération plus profonde de l'aspect systématique du système de commande des
machines.

- 84 -
5. MANUEL UTILISATEUR

5.1. Méthodologie de validation pour les SRCES

Pour traiter de la validation des SRCES7, il faut traiter les étapes de fonctionnement dans l'ordre
recommandé des opérations comme suit :
 Obtenir l'affectation d'exigences de sécurité. Mettre à jour la planification de sécurité
comme approprié au cours du développement des SRCES.

 Déterminer les exigences pour les SRCES, y compris les exigences d'intégrité de sécurité,
pour chaque fonction de sécurité. Affecter les exigences aux logiciels

 Démarrer la phase de planification pour la validation des SRCES.

8
 Accéder à l'architecture (configuration) pour le système logique des SRC , capteurs et
éléments finaux.

 Passer en revue avec le développeur/fournisseur de logiciels l'architecture matérielle et

logicielle et les applications de sécurité des compromis techniques entre le matériel et les
logiciels. Recommencer si nécessaire. La méthodologie pour la validation des logiciels est
divisée en six niveaux principaux:
 La première étape est de s'assurer que les spécifications logicielles sont conformes aux
besoins de l'utilisateur et aux exigences de sécurité. S'assurer que toutes les informations
nécessaires pour les fonctions sont complètes, précises, explicites, cohérentes et
correctes.
 Le second niveau d'évaluation correspond au passage des spécifications au code final en
passant par la conception de logiciels ; le code final doit être conforme aux
spécifications logicielles.
 Le troisième niveau d'évaluation, correspondant au passage du code final au
comportement logiciel, consiste en l'exécution du code final pour vérifier le
comportement logiciel.
 Le quatrième niveau d'évaluation consiste à s'assurer que le code final est conforme aux
besoins de l'utilisateur. Pour les mêmes raisons que celles exprimées pour le premier
niveau d'évaluation, qui sont intrinsèques à la nature des besoins de l'utilisateur, cette
conformité est très difficile à démontrer.
 Le cinquième niveau d'évaluation, correspondant au passage des spécifications au
comportement logiciel, consiste en la vérification de la conformité du comportement
logiciel avec ce qui est décrit dans les spécifications. Cette activité était auparavant
appelée vérification.
 Enfin, le sixième niveau représente l'activité de validation totale.

7
SRCES « Safety-Related Complex Electronics Systems » : systèmes électroniques complexes liés à la sécurité
8
SRC « Safety-Related Components » : composants liés à la sécurité

- 85 -
 Développer un modèle pour l'architecture matérielle dédiée aux systèmes liés à la sécurité.
Développer ce modèle en examinant chaque fonction de sécurité séparément et déterminer
le sous-système (composant) qui sera utilisé pour effectuer cette fonction. Des analyses
déterministes et probabilistes sont nécessaires.

 Pour l'analyse déterministe, deux méthodes sont généralement employées pour prédire des
défauts de mode commun :
 Analyse par arbre de défauts (FTA), cette méthode déductive débute d'une panne
dangereuse du système, déterminée par exemple par une analyse des risques, et cherche
des combinaisons d'événements qui ont pu conduire à cette panne. Elle révèle les défauts
aléatoires, systématiques et de mode commun. Au final, toutes les branches logiques
d'une FTA doivent être développées jusqu'aux événements de base. En pratique, on
développe l'arborescence afin d'être capable d'analyser l'effet de pannes d'entrée, de
traitement et de sortie.
 Analyse des modes de défaillances et de leurs effets (AMDE). Il s'agit d'une méthode
inductive qui démarre des pannes des fonctions ou composants du système à analyser
afin de déterminer les pannes dangereuses qui pourraient l'affecter. Elle souligne les
pannes dues à des modes de défaillance uniques qui affectent les logiciels ou le matériel.
 Utiliser une AMDE et des modèles Markov pour une approche probabiliste. Ces techniques
ont été choisies grâce à leur capacité considérable à gérer de nombreuses caractéristiques
techniques habituellement mises en œuvre dans les dispositifs de sécurité modernes. En
particulier avec la modélisation Markov, des événements périodiques comme des tests en
ligne peuvent être modélisés assez facilement.

 Définir les paramètres de système pour chaque composant utilisé dans les systèmes
électroniques complexes liés à la sécurité. Pour chacun des composants, déterminer les
points suivants :
 le temps moyen de restauration ;
 la couverture de diagnostic ; et
 la probabilité de panne.
 Créer un modèle de fiabilité pour chacune des fonctions de sécurité que le SRCES est censé
effectuer.

 Mettre en œuvre la conception des SRCES. Sélectionner des mesures et des techniques
pour contrôler les pannes matérielles systématiques, les pannes provoquées par des
influences d'environnement et les pannes d'exploitation.

 Intégrer les logiciels contrôlés sur le matériel cible et, en parallèle, développer les
procédures que les utilisateurs et le personnel de maintenance devront suivre lors de
l'exploitation du système.

- 86 -
  Avec l'intervenant en charge du développement logiciel, valider les SRCES. Le but de la
validation de sécurité est de vérifier que tous les composants liés à la sécurité du système
respectent les spécifications pour les exigences de sécurité. La validation de sécurité est
effectuée en fonction du plan de validation de sécurité. En conséquence de la validation de
sécurité, il est possible de conclure que le système lié à la sécurité respecte les exigences de
sécurité puisque toutes les exigences de sécurité sont validées. Lorsque des divergences se
produisent entre les résultats attendus et réels, il faut décider si l'on doit émettre une
demande de modification du système ou des spécifications et des champs d'application
correspondants éventuels. Il faut également décider si l'on doit continuer et effectuer les
modifications nécessaires plus tard, ou si l'on doit effectuer les modifications immédiatement
et reprendre le processus de validation à une phase antérieure.

Enfin, les SRCES doivent également être conformes aux exigences de sécurité génériques :
 Sécurité électrique.

 Compatibilité électromagnétique : la sensibilité et le rayonnement sont requis par la directive

européenne EMC.

 Contraintes climatiques et mécaniques.

 Gestion de la qualité en production, domaine de test et gestion des révisions. Ceci est
particulièrement important pour des systèmes basés sur des logiciels.

 Etc.

5.2. Ce à quoi nous ne pouvons pas répondre

À partir de la recherche entreprise dans le projet STSARCES, certaines limitations, parfois

intrinsèques à la nature des problèmes abordés, doivent être résumées :
 Une correspondance fixe des niveaux d'intégrité de sécurité de la norme IEC 61508 avec les
catégories de la norme EN954-1, n'a pas pu être établie. Ceci est avant tout dû au fait que
les définitions de catégories de la norme EN954-1 ne placent aucune exigence quantifiable
concernant le taux de panne des fonctions de sécurité.

 La structure non hiérarchique des catégories de la norme EN 954-1 est souvent mal
interprétée en une structure hiérarchique. Ceci est dû au fait qu'il faut analyser les définitions
de catégories avec attention pour comprendre leur signification complète. Une annexe
informative interprétant les catégories pour différentes technologies peut être utile.

 Il existe une grande différence entre les pratiques de développement de logiciels et les
travaux théoriques qui traitent du sujet. Il est difficile d’appliquer des principes de sûreté de
fonctionnement pour des PME. Les restrictions d'organisation, et plus particulièrement le
manque de culture de sûreté de fonctionnement, compliquent énormément l'élaboration d'un
processus de sécurité d'exploitation. Il n'existe pas d'outils de spécification de sécurité
logicielle spécifiques pour des applications de petite taille.

- 87 -
 La norme IEC 61508 couvre toutes les phases de la vie d'un équipement, du concept au
déclassement des installations. Dans le secteur des machines, il est très rare qu'une seule
partie soit responsable du cycle de vie entier. On considère qu'il est nécessaire de délimiter
les responsabilités. Ceci est particulièrement vrai dans le cas de fabricants qui produisent des
machines ou des composants de sécurité pour utilisation dans diverses applications où il
peut ne pas être pratique pour le fabricant d'entreprendre une analyse complète des dangers
et des risques et d'identifier des fonctions de sécurité convenables pour toutes les
applications à une étape précoce dans le cycle de vie de sécurité. Dans de tels cas, il faut
mettre l'accent sur les fabricants pour qu'ils fournissent des informations convenables et
suffisantes (y compris le SIL) afin que les utilisateurs puissent prendre en compte
correctement les caractéristiques de performance des équipements dans l'application finale.

 Les composants complexes sont en fait si complexes qu'il est difficile de les analyser de
manière détaillée, et il est très difficile de prédire les modes de défaillance des composants.
Les programmes internes liés aux composants programmables peuvent également contenir
des erreurs sensibles. Toutes ces raisons provoquent une incertitude liée à l'analyse des
composants complexes. Un composant complexe unique seul ne peut commander une
fonction de sécurité de manière suffisamment sûre, et une certaine redondance, diversité
et/ou surveillance est nécessaire. Ceci signifie que l'architecture du système de commande
est d'importance capitale et qu'elle peut rendre les risques causés par des composants
complexes négligeables.

 La complexité croissante des nouveaux systèmes de sécurité (fonction intégrée, vitesse de

traitement, miniaturisation de la technologie d'assemblage et de composants, etc.)
complique énormément l'exécution de tests menés tardivement dans la conception (par
exemple, en validation). Des tests de structure ne parviendront pas à aller en profondeur et
seront de plus en plus souvent appliqués aux couches externes, ce qui suppose un processus
de "fonctionnalisation" ou un changement pour des tests plus fonctionnels. Ces obstacles
obligent à appliquer des techniques de conception qui facilitent les tests ultérieurs des
circuits et programmes (appelés techniques de testabilité) et des tests directs d'un domaine
physique à un domaine de simulation.
 L'injection de défauts physiques au niveau des broches de composants et des techniques
d'injection de défauts mises en œuvre par logiciel se sont avérées les techniques les plus
intéressantes pour l'injection de défauts dans des prototypes de systèmes électroniques
programmables. Chaque technique permet d'introduire un sous-ensemble de tous les défauts
potentiels dans un système, si bien que le testeur devra choisir la technique et planifier le
test correctement en fonction de l'ensemble spécifique de défauts à émuler. L'injection de
défauts mise en œuvre par logiciel apparaît comme une meilleure option pour émuler les
défauts internes précis et transitoires, alors que l'injection de défauts physiques au niveau
des broches permet d'émuler plus facilement des défauts de blocage au niveau de données,
lignes de commande et d'adresse. Cependant, il est difficile de dire dans quelle mesure une
technique couvre l'autre car la capacité d'émulation de défaut de ces techniques dépend
largement de la nature du système et de sa charge.

- 88 -
 Généralement, des systèmes de commande électroniques liés à la sécurité existants pour les
machines n'ont pas été conçus en utilisant les exigences contenues dans la norme IEC 61508
et, en conséquence, la documentation convenable, nécessaire à la vérification des diverses
étapes du cycle de vie de sécurité n'est probablement pas disponible. La documentation,
sous forme convenable à des fins d'évaluation, sera disponible uniquement lorsque des
normes dérivées IEC 61508, comme le projet de norme IEC 62061 gagneront en crédibilité
parmi les fabricants de machine. Jusque là, il pourrait être difficile d'effectuer les évaluations
des systèmes de commande électroniques liées à la sécurité des machines, en particulier en
ce qui concerne l'analyse quantitative. Ce rapport vise à encourager les fabricants à combler
ce vide dans un futur proche et à éditer la documentation pas à pas nécessaire au cours du
développement de nouveaux produits de sécurité.

- 89 -
6. CONCLUSIONS

Les objectifs du projet ont été plus que totalement remplis. Non seulement les résultats préliminaires
ont déjà été transférés à CEN/TC114 en 1999 afin d'accélérer les amendements de la norme
EN 954-1 et les améliorations du projet de norme EN 954-2, ce qui était l'objectif initial, mais des
outils essentiels basés sur la norme générique IEC 61508 ont été adaptés aux besoins spécifiques du
secteur des machines.

En conséquence directe, le projet plus récent de norme IEC 62061 en a également bénéficié. Une
contribution importante du projet traite de techniques de validation et de développement des logiciels
liés à la sécurité.

Une contribution majeure a introduit des techniques de modélisation et des méthodes d'évaluation
probabilistes des taux de pannes dangereuses et des architectures convenables pour réaliser une
réduction des risques. Les modèles de Markov sont une des techniques d'évaluation abordées au
cours du projet STSARCES. En ce qui concerne les tests en ligne effectués automatiquement dans
un système de sécurité, l'immense influence de la couverture de diagnostic pourrait être démontrée.
L'autre aspect est l'intervalle de test de diagnostic approprié pour l'architecture et l'application d'un
système particulier. La norme EN 954-1 ne fournit pas d'informations suffisantes sur ce sujet. Pour
un système de catégorie 2, il exige seulement des contrôles par le système de commande de la
machine "à intervalles convenables" sans expliquer ce que signifie "convenable". Les intervalles de
test de systèmes prétendant à une catégorie 3 ou 4 ne sont pas spécifiés non plus dans cette norme.

L'approche Markov peut fournir une aide. En mettant en œuvre une nouvelle caractéristique dans les
modèles Markov, nous avons pu fournir des informations utiles concernant l'intervalle de test de
diagnostic adéquat. Il est apparu que des systèmes à voie unique et des systèmes à voies multiples se
comportent de manière très différente.

Des découvertes intéressantes sont décrites, établissant une relation entre des taux de test en ligne
suffisants et le MTTFd d'une des voies redondantes. Elles fournissent des conseils au concepteur du
système ainsi que des pistes pour la personne effectuant l'évaluation.

Des liens complets pourraient également être établis entre le concept de catégorie (approche
EN 954) et les SIL (approche IEC 61508) pour des architectures données et des données de fiabilité
réalistes.

6.1. Contribution de STSARCES à EN 954

La norme EN 954-1 est constituée d’une partie normative (norme harmonisée depuis 1996), d'un
manuel utilisateur FD CR 954-100 (harmonisé en 1999), d'un projet de norme pr 954-2 (au niveau
d'une procédure d'enquête CEN) et d'un projet de révision de la norme EN 954-1.

- 90 -
Pendant les deux dernières années, au cours des réunions du Groupe de travail commun chargé de la
norme EN 954, les rapports intermédiaires de STSARCES ont été communément utilisés comme une
entrée importante lors de la rédaction d'une exigence ou d'une procédure de validation concernant
des fonctions de sécurité basées sur des PES.

Par manque de connaissances décisives, les experts de la norme EN 954-2 ont été amenés à
remarquer et à rédiger les points suivants :
 Dans des systèmes de commande où la fourniture des fonctions de sécurité comprend des
PES, il est inadapté d'utiliser seulement des catégories si :
 la fonction de sécurité du système de commande repose seulement sur des PES,
 ou la structure du système de commande est complexe,
 ou la contribution à la réduction des risques de la machine est élevée.

Dans ces cas, des facteurs supplémentaires, par exemple les défauts systématiques, doivent
également être pris en compte (dans le cadre de la norme EN 954-2).

 Dans une note, le CEN/TC 114-CLC/TC44X-JWG6 propose de traiter cette question à

travers l'amendement de la norme EN 954-1 (1996).

C'est au niveau de l'amendement de la Partie 1, que l'on attend impatiemment les résultats du projet
STSARCES parce que les aspects logiciels (défauts systématiques) doivent être introduits dans le
concept de catégories lorsque les PES sont en catégorie 2, 3 ou 4.

Il est également indiqué dans l'amendement qu'une application machine standard dérivée de la norme
IEC 61508 publiée est en cours de préparation par le IEC/TC 44/WG7 (ici le concept de base est le
Niveau d'intégrité de sécurité ou "SIL").

Les résultats de STSARCES permettront de définir des liens crédibles et compréhensibles entre
catégories (EN 954) et SIL dans le projet de norme IEC 62061. Cette connexion est indispensable au
cours des phases de conception et de développement de circuits de commande des machines qui
utilisent des composants mécaniques ainsi qu'hydrauliques ou pneumatiques et électromécaniques
basés sur le concept de catégorie, ainsi que des PES, mieux caractérisés par le concept de SIL.

Une partie des résultats du WP4 (une étude des liens et des divergences entre les normes IEC 61508
et EN 954, HSE, WP4 Tâche 1) a déjà été communiquée en 1999 au JWG6 et la présentation des
résultats WP2.1 est également attendue (Quantitative Analysis of Complex Electronic Systems using
Fault Tree Analysis and Markov Modelling, Analyse quantitative de systèmes électroniques
complexes utilisant une analyse par arborescence de défauts et une modélisation de Markov).

Les experts impliqués dans la normalisation sont convaincus que STSARCES améliorera les
méthodes de validation des PES dans leur utilisation pour des fonctions de sécurité à la fois dans la
norme EN 954 et dans le projet de norme IEC 62061.

- 91 -
 6.2. Contribution de STSARCES à IEC 62061

Des travaux pour développer la norme IEC 62061 “Safety of Machinery - Functional Safety of
Electrical, Electronic and Programmable control systems for Machinery” (Sécurité des machines –
sécurité de fonctionnement des systèmes de commande électriques, électroniques et programmables
pour les machines) ont été initiés en mars 1998 par le groupe de travail TC 44 WG7.

Une première version CD est attendue pour le second semestre de l'an 2000, un an après la date
prévue. Ce délai est largement dû à des difficultés dans l'interprétation de la norme IEC 61508 par
des personnes peu habituées à ces concepts, ainsi que la nécessité de prendre en compte les deux
normes en même temps, comme la norme IEC 61508 (approche probabiliste pour les dispositifs
CES) et la norme EN 954 (approche déterministe pour tous types de technologies).

Le but de ce travail est de développer une norme de secteur pour les machines, guidée par la
publication de sécurité de base, la norme IEC 61508. Cette norme définira une hiérarchie de niveaux
de performances de sécurité en :
 adaptant les exigences de la norme IEC 61508 pour qu'elles conviennent aux principes
établis d'évaluation des risques et d'intégration de sécurité des machines ; et en

 définissant la méthodologie pour la mise en œuvre de la norme EN 954 dans la hiérarchie

des niveaux de performance.

Cette norme est destinée à être utilisée par :

 les fournisseurs de machines, pour permettre la spécification des niveaux de performance
appropriés des systèmes de commande électriques, électroniques et programmables liés à la
sécurité utilisés sur une machine ; et par

 les concepteurs et intégrateurs de ces systèmes, pour leur permettre de respecter les niveaux
de performance spécifiés.

Jusqu'à présent, le travail vise à spécifier une méthodologie pour l'intégration de composants (déjà
certifiés précédemment) afin de développer des systèmes de commandes sûrs pour les machines. Les
exigences appliquées aux composants (par exemple cellule photoélectrique de sécurité) sont celles de
la norme IEC 61508.

Les résultats du projet STSARCES sont ici encore précieux si l'on considère les problèmes soulevés
par l'utilisation intégrée de concepts dérivés à la fois de la norme IEC 61508 et de la norme EN 954.

Plus récemment, en janvier 2000, un avant-projet du rapport WP sur les aspects logiciels (Software
quality and safety requirements, INRS, WP1.2, Aspect 1, exigences de sécurité et de qualité
logicielle, INRS, WP1.2, Aspect 1) a été transféré au groupe de travail avec pour intention
d'introduire les résultats en annexe à la norme, à l'attention des concepteurs des logiciels intégrés
utilisés dans les machines.

- 92 -
 6.3. Validation du projet par des fabricants externes

Un séminaire spécifique avec des fabricants de systèmes liés à la sécurité, non impliqués directement
dans le projet, pour les informer des résultats et améliorer l'intelligibilité de la présentation du rapport
final, a été programmé vers la fin du projet.

Afin d'assurer la plus large audience internationale à cet événement, ce séminaire a été intégré à la
conférence internationale la plus significative organisée fin 1999 sur la sécurité du travail, la
MONTREAL International Conference on Safety of Industrial Automated Systems (Conférence
internationale de MONTRÉAL sur la sécurité de systèmes automatisés industriels) du 4 au 7 octobre
1999. Ceci a été possible grâce au Conference Scientific Committee (Comité scientifique de
conférences) qui comprenait BIA, HSE et INRS, membres du Comité de direction de STSARCES et
IRSST, l'institution organisatrice.

Cinq communications sur les résultats du projet STSARCES ont été présentées par leurs auteurs en
sessions plénières (une vue d'ensemble par le coordinateur et quatre rapports techniques sur chaque
ensemble de travail). Puisque les présidents de séance correspondants étaient INERIS, BIA, HSE et
INRS, les discussions ont pu facilement être orientées pour ressentir l'acceptation des résultats
STSARCES par les fabricants présents.

Enfin, des discussions pouvaient suivre de manière plus informelle après les séances puisque la
plupart d'entre eux avaient leur propre stand dans l'exposition installée au même endroit. Il a été
convenu que l'approche par cycle de vie était bien reçue, mais un souci important a été exprimé sur
le besoin d'une collaboration plus profonde entre organismes de certification et fabricants dans un
futur proche, de l'étape de la conception jusqu'aux tests finaux en vue d'éditer un certificat de
conformité. Il existe un souhait similaire exprimé par les Stations de tests pour une collaboration plus
profonde, étendue sur tout le cycle du "processus de certification".

- 93 -
7. BIBLIOGRAPHIE

1 DIN V VDE 0801/01.90 and A1/10.94 : Grundsätze für Rechner in Systemen mit Sicherheitsaufgaben
und Änderung A1.
2
EN 954-1 (1996) : Safety of machinery - Safety-related Parts of control systems (Identical with ISO/IEC
DIS 13849-1).
3
IEC 61508 : Functional Safety-Related-Systems: Part 1 : General Requirements; Part 2 : Requirements
for electrical, electronic, programmable electronic systems; Part 3 : Software Requirements; Part 4 :
Definitions and abbreviations of terms; Part 5 : Guidelines for the application of part 1; Part 6 :
Guidelines for the application of part 2 and 3; Part 7 : Bibliography of techniques and measures.
4
DIN V 19250: Leittechnik. Grundlegende Sicherheitsbetrachtungen für MSR-Schutzein-richtungen.
Beuth-Verlag, Berlin 1994.
5
Reinert, D.; T. Bömer : Modern Sensors as protective devices for the safety of machinery. Proceedings
Volume 1 : 3rd Eurolab Symposium 5-7.6.1996 Berlin. Testing and Analysis for Industrial
Competitiveness and sustainable Development. Wirtschaftsverlag NW. Bremerhaven 1996, pp. 215-224.
6
Reinert, D.; Schaefer, M.: Integrated safety in flexible manufacturing systems. In R.D. Schraft, G.
Brandenburg, & W. Leidig, (Eds.), Tagungsband SPS/IPC/DRIVES98 (pp. 305-314). Heidelberg,
Germany: Hüthig-Verlag 1998.
7
Reinert, D. et al : Validation of functional safety of programmable electronic systems conformément à
IEC 1508. Preprints of the 5th International Working Conference on Dependable Computing for Critical
Applications, Sept. 27-29, 1995.
8
EN 1050 Sécurité des machines. Principes pour l’appréciation du risque. (Machine safety. Risk
appreciation principles). 1997-01.
9
FARADIP.THREE (Failure Rate and Failure Mode Data Bank and Failure Mode and Effect Analysis
Package). Technis, Tonbridge, Kent UK 1997.
10
SN 29500 Failure Rates of Components, Part 1 – 7, Part 9 – 10. Siemens AG, ZT TN Corporate
Functions Technical Regulation and Standardization, Munich and Erlangen 1982 – 1999.
11
DEPENDABILITY OF CRITICAL COMPUTERS SYSTEMS EWICS/TC7 Ed. F.J. Redmill - 1988.
12
Method for performing diversity and defense-in-depth analyses of reactor protection systems Preckshot
G.G. Fission Energy and Systems Safety Program, Rapport UCRL-ID-119239, Dec 1994.
13
HANDBOOK OF SOFTWARE RELIABILITY ENGINEERING Lyu M.R. Computing Mac Graw-
Hill/IEEE Computer Society Press, 1995.

- 94 -