Qualification des systèmes

programmés dans les centrales

par Alain LEGRAS

Ingénieur Arts et Métiers, Institut National Polytechnique
Directeur adjoint Division Énergie et Industrie à Sema Group
et Daniel QUENOT
Ingénieur de l’École Supérieure d’Électricité
Ingénieur d’études de sûreté et architecture des systèmes à Sema Group

1. Présentation .............................................................................................. BN 3 425 - 2

1.1 Particularité des centrales nucléaires ........................................................ — 2
1.2 Nature des systèmes programmés ............................................................ — 2
1.3 Objectifs de qualité des systèmes programmés....................................... — 3
2. Documents normatifs ............................................................................. — 3
2.1 Paliers français et RCC-E ............................................................................. — 3
2.2 Normes AIEA................................................................................................ — 4
2.3 Normes CEI .................................................................................................. — 4
2.4 Autres normes, travaux en cours ............................................................... — 5
3. Qualification des systèmes programmés. Pratiques ..................... — 5
3.1 Généralités ................................................................................................... — 5
3.2 Systèmes de protection .............................................................................. — 6
3.3 Automates de sûreté ................................................................................... — 9
3.4 Système de conduite du palier N4 ............................................................. — 11
3.5 Site de Kashiwasaki, Japon ........................................................................ — 14
4. Qualification des systèmes programmés. Tendances ................... — 14
4.1 Constructions nouvelles.............................................................................. — 14
4.2 Rénovations ................................................................................................. — 15
5. Conclusion ................................................................................................. — 15
Pour en savoir plus........................................................................................... Doc. BN 3 425

omme les autres secteurs industriels, les centrales nucléaires ont largement
C bénéficié de l’utilisation de moyens informatiques, et ce à tous les niveaux :
outils de conception, systèmes de protection et de contrôle-commande, outils de
suivi d’exploitation. Cet article traite de la qualité du logiciel des systèmes de
protection et de contrôle-commande des centrales nucléaires récentes.
Un paragraphe général permettra au lecteur d’appréhender le contexte d’utili-
sation du logiciel dans une centrale nucléaire, caractérisé par des contraintes de
sûreté et de disponibilité, des facteurs économiques, ainsi que par l’apport fonc-
tionnel permis par la technologie informatique.
Une deuxième partie présente les codes et normes qui président à l’élabora-
tion et à l’évaluation de la qualité des systèmes programmés.
Une troisième partie expose, pour chaque type de système, les caractéristi-
ques (choix techniques, pratiques) qui permettent d’obtenir la qualité adéquate.
Cette présentation est basée sur des exemples concrets de tels systèmes, dans
les centrales nucléaires françaises et étrangères.
Une dernière partie fait le point sur les tendances futures, extrapolées à partir
des études et des projets en cours.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Génie nucléaire BN 3 425 − 1
QUALIFICATION DES SYSTÈMES PROGRAMMÉS DANS LES CENTRALES
1. Présentation
1.1 Particularité des centrales nucléaires
« Une centrale nucléaire est destinée à fournir une énergie électri-
que compétitive dans le contexte économique actuel. Cependant,
elle contient des produits radioactifs qui présentent de ce fait un
danger pour l’environnement ». Cette phrase, extraite du mémento
de la sûreté nucléaire en exploitation, énonce assez bien les deux
principales contraintes, parfois divergentes, qui vont définir la
qualité nécessaire des systèmes programmés comme des autres
systèmes.
1.1.1 Sûreté nucléaire
L’application de la doctrine de sûreté nucléaire aux systèmes de
contrôle-commande des centrales françaises est présentée dans
l’article [BN 3 411]. On se reportera aussi à cet article pour la défini-
tion des niveaux de classement des équipements et des exigences
associées. Nous nous limitons ici au rappel succinct suivant :
— une étude déterministe de sûreté (prise en compte des acci-
dents « de dimensionnement », c’est-à-dire prévisibles à la concep-
tion) est effectuée. Elle est complétée par une étude probabiliste de
sûreté (prise en compte des accidents « hors dimensionnement »
c’est-à-dire les accidents autres ou combinatoires des précédents
pouvant avoir une influence sur la probabilité de fusion du cœur).
Ces études permettent d’identifier les équipements de contrôle-
commande impliqués dans la prévention ou la limitation des consé-
quences des accidents, leur fonction par rapport à la sûreté, et
d’attribuer à ces systèmes ce que l’on appelle un niveau de
classement ;
— les niveaux de classement définis pour le palier 1 450 MW des
centrales nucléaires françaises sont par ordre de sévérité décrois-
sante 1E, 2E, SH, IPS-NC (important pour la sûreté - non classé), NC
(non classé).
L’article [BN 3 411] présente aussi la démarche retenue pour le
réacteur européen du futur (EPR) conduisant à une découpe en qua-
tre catégories (E1A, E1B, E2, E3). D’autres référentiels (méthode de
classement et définition des exigences associées à ces classements)
existent, telle celle présentée dans la norme CEI 1226 [1] ou celle
imposée par la NRC aux États-Unis.
Les exigences de qualité sont décrites dans des documents
(codes, normes ou autres). Leur prise en compte est garantie tout au
long du cycle de développement du système par une démarche de
qualité du fabricant, par des audits du maître d’ouvrage, par un pro-
cessus de qualification à l’initiative de l’autorité de sûreté.
1.1.2 Enjeu économique
Une centrale nucléaire est une installation industrielle représen-
tant un investissement très important, et donc un enjeu écono-
mique fort. La production d’électricité à partir du combustible
nucléaire est intrinsèquement complexe, requiert une très haute
disponibilité, mais aussi un rendement optimal, une pérennité de
l’installation, une diminution des coûts de maintenance et des
temps d’arrêt.
Les systèmes programmés impliqués doivent être à la hauteur de
cet enjeu économique.
1.2 Nature des systèmes programmés
Les systèmes programmés prennent une part croissante dans les
moyens d’instrumentation et de contrôle. Il ne leur est pas demandé
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
BN 3 425 − 2 © Techniques de l’Ingénieur, traité Génie nucléaire
__________________________________________________________________________
de remplacer simplement les moyens dits « conventionnels », mais
d’améliorer la sûreté de la conduite et le rendement économique de
la centrale.
1.2.1 Apport des systèmes programmés
Les systèmes numériques de protection réacteur sont apparus au
début des années 1980, en France sur le palier 1 300 MW. Par rap-
port aux systèmes de protection conventionnels, ils ont permis
d’affiner et d’augmenter la couverture des critères de déclenche-
ment de l’arrêt d’urgence, d’éviter les éventuels arrêts d’urgence
provoqués de manière intempestive par une défaillance simple du
système de protection, d’améliorer les conditions de test en exploi-
tation du système.
L’aide aux actions de sauvegarde consécutives à un arrêt
d’urgence, la régulation plus fine du procédé, l’exécution automati-
que de séquences sont autant de progrès que l’on doit au potentiel
des systèmes programmés.
Au niveau de l’interface opérateur, les systèmes programmés per-
mettent une aide considérable : présentation réduite et ordonnée
des alarmes en fonction de la situation de la tranche, procédures de
conduite notamment d’approche par états largement supportées
par l’informatique [BN 3 421].
Le palier français N4 est aujourd’hui le plus avancé au monde en
termes de conduite informatisée (figure 1). Grâce à ce nouveau
moyen, les opérateurs disposent de postes de conduite « assise »
cumulant, entre autres, tous les avantages cités ci-dessus.
Les systèmes programmés permettent aussi :
— d’optimiser la maintenance (décompte de la fatigue de chacun
des organes de la centrale, procédures de mise hors service provi-
soire d’un circuit, maintenance conditionnelle grâce à la sur-
veillance d’organes par analyse vibratoire) ;
— d’améliorer la connaissance du procédé. Les systèmes d’archi-
vage renseignent les experts, qui peuvent améliorer le contrôle du
procédé et, à plus long terme, sa conception ;
— de bénéficier des techniques de simulation permettant la mise
au point du procédé, de son contrôle et la formation des opérateurs.
Tous les aspects des systèmes programmés ne peuvent être abor-
dés dans cet article qui se limite aux systèmes programmés impli-
qués dans la conduite opérationnelle de la tranche.
1.2.2 Flexibilité des systèmes programmés
Les systèmes programmés apportent aussi une flexibilité nou-
velle par leur caractère très hautement configurable. Modifier ou
optimiser un automatisme, créer de nouvelles séquences, créer de
nouvelles vues (images) du procédé sont autant d’opérations ren-
dues possibles uniquement à l’aide d’outils de CAO. Cette flexibilité
est surtout appréciable dans les phases de mise en service et dans
l’évolution en cours d’exploitation.
Bien sûr, cette flexibilité ne dispense pas du respect des contrain-
tes de sûreté et donc de qualification. C’est pourquoi une modifica-
tion, même de paramètres, du système de protection s’apparente,
dans la majeure partie des cas, à une modification de code ou de
matériel, et engendre l’effort de requalification adéquat.
De manière générale, un système programmé peut être décrit
comme l’association de matériel (unités centrales, cartes d’acquisi-
tion, réseaux, écrans, etc.), de logiciel (logiciel de base, logiciel
applicatif générique) et de données ou paramètres (description des
entrées/sorties, automatismes, séquences, description des alarmes,
images, etc.).
La souplesse des systèmes programmés impose en contrepartie
une extrême rigueur dans la gestion de configuration du matériel,
du logiciel et des données.
__________________________________________________________________________ QUALIFICATION DES SYSTÈMES PROGRAMMÉS DANS LES CENTRALES
Figure 1 – Salle de commande numérique de la centrale nucléaire de Chooz
1.2.3 Types de systèmes
On se reportera à l’article [BN 3 411] pour une meilleure compré-
hension de l’architecture des systèmes de contrôle-commande.
1.3 Objectifs de qualité des systèmes
programmés
Nous ne reviendrons pas ici sur les missions assignées aux systè-
mes programmés, bien que ces missions constituent une avancée
technologique par leur richesse fonctionnelle, leur étendue et leurs
performances (se reporter aux articles [BN 3 411] et [BN 3 421].
Nous nous intéresserons maintenant à l’objet principal de cet article
qui est la qualité de ces systèmes et, plus particulièrement, de leur
logiciel.
Les exigences portées sur les systèmes programmés proviennent
d’impératifs de sûreté ou d’exploitation, éventuellement des deux
(cf. § 1.1). Les objectifs concernant essentiellement la sûreté sont :
— la conformité au besoin : la mission de sûreté du système doit
être définie de manière claire et le système doit remplir cette mis-
sion avec exactitude ;
— la fiabilité : il faut pouvoir caractériser qualitativement ou
mieux quantitativement la confiance que l’on place dans le système
à l’instant t, c’est-à-dire le maintien de son fonctionnement
conforme aux spécifications au fil du temps et dans toutes les
conditions d’ambiance spécifiées ;
— la disponibilité : un objectif de disponibilité doit être spécifié
pour chaque mission et tenu ;
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Génie nucléaire
— le caractère qualifiable : selon la contribution du système à la
sûreté, il sera exigé pour sa qualification un certain nombre de
« garanties » de tenue des objectifs précédemment cités. Cela peut
conduire à se restreindre à des techniques ou pratiques dont on
peut « prouver » l’efficacité.
À des fins économiques, d’autres objectifs sont fixés, tels :
— la fiabilité des systèmes non essentiels pour la sûreté de la
tranche mais influant sur sa disponibilité ;
— au-delà de l’état initial des systèmes programmés, leur main-
tien en condition opérationnelle et leur potentiel à évoluer pendant
15 à 25 ans.
2. Documents normatifs
Un moyen formel de caractériser la qualité d’un système pro-
grammé est d’en évaluer la conformité par rapport à un ensemble
de normes bien choisi. Cette évaluation est un critère d’appréciation
essentiel pour l’autorité de sûreté, surtout en ce qui concerne la
catégorie la plus sévère (1E pour les paliers français).
2.1 Paliers français et RCC-E
Après une réflexion entreprise en 1976 par les représentants du
ministère de l’Industrie, du CEA, d’EDF et de Framatome, il fut
BN 3 425 − 3
QUALIFICATION DES SYSTÈMES PROGRAMMÉS DANS LES CENTRALES
décidé d’élaborer une codification, fondée non pas sur des considé-
rations générales et abstraites mais sur la réalisation concrète des
tranches nucléaires avec ses acteurs techniques (organismes de
sûreté, exploitants, constructeurs, fournisseurs et sous-traitants).
C’est ainsi, que fut créée l’AFCEN (association française pour les
règles de conception et de construction des matériels des chau-
dières électronucléaires) en 1980. Cette association regroupe EDF,
Framatome et Novatome.
On se reportera à l’article [B 3 220] pour une information
complète sur les codes applicables en France.
2.1.1 Code RCC-E
Le RCC-E [3] constitue un ensemble de règles techniques qu’un
fabricant applique pour la conception et la construction des maté-
riels électriques des îlots nucléaires et en premier lieu pour les
matériels liés à la sûreté des installations.
Le RCC-E se caractérise par l’importance donnée à la qualification
aux conditions accidentelles des matériels, qui relève d’exigences
strictes d’assurance de la qualité.
L’édition* la plus récente du RCC-E date de 1984. Elle traite de
l’ensemble du cycle de vie des matériels électriques avec complé-
tude, moyennant parfois des renvois à d’autres documents norma-
tifs. Ce document traite d’appareillages électriques conventionnels,
et il faut le décliner avec intelligence pour l’appliquer à des systè-
mes programmés.
Nota : * Édition est ici employé au sens réédition complète. Des modifications ou ajouts
ont été édités depuis.
2.1.2 Modificatif C 5000 du RCC-E
Le modificatif* C 5000 [Systèmes programmés (aspects logiciel)
d’octobre 1987] s’applique aux « systèmes programmés dont la
défaillance peut avoir des conséquences sur la sécurité des person-
nes ou des incidences notables sur la disponibilité de la centrale ».
Nota : * Modificatif est le terme consacré par l’AFCEN. Il s’agit en fait d’un supplément
(traitant d’un sujet non encore abordé).
Le modificatif C 5000 ne reconnaît que deux catégories de
logiciel : les logiciels classés de sûreté et les autres. Il est très
contraignant pour les premiers grâce à de nombreux reports à la
norme CEI 880. Il ne traite pas en détail les autres catégories de
logiciel.
2.2 Normes AIEA
Le rôle de l’AIEA (Agence internationale de l’énergie atomique)
est de définir des objectifs, et une politique d’instrumentation et de
contrôle-commande. Les documents produits sont des codes,
guides ou documents techniques (tous ces documents étant abu-
sivement appelés « normes »).
La liste des documents de l’AIEA applicables aux systèmes pro-
grammés est présentée dans le tableau 1.
En général, ces documents n’ont pas pour vocation d’être appli-
qués tels quels. Le rôle de la CEI est de transcrire ces documents en
normes applicables.
2.3 Normes CEI
La CEI (Commission électrotechnique internationale) est une
organisation mondiale qui a pour objet de favoriser la coopération
internationale pour toutes les questions de normalisation dans les
domaines de l’électricité et de l’électronique.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
BN 3 425 − 4 © Techniques de l’Ingénieur, traité Génie nucléaire
__________________________________________________________________________
Tableau 1 – Normes AIEA
Norme Référence
Code on the safety of nuclear power 50-C-QA
plants : quality assurance
Code on the safety of nuclear power 50-C-D
plants : design
Safety functions and component classi- 50-SG-D1
fication for BWR, PWR and PTR
Protection system and related features 50-SG-D3
in nuclear power plants
Safety-related instrumentation and con- 50-SG-D8
trol systems for nuclear power plants
General design safety principles for 50-SG-D11
nuclear power plants
Manual on Quality Assurance for Com- TECHNICAL REPORT 282
puter Software Related to the Safety of
Nuclear Power Plants
Software Important to Safety in Nuclear TECHNICAL REPORT 367
Power Plants
Le comité CEI 45 « Instrumentation nucléaire » est divisé en deux
sous-comités :
— le sous-comité 45 A : instrumentation des réacteurs ;
— le sous-comité 45 B : instrumentation pour la radioprotection.
Le sous-comité 45 A a la charge d’émettre des normes à partir des
recommandations de l’AIEA. Ces normes sont nombreuses car elles
couvrent l’ensemble de l’instrumentation depuis les capteurs
jusqu’aux salles de commande.
2.3.1 Norme CEI 1226
La norme CEI 1226 (Centrales nucléaires - Systèmes d’instrumen-
tation et de contrôle-commande importants pour la sûreté - Classifi-
cation) établit une méthode de classification des fonctions
d’information et de commande des centrales nucléaires, des sys-
tèmes et du matériel d’instrumentation et contrôle qui assurent
ces fonctions, en catégories indiquant leur importance pour la
sûreté [1].
La classification qui en résulte permet alors l’établissement de cri-
tères de conception appropriés. Les critères de conception sont les
mesures de la qualité garantissant qu’il y a adéquation de chaque
système relativement à son importance pour la sûreté. Les prescrip-
tions sont souvent exprimées en termes de reports à d’autres nor-
mes (CEI 780, 880, 980 notamment).
2.3.2 Norme CEI 880
Ce document [2] datant de 1986 est applicable aux systèmes de
protection et de sauvegarde des réacteurs. Il fait autorité en la
matière car il a été appliqué pour la conception et la qualification de
systèmes numériques de protection réacteur dans plusieurs pays
(dont la France, la Grande-Bretagne).
Il fournit un ensemble de prescriptions imposant une méthodolo-
gie de développement rigoureuse basée sur le « cycle en V », et pré-
conisant des techniques permettant d’obtenir du logiciel fiable. Ces
techniques permettent essentiellement de maîtriser la complexité
__________________________________________________________________________ QUALIFICATION DES SYSTÈMES PROGRAMMÉS DANS LES CENTRALES
(découpe en modules simples, langage de programmation évolué et
orienté sûreté, non-utilisation des interruptions lors de la program-
mation, etc.).
2.3.3 Autres normes CEI
Le tableau 2 liste les normes CEI les plus directement applicables
aux systèmes programmés.
Tableau 2 – Autres normes CEI
Norme Référence
Centrales nucléaires - Systèmes d’instrumenta- CEI 1226 : 1993
tion et de contrôle-commande importants pour
la sûreté - Classification
Logiciel pour les calculateurs utilisés dans les CEI 880 : 1986
systèmes de sûreté des centrales nucléaires
Calculateurs programmés importants pour la CEI 9897 : 1989
sûreté dans les centrales nucléaires
Critères fonctionnels de conception pour un CEI 960 : 1988
système de visualisation des paramètres de
sûreté pour les centrales nucléaires
Pratiques recommandées pour la qualification CEI 980 : 1989
sismique du matériel électrique du système de
sûreté dans les centrales nucléaires
Qualification des constituants électriques du CEI 780 : 1984
système de sûreté des centrales nucléaires
D’importants travaux sont en cours, principalement pour couvrir
des sujets non traités à l’heure actuelle (nouvelles technologies, réu-
tilisation de composants existants, systèmes de classe de sûreté
autre que la plus sévère, etc.).
2.4 Autres normes, travaux en cours
D’autres référentiels normatifs peuvent être utilisés pour caracté-
riser la qualité des systèmes programmés des centrales nucléaires,
tels :
— la norme CEI 1508 traitant des systèmes critiques dans l’indus-
trie en général ;
— les documents rédigés par la NRC (Nuclear Regulatory
Commission ). Cette institution rédige et impose les règles applica-
bles aux États-Unis ;
— la norme japonaise JEAG 4609 traitant des systèmes program-
més importants pour la sûreté dans les centrales nucléaires.
Parmi les travaux en cours, on remarque :
— l’ETC-I (European Technical Code for I & C ) qui est le document
homologue de l’actuel RCC-E pour le futur palier européen EPR ;
— les normes CEI en cours de rédaction (cf. § 2.3).
La France, comme d’autres pays, tente d’évoluer de standards
nationaux (RCC-P, RCC-E) vers des standards internationaux (ETC-I
et normes CEI). Cela suppose de reconnaître dans ces standards
internationaux des pratiques et une rigueur équivalentes à ce qui est
fait en France.
L’élaboration de standards internationaux pose cependant des
problèmes d’harmonisation. Les pratiques ne sont pas identiques
dans tous les pays même si elles conduisent à la même qualité du
produit final. La tendance est donc à obtenir un consensus en prio-
rité sur les qualités d’un système programmé (fiabilité, disponibilité,
maintenabilité, déterminisme, etc.) plutôt que sur les moyens d’y
parvenir (techniques de réalisation).
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Génie nucléaire
3. Qualification des systèmes
programmés. Pratiques
3.1 Généralités
L’installation de systèmes programmés dans les centrales
nucléaires a soulevé un certain nombre de problèmes nouveaux.
Outre la création des systèmes eux-mêmes, il a fallu créer des
méthodes de qualification de ces systèmes.
3.1.1 Qualification du matériel
Dans une certaine mesure, les règles de conception et de
construction du matériel programmable peuvent s’apparenter à une
extension d’une pratique déjà courante pour le matériel électrique
(cycle de développement, sélection de composants, tests sous
forme d’épreuve, etc.). Une bonne partie des exigences est factuelle
et donc facile à vérifier (exemple : redondance, isolation géogra-
phique) une autre partie est démontrable par tests (exemple : résis-
tance aux conditions sismiques, aux conditions d’ambiance,
isolation électrique). L’assurance qualité du procédé de fabrication,
quoique plus complexe, peut aussi s’apparenter à des pratiques
existantes pour les produits électroniques.
Concernant les unités centrales, nous éludons le débat de la limite
entre le matériel et le logiciel, trop détaillé par rapport à l’exposé (le
microcode d’un processeur est-il considéré comme du matériel ou
du logiciel ?).
Le comportement du matériel se caractérise en général par un
profil d’exécution (séquencement des sollicitations au fil du temps)
relativement constant ou répétitif. Les éléments d’une unité centrale
sont sollicités selon une combinatoire maîtrisée.
On peut donc considérer que tous les cas de figure d’exécution
ont été testés et qu’il ne reste quasiment pas d’erreurs de concep-
tion. Nous savons que cette hypothèse est simplificatrice mais elle
est assez exacte pour les cartes constituant le système de protection
ou les automates de sûreté.
Par conséquent, fiabilité et disponibilité d’un équipement matériel
vont reposer essentiellement sur la fiabilité et la disponibilité des
composants individuels. Les mesures effectives sur un nombre suf-
fisant de matériels et composants confirment d’ailleurs cette hypo-
thèse, et il est admis que fiabilité et disponibilité du matériel sont
des grandeurs mesurables.
3.1.2 Qualification du logiciel
Dès qu’un logiciel dépasse quelques centaines de lignes, le nom-
bre de profils d’exécution possibles devient énorme. Le problème
est bien sûr accru si on utilise des interruptions et l’ordonnancement
de tâches parallèles. Si on ne limite pas la complexité à la concep-
tion, il est illusoire de prétendre tester tous les profils d’exécution
possibles. Fiabilité et disponibilité du logiciel sont uniquement
dépendants des erreurs résiduelles issues de fautes de conception,
qui ne se transformeront en défaillance que le jour où l’exécution
passera par un profil qui révélera ces erreurs.
Sans pour autant minimiser l’importance pour la sûreté ou l’effort
nécessaire à la qualification du matériel, nous allons nous intéresser
par la suite essentiellement à la qualification du logiciel, problème
plus nouveau et plus complexe de par la nature même du logiciel.
3.1.3 Importance du contexte
Il faut se garder de toute comparaison hâtive de pratiques entre
deux pays, même sur deux systèmes de nature a priori similaire.
BN 3 425 − 5
QUALIFICATION DES SYSTÈMES PROGRAMMÉS DANS LES CENTRALES
Différence de pratique ne signifie pas incohérence. La cohérence se
juge en fait au sein d’une même réalisation, par l’homogénéité
d’application de la doctrine de sûreté. Ainsi une exigence qui paraît
moins forte sur un système donné peut être compensée par diver-
ses techniques : diversification, défense en profondeur, tests en
exploitation, etc.
En outre, des pratiques différentes peuvent tout à fait amener à un
niveau de sûreté équivalent. Concernant le logiciel, domaine relati-
vement nouveau, clients et industriels fournisseurs ont été amenés
à sélectionner des techniques qui leur paraissaient appropriées,
fonction des règles de sûreté, de la nature du système à réaliser et
de leur savoir-faire.
La présentation qui suit se base sur des exemples de réalisation
rapportés à leur contexte.
3.2 Systèmes de protection
Toutes les centrales nucléaires de puissance sont équipées d’un
système de protection, même si le contour et les missions qui lui
sont assignées connaissent quelques différences. Se reporter à
l’article [B 3 470].
Ce sont des systèmes essentiellement à logique booléenne et de
type réactif (passifs en conditions normales, mais qui déclenchent
des actions sur détection de conditions anormales). Les systèmes
numériques de protection succèdent à une génération de systèmes
à relayage conventionnel, le noyau de leur mission est donc de
reproduire les fonctions de protection déjà connues, le tout avec
une fiabilité et une disponibilité supérieures. Dispositif essentiel
d’application de la doctrine de sûreté, il est toujours classé au
niveau le plus sévère (1E en France).
Ce paragraphe décrit la réalisation du système numérique de pro-
tection du réacteur (SNPR) N4. D’autres réalisations similaires sont
ensuite évoquées, en ne présentant que les pratiques différentes ou
complémentaires.
3.2.1 Système numérique de protection réacteur
N4 (France)
Ce système est connu sous le nom de SPIN (système de protec-
tion intégré numérique, technologie de Schneider Electric). Pour ce
système, la technologie numérique a permis la prise en compte
d’exigences de conception supplémentaires par rapport à un sys-
tème conventionnel visant à accroître sûreté et disponibilité de la
tranche. Particulièrement :
— une plus grande diversification des conditions d’arrêt
d’urgence ;
— le respect du critère de défaillance unique y compris lors du
test en exploitation d’une chaîne du système ;
— éviter tout déclenchement intempestif de l’arrêt d’urgence sur
défaillance unique d’un composant du système.
Ces exigences supplémentaires ont induit une architecture plus
complexe basée sur une redondance 4 qu’il a fallu, en contrepartie,
maîtriser.
3.2.1.1 Application de la CEI 880
La conception du logiciel en vue de la qualification du système a
largement reposé sur le respect strict de la norme CEI 880, et ce dans
son interprétation la plus contraignante.
Un système qualité a été mis en place, respectant le cycle dit
« en V » et les activités de vérification requises par la norme. Le
cycle en V est d’une manière générale très répandu, à tel point que
cette pratique n’est pas nécessairement typique d’une application
de sûreté. Il est donc important de signaler que les règles associées
d’assurance qualité et de contrôle qualité sont spécifiques aux sys-
tèmes de sûreté. Les audits de conformité sont eux aussi orientés
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
BN 3 425 − 6 © Techniques de l’Ingénieur, traité Génie nucléaire
__________________________________________________________________________
sur la sûreté et sont, de ce point de vue, beaucoup plus contrai-
gnants que des audits de types certification ISO 9001.
Les activités de tests unitaires, vérification et validation ont été
effectuées par des personnes indépendantes de celles qui ont effec-
tué le développement. Ces activités ont comporté un cycle systéma-
tique de relecture de documents et des programmes. Un contrôle de
configuration rigoureux assure la cohérence de chaque module logi-
ciel avec sa documentation, l’environnement et la trace des tests
associés.
3.2.1.2 Preuve et déterminisme
Les systèmes numériques de protection réacteur réalisés en
France dès le palier 1 300 MW constituaient une première mondiale.
L’autorité de sûreté a donc logiquement porté une attention parti-
culière à la qualification du logiciel.
Une idée force, qui a sans doute dicté beaucoup de choix, était
qu’il fallait obtenir la preuve de bon fonctionnement du logiciel, au
même titre que l’on obtenait cette preuve grâce à une combinatoire
de tests limitée pour les systèmes de protection à relayage conven-
tionnel. Sur un logiciel de grande taille, nous avons déjà exprimé
qu’il est impossible d’apporter la preuve de bon fonctionnement par
une combinatoire exhaustive de tests. Il a donc été nécessaire de
fixer des règles de conception conduisant à un logiciel simple et
entièrement maîtrisé.
La norme CEI 880 a été conçue pour conduire à la maîtrise de la
complexité et comporte, surtout dans les annexes, des règles de
réalisation contraignantes. Ces exigences ont été respectées même
si elles ne présentaient pas un caractère strictement obligatoire.
Principalement :
— aucun logiciel préexistant n’a été utilisé ;
— deux types de logiciel sont définis : le logiciel système et le
logiciel d’application, tous deux entièrement conçus selon la
CEI 880 ;
— le logiciel est découpé en modules pouvant être testés
exhaustivement ;
— les programmes n’utilisent pas de tâches ni d’interruption.
L’exécution d’un programme (logiciel système incluant la gestion
des entrées/sorties et logiciel d’application) est réalisée en une seule
boucle cyclique ;
— l’allocation dynamique de mémoire, technique jugée
complexe et imparfaite, est interdite ;
— les programmes ne contiennent pas de code « mort » (inuti-
lisé) ;
— le code a été systématiquement inspecté par un outil d’analyse
statique ;
— des autotests sont effectués au lancement du logiciel et au
cours de son exécution.
3.2.1.3 Éviter les erreurs dès la conception
La norme CEI 880, bien que très directive, donne lieu à des inter-
prétations différentes sur le caractère obligatoire ou sur la portée de
certaines exigences, donc des moyens à mettre en œuvre. Il suffit de
regarder les différences de pratique d’un projet à l’autre pour s’en
convaincre.
Il est certain que les règles déjà énoncées diminuent la probléma-
tique dans des proportions appréciables. L’état de l’art sur le logiciel
critique incite à éviter ou éliminer les erreurs aussi tôt que possible
dans le processus de conception. À cette fin, l’industriel fournisseur
a jugé utile de faire le choix d’une technique de conception particu-
lière.
■ Langage Lustre
Ce langage structuré permet l’écriture d’un programme sous
forme d’un ensemble d’équations définissant des variables fonction
du temps. Le temps en langage Lustre est discret, et on peut l’assi-
miler à la séquence des entiers positifs. L’équation « x = y + z »
signifie qu’à chaque instant t, on a « x (t ) = y (t ) + z (t ) ». Une varia-
__________________________________________________________________________ QUALIFICATION DES SYSTÈMES PROGRAMMÉS DANS LES CENTRALES
ble étant définie par une équation et une seule, nombre d’erreurs de
programmation classiques étaient ici impossibles.
Le formalisme du langage Lustre est proche des habitudes des
automaticiens. Il a permis un parallélisme de conception maximal
tout en assurant une bonne communication entre les intervenants
du projet (concepteurs, programmeurs, valideurs...).
■ Hypothèse de synchronisme
Elle repose sur l’existence d’une horloge de base discrète. Le
concepteur suppose ensuite que les moyens de traitement disponi-
bles permettent d’effectuer le calcul des sorties avant l’occurrence
d’arrivée de nouvelles entrées. Le bien-fondé de cette hypothèse est
vérifié a posteriori : le temps de traitement doit être inférieur au
temps de cycle spécifié pour l’application.
Cette vision simplifie le comportement dynamique du pro-
gramme, ainsi rendu déterministe. Le problème de prise en compte
d’événements en cours de traitement ne se pose plus.
■ Atelier graphique de conception
Créé pour l’occasion, cet atelier reprend certains aspects de la
méthode SADT (Structured Analysis and Design Technique ) :
démarche de conception descendante, circulation de données
(représentée par des flèches) reliant les fonctions (représentées par
des boîtes), notion de condition d’activation de ces fonctions.
L’interface graphique guide et contraint l’utilisateur dans sa démar-
che progressive d’affinement des fonctions et des données. L’outil
assure en outre des vérifications statiques (de syntaxe, de cohé-
rence, de type).
L’atelier reprend les principaux opérateurs du langage Lustre, per-
met d’appeler des fonctions en C, intègre un générateur de code
pour chacun de ces langages, et un générateur de documentation.
L’utilisation de l’atelier a permis de porter un effort de développe-
ment particulier sur la phase de conception. Les contrôles stricts de
cohérence ont permis de réduire les temps d’intégration et de mise
au point du code. Des mesures d’erreurs résiduelles ont permis
d’affirmer que la technique a été très efficace pour maîtriser les
200 000 lignes de code C (générées à près de 90 % par l’atelier) du
SNPR.
■ Technique de diversification
Cette technique consiste en la conception et la réalisation d’une
même fonctionnalité selon des moyens (matériel, méthodes, outils,
langages, etc.) différents. L’intérêt est de ne pas reproduire, sur des
unités parallèles, les mêmes erreurs d’exécution dues aux mêmes
fautes de conception, contrairement à une simple redondance utili-
sant mêmes matériels et logiciels.
Même si la diversification n’a pas été appliquée directement aux
unités redondantes du système numérique de protection réacteur
N4 (deux unités redondantes exécutent en fait le même logiciel), le
concept de diversification a été exploité sous deux formes :
— les conditions d’arrêt d’urgence sont fonctionnellement diver-
sifiées au sein du système. En cas de défaillance d’une sollicitation
de l’arrêt d’urgence, d’autres sollicitations seront effectuées selon
d’autres critères ;
— la protection réacteur de type « ATWS (Anticipated Transient
Without Scram) » est en outre réalisée dans un automate de sûreté
classé 2E. La diversification est ici totale, puisque cet automate de
sûreté est conçu par une société différente, sur un matériel différent
et avec un logiciel différent (indépendant).
■ Expérience de vérification formelle de propriétés
Cette expérience a été menée sur une partie de l’application.
La méthode, applicable aux langages synchrones, est basée sur les
étapes suivantes :
— déclaration d’assertions en langage Lustre permettant de ca-
ractériser la combinatoire des entrées cohérentes du programme ;
— déclaration de propriétés en langage Lustre que les sorties du
programme doivent systématiquement vérifier si les entrées corres-
pondantes vérifient les assertions ;
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Génie nucléaire
— élaboration d’un automate d’états en fonction des assertions,
du programme à vérifier et des propriétés ;
— génération par l’atelier de tous les états possibles de cet auto-
mate et pour chacun d’eux, vérification de l’ensemble des propriétés
(technique connue sous le nom de model checking ).
Cette technique a été utilisée en complément (et non en remplace-
ment) des autres méthodes de vérification. Elle n’a pas été appli-
quée à l’ensemble du logiciel, mais à une unité seulement. De plus,
elle n’a pas eu pour but d’être le moyen unique ou principal de véri-
fication d’un logiciel. Le test « conventionnel » de chaque module
logiciel reste l’étape clé de la vérification de celui-ci.
3.2.1.4 Qualification
Le SNPR doit satisfaire aux exigences applicables aux systèmes
1E, exigences concernant :
— la redondance ;
— l’indépendance (séparation physique et électrique) ;
— les alimentations électriques de secours ;
— la qualification des matériels aux conditions d’ambiance nor-
male et accidentelle ;
— l’aptitude aux essais périodiques.
Présentées ainsi, les exigences ne traitent pas du logiciel. Le
RCC-E, code applicable à tout système électrique, comble cette
lacune en imposant, pour les systèmes programmés 1E, le respect
de la norme CEI 880.
Pour le système numérique de protection réacteur N4, l’exploitant
a défendu avec succès vis-à-vis de l’autorité de sûreté :
— que le respect de la norme CEI 880 était une base adéquate
pour le processus de qualification du logiciel ;
— que cette norme était effectivement appliquée pour le dévelop-
pement du système.
Pour un « matériau » aussi complexe que le logiciel, seul un juge-
ment d’expert permet l’appréciation de conformité à une norme. La
rigueur du fournisseur, les audits constants du client et de l’autorité
de sûreté ont effectivement conduit à la réalisation d’un logiciel
aussi exempt d’erreurs que possible.
Sans que l’on ne soit pour autant arrivé à chiffrer la fiabilité du
logiciel, on constate par retour d’expérience que le logiciel du sys-
tème numérique de protection réacteur N4 est suffisamment
exempt d’erreurs pour que fiabilité et disponibilité du système
soient uniquement fonction du matériel et donc « mesurables »
(hypothèse du comportement « parfait » du logiciel).
3.2.2 Système numérique de protection réacteur
Sizewell (Grande-Bretagne)
Le PPS (Primary Protection System) numérique pour le site de
Sizewell B a lui aussi apporté son lot d’avantages par rapport à un
système conventionnel, parmi lesquels on compte :
— une meilleure information de l’opérateur ;
— une automatisation des tests périodiques en exploitation ;
— une plus grande couverture des conditions de déclenchement
des actions de protection.
3.2.2.1 Diversification par un système conventionnel
En France, des règles et codes ont reçu l’aval de l’autorité
de sûreté, tels les règles fondamentales de sûreté (RFS) [6], les
codes RCC-P, RCC-E, etc. En Grande-Bretagne, la démarche est diffé-
rente. L’exploitant expose à l’autorité de sûreté le « safety case »,
c’est-à-dire défend « dans l’absolu » un dossier de sûreté qui se doit
d’être convaincant.
Les pratiques sont ensuite assez proches car fournisseurs et
exploitants ont effectivement une démarche structurée qui consiste
à se fixer des règles et à s’y tenir. Mais la différence essentielle est
sans doute venue de la difficulté (l’impossibilité à l’heure actuelle)
BN 3 425 − 7
QUALIFICATION DES SYSTÈMES PROGRAMMÉS DANS LES CENTRALES __________________________________________________________________________

de mesurer la fiabilité du logiciel. Or l’approche probabiliste revêt en — 40 homme-an de vérification de l’ingénierie ;

Grande Bretagne une importance de premier plan.
Devant l’insuffisance de preuve de défaillance inférieure à 1 pour
10 000 sollicitations pour une chaîne de protection (1 pour
10 000 000 pour l’ensemble du PPS), l’autorité de sûreté a exigé que
le PPS numérique soit doublé d’un système de protection conven-
tionnel (et non numérique comme pour l’ATWS en France), et ce
pour tous les cas de déclenchement de probabilité supérieure
à 1 occurrence tous les 1 000 ans.
— 40 homme-an de vérification de la conception par une équipe
du client indépendante de l’équipe projet ;
— 80 homme-an d’« analyse de confirmation » à l’aide de l’outil
MALPAS ;
— 20 homme-an de vérifications diverses par des tiers ;
— 15 homme-an de test dynamique ;
— 15 homme-an d’activités de sûreté connexes de la part du
client.

3.2.2.2 CEI 880 et vérification
Dans la pratique, la réalisation a été contrainte par le respect de la
CEI 880. On peut se reporter à ce propos au document [5].
Le processus anglais se caractérise par un gigantisme des activi-
tés de vérification et validation dont on a pu lire dans la presse
qu’elles ont demandé 300 homme-an (50 pour le fournisseur en acti-
vité de vérification et validation pure, 250 pour le client et des socié-
tés consultantes mandatées par le client) (figure 2). Les 250 homme-
an de validation hors fournisseur ont consisté en [4] :
— 40 homme-an de vérification de la conception par l’équipe pro-
jet du client ;
En plus du poids des chiffres, il est intéressant de noter l’impor-
tance apportée aux techniques d’« analyse de confirmation » et de
comparaison entre le programme source et les instructions effecti-
vement exécutées.
■ Objectif de l’analyse de confirmation
Il est relativement comparable à l’essai de vérification de proprié-
tés effectué sur une unité du système de protection français. La dif-
férence essentielle est que les Anglais ont appliqué l’analyse de
confirmation sur l’ensemble du logiciel de protection réacteur (aux
difficultés de mise en œuvre près) et en ont fait un argument de pre-
mier plan de validation de sûreté du PPS.

Spécifications Spécifications Conception Code Code Code

du système du logiciel du logiciel source objet exécutable
Revue de conformité
au besoin

Vérification indépendante des spécifications

Vérification de conformité au besoin

Analyse à l'aide de MALPAS

confirmation
Analyse de

Comparaison code source / code exécutable

Vérification et validation
par le fournisseur

Vérification indépendante par le fournisseur

Validation indépendante par le fournisseur

Figure 2 – Validation du PPS de Sizewell [4]

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
BN 3 425 − 8 © Techniques de l’Ingénieur, traité Génie nucléaire
__________________________________________________________________________ QUALIFICATION DES SYSTÈMES PROGRAMMÉS DANS LES CENTRALES
Après une phase de traduction du logiciel source en un langage
« intermédiaire » interprétable par l’outil MALPAS, l’outil effectue
en séquence :
— une analyse syntaxique (vérification de structure du logiciel et
des données) ;
— une analyse sémantique (description de la fonctionnalité du
code par la description mathématique des sorties en fonction des
entrées) ;
— une analyse de conformité. Cette étape (la plus innovante par
rapport aux outils d’analyse statique conventionnels) consiste en
une vérification du code par rapport à une représentation mathéma-
tique de ses spécifications.
■ Comparaison du code source par rapport au code effectivement
exécuté
Il permet de se prémunir contre les erreurs de compilation. Afin
d’adopter une démarche différente de la compilation, le chemine-
ment inverse a été employé :
— reconstitution du code objet à partir des PROM de pro-
gramme ;
— désassemblage du code objet en un langage type assembleur ;
— décompilation du langage assembleur en un code source, puis
comparaison du code source obtenu au code source réel.
3.2.3 Système numérique de protection réacteur
de Darlington (Canada)
Le SPIN du palier N4 et le PPS ont un logiciel de volume similaire
de l’ordre de 200 000 lignes de code source. Le SNPR de Darlington
(appelé SRS : Shutdown Reactor System) ne comprend que
5 000 lignes de langage Pascal. La différence s’explique par :
— l’architecture très distribuée des systèmes français et anglais,
qui ont nécessité une part importante de logiciel système et de
communication ;
— la différence de fonctionnalité. Le SRS n’embarque que la fonc-
tion d’arrêt d’urgence du réacteur, une fonction parmi d’autres sur
les autres systèmes ;
— la compacité du logiciel du SRS, compacité proscrite sur les
autres systèmes.
Le processus de qualification du logiciel canadien a laissé une
impression de tâtonnement pour la recherche, la rédaction et la
mise en application de normes adéquates. Cette impression est en
partie due à la grande transparence dans laquelle s’est déroulée ce
processus. En pratique, on peut remarquer qu’aucune transgression
n’a été tolérée, et qu’il a fallu un processus de qualification complet
et cohérent, même au prix d’un retard pénalisant, pour obtenir l’aval
de l’autorité de sûreté.
Une bonne partie du logiciel était déjà écrite au moment où les
normes applicables sont entrées en vigueur. Une forte activité de
rétroconception (« reverse engineering ») a donc été nécessaire.
L’équipe d’experts techniques délégués par l’autorité de sûreté
canadienne a exigé un effort particulier de reformulation des spéci-
fications de besoins. Un éminent spécialiste (L.D. Parnas) a en effet
jugé que la difficulté de caractériser l’environnement « réel »,
auquel était soumis le SRS, à l’aide du langage naturel constituait
un risque d’ambiguïté inacceptable.
3.3 Automates de sûreté
Les projets des années 1980 ont introduit les automates program-
mables dans la conduite des centrales nucléaires. À l’inverse des
systèmes de protection, ce sont des systèmes critiques de type
« actif », c’est-à-dire devant fournir un service continu et fiable. Ils
peuvent contribuer à la sûreté à deux titres :
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Génie nucléaire
— en conduite normale où ils contribuent à maintenir la centrale
dans un domaine de fonctionnement sûr (première ligne de
défense) ;
— en conduite postaccidentelle où ils permettent de tempérer les
conséquences de l’accident dans les meilleures conditions possi-
bles (autres lignes de défense).
Par rapport à la génération précédente d’équipements à relayage
et à régulation analogique, les automates numériques ont beaucoup
d’avantages. Le câblage est réduit. Les fonctions logiques et de
régulation sont plus fines et surtout programmables ou paramétra-
bles à l’aide d’un outil de CAO.
On se reportera à l’article [BN 3 411] pour la description des mis-
sions assignées aux différents systèmes et leur positionnement
dans l’architecture générale.
3.3.1 Automates classés 1E du palier N4
Hors système de protection, deux automates sont classés 1E sur
le palier N4 [BN 3 411] :
— le contrôle des systèmes supports de sauvegarde (CS3) ;
— le système de contournement à l’atmosphère utilisé en protec-
tion (SCAP).
Ces deux automates sont basés sur un matériel de même nature
que le système de protection, et ont été réalisés selon des techni-
ques comparables. Qualité de réalisation et processus de qualifica-
tion ont aussi été similaires.
Ces systèmes sont apparus chronologiquement après le système
de protection. Il y a donc eu, dans certains cas, réutilisation de
composants matériels et logiciels existants. Ce qui peut paraître par
certains côtés rassurant (les composants réutilisés ont déjà été
éprouvés par une vérification), peut aussi être vu comme une fai-
blesse. Le cycle en V présenté initialement ne traitait pas de la réuti-
lisation de composants existants. Il y a en outre un danger à « faire
confiance » à un module déjà testé lorsqu’on le réutilise dans des
conditions différentes. L’échec du premier lancement d’Ariane V en
est une regrettable démonstration.
Cette situation a été gérée en ne considérant pas les tests déjà
effectués pour le système de protection comme acquis, mais en
définissant et appliquant une stratégie de vérification et de valida-
tion complète pour ces nouveaux systèmes.
3.3.2 Automates classés 2E du palier N4
Le système de contrôle des auxiliaires de tranches (SCAT) réalise
tous les automatismes non déjà cités sauf la régulation des grappes
longues et la régulation de la turbine. Ce système est déclinable en
deux sous-systèmes : le SCAT 2E embarquant les automatismes
classés de sûreté, et le SCAT non classé embarquant le reste des
automatismes, non classés de sûreté.
Le SCAT 2E présente des caractéristiques particulières :
— il représente le seul type de système programmé classé 2E sur
le palier N4 ;
— il a été réalisé à l’aide d’un produit automate préexistant, le
procédé de qualification de la composante produit est donc basé sur
l’analyse de l’existant, la rétroconception des parties sensibles et la
vérification et validation a posteriori :
• il est très hautement configurable. Tous les automatismes sont
décrits à l’aide d’un outil de CAO qui produit des fichiers téléchar-
gés dans les automates. Ces fichiers sont partie intégrante de la
fonction 2E, au même titre que le logiciel,
• il représente une catégorie de complexité intermédiaire de
système programmé, plus tout à fait déterministe mais de
comportement « prédictible », proche des règles imposées par la
CEI 880, mais pas au niveau d’application le plus sévère.
BN 3 425 − 9
QUALIFICATION DES SYSTÈMES PROGRAMMÉS DANS LES CENTRALES
Toutes ces particularités font du SCAT 2E un cas de démarche de
qualification pragmatique d’un système relativement complexe,
intégrant des données de configuration, et basé sur un produit
préexistant.
3.3.2.1 Caractéristiques de la classe 2E
La classe 2E est caractérisée par le respect des exigences
suivantes :
— redondance avec alimentations électriques indépendantes ;
— qualification des matériels aux conditions d’ambiance et aux
conditions sismiques ;
— aptitude aux essais périodiques ;
— conception et construction selon le RCC-E.
Concernant le logiciel système qui est préexistant dans ce cas, la
conformité à la CEI 880 est requise, avec justification au cas par cas
si certaines exigences ne sont pas respectées. Si l’analyse montre
que le respect de la CEI 880 est incomplet ou incertain, il est exigé
d’analyser les conséquences potentielles et le retour d’expérience
sur d’autres installations.
3.3.2.2 Évaluation de la qualité du produit
Le SCAT 2E a été réalisé à l’aide d’un produit automate existant,
sélectionné à la suite d’une étude comparative. Cette sélection a été
une étape importante car ce sont en partie les qualités initiales du
produit qui ont rendu le processus de qualification envisageable, à
savoir :
— qualité de réalisation (cycle de vie selon un plan d’assurance
qualité rigoureux) ;
— structure modulaire ;
— structure redondante ;
— bus à fibre optique permettant l’isolation entre voies électri-
ques et entre SCAT 2E et SCAT non classé ;
— fonctionnalité permettant la configuration par CAO des fonc-
tions du SCAT 2E (conditionnement de signaux, traitements, régula-
tions, séquences).
La réalisation du SCAT 2E à partir du produit sélectionné n’a pas
demandé de modification de fond de celui-ci.
■ Conformité à la CEI 880
La CEI 880 impose des pratiques dès le début du cycle de vie du
logiciel. La conformité a posteriori est donc hypothétique. De plus,
un automate haut de gamme avec des fonctions d’application riches
et des fonctions système étendues (réseaux, redondance, configura-
tion par CAO) est d’un degré de complexité tel que l’application la
plus stricte de la CEI 880 n’est pas toujours possible.
L’objectif de l’analyse n’est pas de rejeter le produit pour cause de
non-conformité. Une fois identifiées, les non-conformités doivent
être compensées de manière adéquate (rétroconception, validation
renforcée, analyse du retour d’expérience).
L’analyse a montré que le cycle en V et le programme d’assurance
qualité employés par le fournisseur respectaient les exigences de la
CEI 880. Lorsque des non-conformités mineures ont été détectées,
elles ont été corrigées.
Les exigences restreignant les techniques de programmation afin
de garantir la simplicité et le déterminisme ne sont qu’en partie res-
pectées. Les contre-mesures employées ont été :
— des vérifications et tests complémentaires sur le comporte-
ment des bus et du système d’exploitation des cartes automates ;
— une analyse de comportement grâce au retour d’expérience ;
— une analyse des autotests en exploitation du système (détec-
tion et signalisation d’erreurs, position de repli en cas d’erreur
détectée) ;
— des tests de comportement prédictible et de vérification des
temps de réponse.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
BN 3 425 − 10 © Techniques de l’Ingénieur, traité Génie nucléaire
__________________________________________________________________________
■ Tests constructeur et recette usine
Des études ont permis de recenser les tests effectués par le
constructeur, de lui imposer des tests complémentaires lors de la
réception du produit et de consigner dans un rapport la couverture
ainsi obtenue.
■ Retour d’expérience
L’appréciation portée grâce au retour d’expérience incite à une
certaine prudence. Le bon fonctionnement d’un produit sur des ins-
tallations existantes (centrales thermiques en l’occurrence) n’est un
gage de bon fonctionnement sur une nouvelle installation que si
l’utilisation du produit est en tous points comparable : version du
produit, architecture, fonctionnalité, sollicitation de la part du pro-
cédé. En pratique, ces conditions ne sont jamais complètement rem-
plies. Il est toutefois admis qu’un retour d’expérience positif
renforce sensiblement la confiance que l’on peut avoir dans un pro-
duit.
Dans le cas qui nous intéresse, le retour d’expérience est utilisé
comme élément d’appréciation complémentaire aux analyses déjà
décrites. L’automate a été installé pour contrôler des procédés de
nature différente, mais le fonctionnement du logiciel est relative-
ment comparable du fait de l’aspect modulaire de l’architecture et
du caractère contraint de l’application d’automatisme, qui est un
assemblage de modules de programmation effectué à l’aide d’un
outil de CAO.
Après définition d’un certain nombre de missions-type (condition-
nement de signaux, boucle de régulation, etc.), le retour d’expé-
rience a permis de conclure à l’exécution satisfaisante de ces
missions par le produit et de caractériser la disponibilité offerte pour
ces missions.
■ Analyse fonctionnelle
Une analyse fonctionnelle a été menée pour s’assurer que le
produit permettait de réaliser le SCAT tel qu’il était spécifié tant
d’un point de vue système (redondances, bus, isolation électrique
par fibre optique, architecture modulaire, etc.) que d’un point de
vue fonctionnel (conditionnement de signaux d’entrée/sortie,
commande et verrouillage des actionneurs, automatismes logiques
et analogiques).
3.3.2.3 Conception des données
Les données (définitions d’entrée/sortie, traitements et automa-
tisme), définies et téléchargées dans les automates à l’aide de l’outil
de CAO, sont une caractéristique essentielle de la conception du
SCAT. Cette configuration des automates ne s’apparente pas à un
simple paramétrage, mais à de la programmation avec tous les pro-
blèmes que cela comporte : maîtrise de la complexité, fonction-
nement prédictible, conception descendante, tests, vérification et
validation.
L’état de l’art et le savoir-faire des ingénieurs automaticiens n’ont
pas conduit au respect d’une norme de type CEI 880, mais à la mise
en place d’une démarche structurée à la hauteur de la quantité et de
la diversité des programmes à maîtriser.
■ Définition de traitements-type
La description de tous les organes du procédé (capteurs et action-
neurs) a été caractérisée en une soixantaine de traitements-type.
Pour un actionneur d’une classe donnée par exemple, le traitement-
type associé gère la modélisation de l’actionneur, les entrées/sor-
ties, les conditions de verrouillage associées, le protocole de
commande, etc.
Cette répartition en classes permet de modéliser plusieurs dizai-
nes de milliers de capteurs et actionneurs à l’aide d’instanciation
d’une soixantaine de traitements-type seulement. L’effort de tests et
validation est donc factorisé d’autant et concentré sur ces traite-
ments-type.
__________________________________________________________________________ QUALIFICATION DES SYSTÈMES PROGRAMMÉS DANS LES CENTRALES
■ Outil de CAO et approche descendante
EDF a adopté une chaîne de CAO permettant de gérer deux
niveaux de modélisation des traitements. Les diagrammes fonction-
nels (logiques ou analogiques) décrivent les principes généraux des
traitements. Les schémas logiques de programmation (SLP) pour
les traitements booléens et les schémas numériques de program-
mation (SNP) pour les traitements analogiques sont un raffinement
des diagrammes fonctionnels. À partir des SLP et SNP, l’outil de
CAO génère automatiquement les fichiers de description des traite-
ments qui sont ensuite téléchargés dans les automates.
■ Tests unitaires et tests par lots
Les programmes d’automatisme ont subi des tests unitaires soit
sur matériel cible, soit par simulation. Ensuite il a fallu les tester
dans un environnement aussi proche que possible de l’environne-
ment cible. Or le SCAT complet (SCAT 2E + SCAT non classé) repré-
sente un ensemble de plus de 130 armoires d’automates dont la
fabrication et la mise en service sont étalés dans le temps. Le SCAT
a donc été découpé en « lots », un lot constituant un sous-ensemble
de l’architecture cohérent et dans la mesure du possible indépen-
dant des autres lots.
Chaque lot a subi une série complète de tests visant à prouver le
bon fonctionnement des programmes, le bon fonctionnement du
matériel, la cohérence entre l’architecture matérielle et les pro-
grammes (définition des entrées/sorties, charge des bus et des auto-
mates).
3.3.2.4 Qualification du SCAT 2E
Les activités principales de qualification ont consisté en :
— analyses et audits du développement du système par l’autorité
de sûreté ;
— fourniture d’une documentation spécifique de présentation du
système par le fournisseur : cette documentation a fourni la
connaissance de base aux personnes impliquées dans la qualifica-
tion. La découpe de la fonctionnalité du SCAT 2E en « missions » a
joué un rôle prépondérant car elle a permis par la suite une analyse
approfondie de chaque mission ;
— qualification matérielle : de même nature que pour les équipe-
ments 1E, la qualification du matériel a requis, outre les preuves de
tests effectués par le constructeur, des tests spécifiques de résis-
tance aux conditions d’ambiance, aux perturbations électromagné-
tiques et aux conditions sismiques ;
— études de sûreté : au fur et à mesure de ses travaux d’exper-
tise, l’autorité de sûreté a exigé l’analyse de points techniques parti-
culiers. Les études de sûreté ont consisté en la fourniture de
rapports d’analyse correspondants par le fournisseur, des organis-
mes mandatés par le client ou le client lui-même.
D’un point de vue formel, un dossier de sûreté élaboré par le
client a consigné l’ensemble des informations et études relatives à
la qualification du système. Ce dossier est structuré en trois volets
complémentaires :
— cadre méthodologique : assurance, contrôle de la qualité,
moyens associés ;
— démarche déterministe : présentation de système, choix de
conception, fonctionnalité, contrôles associés ;
— démarche probabiliste : études complémentaires concernant
les comportements du système qui ne peuvent être caractérisés que
de manière probabiliste (disponibilité de certaines « missions » du
système, étude de défaillances particulières).
Les procédés de conception et de qualification ont conduit à la
mise en service d’un système remplissant de manière satisfaisante
la mission qui lui est assignée. La catégorie 2E est, par définition,
moins contraignante que le catégorie 1E. Une relaxation de la
vérification analytique a été tolérée (pas de méthode ou langages
formels) au profit de techniques de validation « globales » complé-
mentaires (analyse par « missions », retour d’expérience, études de
sûreté), plus adéquates pour ce système.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Génie nucléaire
3.4 Système de conduite du palier N4
Le système informatique de conduite constitue le « niveau 2 »
de l’architecture du contrôle-commande sur le palier N4 [BN 3 411].
Il assure l’interface homme-machine en salle de commande
(figure 1).
Dans toutes les situations et particulièrement en situation acci-
dentelle, le système informatique de conduite (KIC) permet la
conduite à l’aide de postes opérateur informatisés, proposant une
aide à l’opérateur du plus haut niveau (cf. articles [BN 3 411] et
[BN 3 421]. C’est à la suite de l’accident de Three Miles Island en
1979 qu’EDF a lancé des programmes de développement de systè-
mes informatiques d’aide à l’opérateur.
Le KIC est réalisé sur une architecture distribuée de quinze unités
centrales (pour la partie temps réel), et comporte plus d’un million et
demi de lignes de code développées spécifiquement. Il est très hau-
tement configurable. À l’aide d’un outil de CAO, il est possible de
charger de nouvelles données dans le système sans interrompre la
mission de celui-ci. Ces données peuvent être la définition d’orga-
nes, d’alarmes, d’images synoptiques représentant des vues dyna-
miques du procédé, etc. C’est un système « actif », devant fournir
une mission continue et sûre.
La réalisation du KIC est un projet de développement logiciel volu-
mineux et complexe donc difficile à qualifier. Cependant, refuser
l’utilisation d’un tel système eût été refuser l’aide extrêmement pré-
cieuse qu’il peut fournir à un opérateur stressé en situation acciden-
telle. La stratégie suivante a donc été retenue :
— le KIC est le moyen principal de conduite de la tranche en toute
situation, y compris en situation accidentelle. Il doit à ce titre être
qualifié à un niveau appelé IPS-NC (important pour la sûreté - non
classé) et devra respecter les règles définies pour ce type de
classement ;
— un panneau auxiliaire de type conventionnel permet de
ramener la tranche à l’arrêt sûr en cas d’indisponibilité du sys-
tème KIC. Le panneau auxiliaire est divisé en deux niveaux de
classement (1E et 2E). Ce système, entièrement diversifié par
rapport au KIC et aux automates (les commandes individuelles
sont connectées au plus bas niveau de l’architecture), est un élé-
ment indispensable de la démonstration de sûreté du contrôle-
commande.
3.4.1 Exigences applicables à la classe IPS-NC
Les règles initiales ne concernaient que le respect de contraintes
de qualité décrivant le cycle de développement du système. Elles
ont en fait été renforcées en vue du processus de qualification, et
pour garantir une très haute disponibilité du KIC (influant directe-
ment sur la disponibilité de la tranche) :
— assurance qualité selon le RCC-E (assurance qualité garantis-
sant le respect du cycle en V, mise en place et contrôlée par des per-
sonnes indépendantes de l’équipe de développement) ;
— respect du critère de défaillance unique pour le matériel assu-
rant les fonctions de conduite (redondance) ;
— séparation géographique et électrique entre unités redon-
dantes ;
— qualification aux conditions d’environnement, armoires résis-
tantes aux conditions sismiques afin de garantir un délai de répara-
tion court après séisme.
Il était en outre important de maîtriser le projet et de s’engager sur
des solutions pérennes. Client et fournisseur se sont donc mis
d’accord sur :
— l’utilisation de composants logiciel « standard » (systèmes
d’exploitation, outils logiciel graphiques, logiciel de communica-
tion) ;
— l’utilisation de langages et de règles de programmation per-
mettant une bonne portabilité.
BN 3 425 − 11
QUALIFICATION DES SYSTÈMES PROGRAMMÉS DANS LES CENTRALES __________________________________________________________________________
3.4.2 Pratiques de réalisation du KIC
Les techniques de réalisation sont essentiellement des techniques
de développement logiciel permettant de maîtriser un développe-
ment de grande ampleur. L’état de l’art n’offre d’ailleurs pas de
meilleure solution pour produire un logiciel de plus d’un million et
demi de lignes de code avec un niveau de sûreté acceptable, si ce
n’est :
— d’appliquer des méthodes de génie logiciel avec toute la
rigueur qui s’impose ;
— d’utiliser des techniques plus « dures » pour certaines portions
du logiciel jouant un rôle central dans la sûreté du système ;
— d’effectuer des analyses de sûreté transverses sur des points
jugés « sensibles ».
La réalisation a reposé sur un plan qualité et un ensemble de
procédures décrivant le cycle en V utilisé, les activités transverses
associées (assurance qualité, vérification), les méthodes et outils
employés.
Les techniques et règles employées ne sont pas en tout point
comparables à celles préconisées par la CEI 880, mais un parallé-
lisme se dégage. Certaines pratiques sont de même nature avec
quelques dérogations : cycle en V, vérification et validation par des
équipes indépendantes (partiellement). D’autres pratiques visent à
remplir les mêmes objectifs (exemple : maîtrise de la complexité)
avec des moyens différents (exemple : approche orientée objet).
3.4.2.1 Base technologique existante
Le cahier des charges présentait en détails une interface homme-
machine (IHM) établie suite à des études d’ergonomie allant jusqu’à
un prototypage de la salle de commande. Il n’était pas question de
s’écarter de la définition de cette IHM, par contre il était tout à fait
concevable de réaliser le KIC à l’aide de certains composants exis-
tants s’ils permettaient de répondre au cahier des charges.
Une étude de faisabilité a permis de faire le choix d’un certain
nombre de composants matériel et logiciel existants pour réaliser le
système KIC : serveurs et stations de travail, éléments de réseaux,
systèmes d’exploitation, logiciel système, logiciel réseaux, logiciels
graphiques. Cette étude de faisabilité a aussi permis de sélectionner
ces composants par analyse du sérieux des fournisseurs et de la
conformité au besoin.
Pendant la réalisation proprement dite, les fournisseurs ont fait
l’objet de contrôles qualité (collecte d’informations sur leur certifica-
tion ISO 9000, 9001 ou 9002, audits qualité). Les produits utilisés ont
été observés tout au long du projet (détection et correction d’ano-
malies) au même titre que les produits développés spécifiquement.
3.4.2.2 Méthodologie de conception
Une phase de spécifications fonctionnelles a permis au fournis-
seur de reformuler entièrement les exigences du cahier des charges.
Ces spécifications fonctionnelles ont été entièrement analysées puis
approuvées par le client. Elles ont ensuite servi de base unique à la
réalisation des étapes suivantes de conception.
Comme pour la programmation des automates, un nombre limité
de traitements-type a permis de modéliser les organes du procédé
et leurs différentes représentations graphiques. Cette notion de trai-
tement-type a été étendue à l’élaboration de variables de synthèse
effectuée par le KIC : élaboration d’alarmes, intégrale ou dérivée de
valeurs, etc. Elle a permis de concentrer les efforts de spécification,
conception, codage, test générique et tests d’intégration avec les
automates.
3.4.2.3 Langage Ada
Le langage Ada a été retenu pour réaliser le logiciel spécifique.
Spécialement étudié pour le développement d’applications
complexes et critiques, il remplit au mieux les critères de choix de
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
BN 3 425 − 12 © Techniques de l’Ingénieur, traité Génie nucléaire
langage préconisés par la CEI 880. Il a permis un portage aisé du
logiciel sur des matériels nouveaux au cours du projet.
La nature même du langage permet d’ordonnancer simplement
des tâches, de contrôler systématiquement l’affectation des varia-
bles, de traiter par mécanisme d’« exception » les erreurs détectées
lors de l’exécution.
3.4.2.4 Composants critiques
Deux composants logiciel revêtent une importance particulière :
— l’un constitue la couche système (ordonnancement, communi-
cation entre machines et fonctionnement en redondance active des
calculateurs centraux) ;
— l’autre est une base de données et de traitements temps réel
et orientée objet. Cette base de données peut être configurée (peu-
plée) à l’aide d’un outil de CAO et fonctionne de manière cohérente
en mode distribué sur plusieurs machines.
Ces deux composants résolvent les difficultés techniques essen-
tielles (gestion des tâches et allocation mémoire). Ils sont garants
de la disponibilité et du fonctionnement en redondance « active »
des calculateurs centraux, eux-mêmes garants de la disponibilité
du KIC. Les autres composants logiciel s’appuient sur les services
fournis par ces deux composants.
À ce titre, ils ont bénéficié de mesures de réalisation particulières.
Ils ont été vérifiés par une équipe indépendante de l’équipe de déve-
loppement. Ils ont ensuite été gérés comme un produit logiciel,
maintenu par une équipe aux compétences spécifiques. Leur utilisa-
tion sur d’autres affaires a permis de renforcer la validation et la
gestion des anomalies pour tendre vers le « zéro défaut ».
3.4.2.5 Test du logiciel
Le logiciel a fait l’objet de tests unitaires aussi formels que possi-
ble. Pour les modules logiciel constitués de procédures simples, des
outils de génération automatique de test ont été utilisés (exécution
des procédures avec des jeux de paramètres d’entrée, trace des
résultats dans un fichier de sortie). Pour les modules logiciel dont le
contexte d’activation était plus délicat, des environnements de test
spécifiques ont été écrits. Plus de 500 000 lignes de logiciel de test
(ne faisant pas partie de l’application) ont été écrites.
3.4.2.6 Intégration et validation indépendantes
Il est préconisé dans la CEI 880 que les activités d’intégration et de
validation soient effectuées par des équipes indépendantes de cel-
les qui ont effectué le développement. Cette mesure a été respectée,
en outre parce qu’elle permettait d’avoir une équipe ayant la compé-
tence particulière et les moyens associés à cette mission (plates-for-
mes de test).
Les nombreuses étapes d’intégration ont permis de contrôler pro-
gressivement le bon fonctionnement coordonné des différentes
machines (aspects système, interface, fonctionnement applicatif).
Des outils de test spécifiques ont été développés, capables de simu-
ler la présence des machines non encore présentes pour l’étape cou-
rante d’intégration, ou de simuler les échanges avec les automates.
La validation du système intégré a fait l’objet d’une recette for-
melle en présence du client. Cette validation a été rejouée entière-
ment ou au cas par cas à chaque livraison d’une nouvelle version du
système.
3.4.2.7 Gestion des anomalies et critères de convergence
Deux mesures complémentaires permettent d’aboutir à des métri-
ques de qualité du code.
■ Signalement, confinement et traitement des erreurs
Les outils tels que débogueur symbolique ont été utilisés par les
programmeurs dans des phases de test bien particulières. Pour
prendre le relais et permettre l’investigation d’erreurs en toutes cir-
constances (intégration, validation, mise en service site, fonctionne-
__________________________________________________________________________ QUALIFICATION DES SYSTÈMES PROGRAMMÉS DANS LES CENTRALES

ment opérationnel), une opération d’« instrumentation de code » a

été mise en place. Le logiciel comporte des procédures rapportant 6

Nombre de fiches
de suivi ouvertes
les contextes anormaux rencontrés lors de l’exécution. Ces procé- Manipulation
dures peuvent être activées ou désactivées par paramétrage du sys- 5
Logiciel
tème. Elles peuvent ordonner l’arrêt de la machine ou de l’ensemble 4 Matériel
du système si l’erreur détectée ne peut pas être palliée ou confinée,
3
ou si le comportement ultérieur du système n’est plus sûr.
2
L’instrumentation de code a pris une importance croissante au fil
du projet. Au départ, cette instrumentation n’avait été systématique 1
que sur les modules logiciel de type système (gestion des tâches, 0
allocation de mémoire, communication). Au vu de l’apport de la 1 5 10 15 20 25 30 35 40 45 50
technique, une campagne de rétroconception a été effectuée, afin de Semaine
généraliser cette instrumentation.
Figure 3 – Fiches de suivi : répartition entre les différentes causes
■ Fiches de gestion des anomalies
Un recensement systématique des anomalies du système est
effectué dès qu’elles se produisent dans un environnement d’exécu-
tion fiable (plate-forme d’intégration ou de validation, mise en ser-
vice ou exploitation site).
20

Tout comportement du KIC jugé anormal sur le site fait l’objet
d’une « fiche de suivi ». Une première analyse a pour objet d’établir
s’il s’agit :
— d’une erreur d’interprétation ou de manipulation ;
— d’une défaillance du matériel ;
— d’une défaillance due au logiciel. Dans ce dernier cas, le
contexte est apporté au fournisseur en vue d’une reproduction de
l’anomalie sur plate-forme de développement, puis de correction.
Une erreur du logiciel (rapportée par une fiche de suivi ou
constatée lors de la validation) est consignée dans une « fiche
d’anomalie », et fait l’objet d’une investigation pour décrire et repro-
duire le contexte d’exécution de l’erreur, puis proposer une modifi-
cation apportant la correction.
Une fois la fiche d’anomalie renseignée, « une fiche de prise en
compte de modification » est ouverte. Cette fiche décrit la modifica-
tion retenue et les tests permettant de valider la correction. Elle pré-
sente une étude d’impact éventuel de la correction, les tests de non-
régression à effectuer pour contrôler cet impact et identifie la ver-
sion du logiciel qui corrigera cette anomalie. La fiche est close après
validation de la correction.
Les fiches de suivi font l’objet d’une analyse statistique (différen-
tes causes et variation au fil du temps : cf. figure 3).
■ Critères de convergence
Au-delà de la gestion analytique rigoureuse de chaque anomalie
qui vient d’être décrite, une analyse statistique permet de conclure à
la « convergence », c’est-à-dire à la stabilité et à la maîtrise du logi-
ciel.
La fiabilité de l’analyse statistique repose sur la précision de l’ins-
trumentation du code et de la gestion des anomalies.
Sur la base de données fiables, il existe des méthodes permettant
d’évaluer les critères de convergence associés à l’apparition des
anomalies (figure 4).
Ces statistiques n’apportent pas une preuve de la qualité du logi-
ciel, mais une preuve de la maîtrise de celui-ci (correction d’anoma-
lies sans en introduire ou en révéler de nouvelles). Elles ont aussi
l’avantage de fournir des données quantitatives sur la qualité du
logiciel et de conclure à la fin de la validation sur ce critère objectif.
3.4.2.8 Données de configuration
Le système KIC est constitué d’une architecture matérielle, de
logiciel « de base » (base de données et de traitements à peupler,
fonctions d’IHM) et de données de configurations (paramètres saisis
à l’aide d’un outil de CAO permettant de peupler la base de données
et de définir les images du système).
Ces données de configuration sont volumineuses et complexes
(cf. articles [BN 3 411] et [BN 3 421]). Leur maîtrise est rendue possi-
ble par :
Nombre d'anomalies
Modèle hyperexponentiel
15
10
5
0
0 20 40 60 80 100
Semaine
Figure 4 – Nombre d’anomalies par semaine et convergence
selon modèle hyperexponentiel
— le mode de peuplement de la base de données : les 60 000
« objets » (organes du procédé ou variables calculées) sont décrits
par renseignement de paramètres de configuration d’un « traite-
ment-type ». La saisie est donc contrainte. Les contrôles de cohé-
rence effectués par l’outil de CAO et par le système lors du
peuplement sont aussi exhaustifs que possible ;
— la vérification et la validation de toutes les données : des
plates-formes de test dédiées permettent de vérifier toutes les don-
nées. Des programmes particuliers de validation sont définis au cas
par cas. Les procédures de conduite (cf. article [BN 3 421]) sont un
exemple de données nécessitant un programme de validation parti-
culier. Une phase de validation des données décrivant les procédu-
res est réalisée par exécution de ces procédures sur un simulateur.
3.4.3 Études de sûreté et qualification du KIC
L’autorité de sûreté a audité la réalisation du KIC (choix de concep-
tion, système qualité et contrôle qualité) et a exigé la fourniture d’un
dossier de sûreté de structure analogue à celle décrite pour le
SCAT 2E (cadre méthodologique, démarche déterministe, démar-
che probabiliste). La démarche probabiliste visait à caractériser tout
particulièrement la fiabilité et la disponibilité du système.
La disponibilité du KIC a été contrôlée par l’autorité de sûreté car
bien qu’il existe un moyen de secours pour ramener la tranche à
l’état sûr, le moyen normal de conduite en toutes circonstances est
le système KIC. La disponibilité a été caractérisée soit par calcul à
partir des chiffres de disponibilité du matériel (en ne tenant pas
compte des pannes dues au logiciel), soit à partir des données accu-
mulées pendant la phase de mise en service.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Génie nucléaire BN 3 425 − 13
QUALIFICATION DES SYSTÈMES PROGRAMMÉS DANS LES CENTRALES
Les études de fiabilité se sont concentrées sur un point précis qui
est la non-pollution de systèmes de classement plus sévère (1E et
2E) par le KIC (lui-même classé IPS-NC). Toutes les mesures prises
lors du cycle de développement renforcent la confiance dans le sys-
tème, mais n’apportent pas de preuve de son bon fonctionnement,
preuve vers laquelle on tend plus directement pour les systèmes
classés 1E. Les erreurs franches du système ont un effet sur sa dis-
ponibilité, mais une solution de secours existe (conduite au pan-
neau auxiliaire). La seule pollution possible d’un système classé par
le KIC consisterait en l’émission d’ordres « spontanés » ou
« erronés », regroupés sous le terme d’ordres aberrants. Les études
sur les ordres aberrants ont permis de s’assurer qu’un fonctionne-
ment erratique du système ne peut pas conduire à l’émission effec-
tive d’une commande vers le procédé.
En conclusion, comme pour les autres types de systèmes, les pro-
cédés de réalisation et de qualification du KIC ont conduit à la mise
en service d’un système remplissant la fonctionnalité demandée
tout en respectant les exigences de conception et les objectifs de fia-
bilité et de disponibilité.
3.5 Site de Kashiwasaki, Japon
Jusqu’ici, l’exposé présente largement le palier français N4, et
plusieurs réalisations de systèmes numériques de protection réac-
teur dans le monde. Il est intéressant de citer en complément le cas
des deux tranches les plus récentes du site de Kashiwasaki au
Japon. Ces deux tranches dont la mise en service a débuté en 1996
sont équipées d’un contrôle-commande informatisé.
La norme JEAG 4609 rédigée pour la circonstance définit les
modes de redondance du système de protection (« deux sur
quatre ») et des automates de sûreté (« deux sur trois » ou « un sur
deux ») ainsi que les règles de conception pour ces systèmes (assu-
rance qualité, système d’exploitation non spécifique, fonctionne-
ment cyclique sans interruptions).
Le système de protection respecte la norme JEAG 4609. Il est
constitué d’automates spécifiques répartis sur une architecture en
redondance 4. Le système d’exploitation des automates n’est pas
spécifique. Le logiciel d’application est cyclique, développé selon les
règles de l’assurance qualité. La fonction « ATWS : Anticipated Tran-
sient Without Scram » est réalisée en technologie conventionnelle
et constitue donc une diversification partielle.
Les automates de sûreté sont des automates du commerce béné-
ficiant de dix ans de retour d’expérience. L’architecture offre une
redondance double ou triple selon les cas. Leur fonctionnement est
cyclique.
Les moyens de visualisation et de commande associés sont
constitués de systèmes à écran plasma (deux systèmes indépen-
dants, connectés respectivement au système de protection et aux
automates de sûreté). Ces systèmes à écran plasma sont des pro-
duits spécifiques développés selon la norme JEAG 4609 et qualifiés
au séisme. Un nombre limité de commandes est aussi possible à
l’aide d’éléments conventionnels.
L’interface homme-machine en salle de commande est constituée
de plusieurs systèmes indépendants (synoptique mural et postes
de conduite composés de plusieurs éléments de technologie diffé-
rente, panneaux de commande et d’alarmes spécifiques à la situa-
tion de la tranche). Cela a permis d’adapter l’effort de qualification à
la nature de chaque système (système effectuant ou non des
commandes ; participant ou non aux actions de protection et de
sauvegarde, etc.).
Du fait de la juxtaposition de ces moyens, la conduite informati-
sée peut paraître moins intégrée que sur le palier N4 français. En
fait, l’ergonomie a été conçue en conséquence, et un opérateur dis-
pose à son poste de travail de toutes les commandes, informations
et alarmes nécessaires à la conduite dans de très bonnes condi-
tions.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
BN 3 425 − 14 © Techniques de l’Ingénieur, traité Génie nucléaire
__________________________________________________________________________
4. Qualification des systèmes
programmés. Tendances
Il n’est pas prématuré de parler de retour d’expérience même
pour un palier jeune comme N4, tant la période de mise en service
est probatoire pour le contrôle-commande. Bien des tests de mise
en service sont en effet plus contraignants pour les systèmes pro-
grammés que l’exploitation en conditions réelles.
Tous les systèmes ont révélé des défauts de jeunesse, bien
compréhensibles pour une telle première (nouveau procédé
1 450 MW, premier contrôle-commande informatisé de centrale
nucléaire au monde). La méthodologie de prise en compte des ano-
malies, révélées par la validation et la mise en service, a permis de
résorber ces défauts et de faire de cette première installation un suc-
cès à tous égards. La faisabilité d’un contrôle-commande entière-
ment informatisé est maintenant établie, et son intérêt pour la
conduite prouvé.
De même, plusieurs réalisations de systèmes numériques de pro-
tection réacteur prouvent que, même pour le niveau de qualification
le plus sévère, des solutions viables existent. Le réalisme économi-
que de certaines réalisations peut toutefois encore être mis en
doute, à cause du coût direct ou induit de la validation.
Dans le même temps et à l’inverse, les solutions conventionnelles
(boutons de commande, afficheurs, relayage à seuil) sont en perte
de vitesse. Devenues obsolètes dans toute l’industrie, ces technolo-
gies sont rattrapées par les automates et systèmes programmables.
Le parc installé est vieillissant et il est difficile de maintenir les
stocks, les unités de fabrication et les compétences sur des équipe-
ments anciens.
4.1 Constructions nouvelles
Les systèmes programmés sont donc reconnus aujourd’hui
comme un choix compétitif pour tous les éléments de l’architecture
d’un contrôle-commande de centrales nucléaires. Les motivations
que peut avoir un client en faveur des systèmes conventionnels sont
de minimiser les risques et les coûts du projet en reconduisant une
solution existante et déjà qualifiée.
Pour la construction de nouvelles unités, les études et marchés
récents ont montré que les deux choix restent d’actualité :
— un contrôle-commande entièrement informatisé : c’est le choix
du client pour les deux nouvelles tranches de Lungmen (Taïwan), ou
encore le choix d’avant-projet détaillé pour l’EPR, futur palier
nucléaire européen ;
— un contrôle-commande conventionnel : c’est le choix du client
pour les deux nouvelles tranches chinoises de Ling Ao. Les systè-
mes de protection, relayage et automatismes sont réalisés en tech-
nologie conventionnelle. La salle de commande comporte une
interface homme-machine à base d’écrans, présentant des fonctions
de type « supervision » et « panneau de sûreté », élaborées par un
système informatique. L’acquisition de valeurs pour ce système est
basée sur un matériel de type automate programmable, même si
ceux-ci ne réalisent pas d’automatismes.
Lorsque des systèmes programmés sont employés, les pratiques
suivantes sont en général retenues :
— le système de protection est un produit spécifique, utilisant
éventuellement un système d’exploitation non spécifique. Qualifica-
tion du matériel aux conditions sismiques et aux conditions
d’ambiance sont de rigueur. Assurance qualité et contraintes de réa-
lisation du logiciel selon la CEI 880 ou équivalent sont préconisées ;
— les automates de sûreté sont réalisés sur la base d’un très bon
produit du commerce. Le matériel doit être qualifié aux conditions
sismiques et d’ambiance. Fiabilité et disponibilité sont évaluées
concurremment par analyse de conformité a posteriori à une norme
de type CEI 880 et par analyse du retour d’expérience ;
__________________________________________________________________________ QUALIFICATION DES SYSTÈMES PROGRAMMÉS DANS LES CENTRALES
— il n’y a pas de tendance établie pour les écrans d’interface
homme-machine classés aux niveaux les plus sévères. L’exemple
du Japon peut être retenu (système réservé à la commande à base
d’écrans plats, qualification matérielle, logicielle et système selon
les mêmes règles et normes que les automates du même niveau de
classement) ;
— systèmes informatiques de conduite ou de supervision réali-
sés sur la base d’un très bon produit du commerce répondant aux
critères d’assurance qualité, fiabilité et disponibilité. Diversification
partielle à l’aide d’un système conventionnel permettant de rame-
ner la tranche à l’état sûr.
4.2 Rénovations
La durée de vie des tranches nucléaires est de l’ordre de 40 ans, il
est difficile d’en dire autant des équipements de contrôle-
commande. La durée de vie de ces derniers peut être contrôlée par
une politique forte de maintien de compétences et de stocks de
rechange. Malgré cela, l’exploitant est fatalement amené à se poser
la question de la rénovation totale ou partielle de certains éléments
du contrôle-commande. Les questions induites sont : quelle techno-
logie choisir, quel classement, quelle qualification ?
Le cas du remplacement de systèmes conventionnels par des sys-
tèmes numériques se pose de plus en plus. Nous présentons ici cer-
tains cas de figure introduisant des systèmes programmés recensés
actuellement.
4.2.1 Remplacement d’un système de protection
conventionnel par un système numérique
Le système numérique offre une couverture de cas plus grande
avec une diminution des déclenchements intempestifs donc une
meilleure disponibilité d’exploitation. En outre, ce type de remplace-
ment n’oblige pas à de grands bouleversements dans le contrôle-
commande car ce système est très isolé des autres et présente une
interface homme-machine très limitée (quelques commandes et
indicateurs conventionnels). Plusieurs clients optent pour cette
solution même si le processus de qualification lors d’une première
installation est coûteux.
Exemple : France (tranches 900 MW).
4.2.2 Rénovation des systèmes de supervision
Toutes les tranches ou presque ont déjà des systèmes informati-
ques de type « supervision » ou « aide à la conduite » (présentation
d’images, courbes, éventuellement alarmes, mais sans aucune pos-
sibilité de commande). La rénovation permet de traiter l’obsoles-
cence du matériel informatique de la génération précédente mais
aussi d’améliorer la fiabilité, la disponibilité, les performances, de
proposer une fonctionnalité plus appropriée (fonctions d’aide à
l’opérateur en situation accidentelle), de rendre à nouveau évolutif
un système figé.
Exemple : projets de remplacement des systèmes de supervision
des centrales de type VVER ou RBMK (CEI, pays de l’Europe de l’Est).
4.2.3 Rénovation des armoires d’acquisition
de signaux
Souvent jumelée avec le remplacement du système de supervi-
sion associé, cette rénovation fait l’objet de remplacement par des
systèmes de type automate, même si ceux-ci n’ont qu’une fonction
d’acquisition pure.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Génie nucléaire
Exemple : rénovation des systèmes d’acquisition et supervision de
la centrale de Rovno, Ukraine.
4.2.4 Remplacement d’automatismes
conventionnels et de l’IHM associée
par des systèmes programmés
L’installation d’automates modernes suggère en toute logique de
proposer le système informatique de conduite associé à base
d’écrans (rénovation dite « verticale »). Ce dernier point est le plus
délicat car il oblige à modifier sensiblement la salle de commande
d’une tranche en exploitation. Les nouveaux moyens doivent s’insé-
rer dans la logique d’ensemble de l’ergonomie de la salle de
commande, et l’arrêt de tranche pour installation, validation et mise
en service doit être minimisé.
L’exploitant des deux tranches PWR de la centrale de Ringhals
(Suède) a programmé ce remplacement d’un contrôle-commande
conventionnel par un contrôle-commande informatisé. Planifiée sur
10 ans, l’opération commence par l’installation d’un contrôle-
commande informatisé pour le circuit secondaire. La salle de
commande est alors « hybride » : conduite informatisée pour le
secondaire et conventionnelle pour le primaire. Puis viendra la
numérisation du système de protection et de contrôle-commande
du circuit primaire.
4.2.5 Remplacement circonstancié
d’automatismes
Une solution de remplacement d’automatismes conventionnels à
moindre coût est à l’étude dans certains pays. Elle consiste à
reproduire strictement à l’identique une armoire à relayage conven-
tionnel par une technologie de type ASICs (Application Specific Inte-
grated Circuits) ou autre.
L’intérêt est de ne pas modifier la fonctionnalité d’un automa-
tisme qualifié et dont le retour d’expérience est satisfaisant. Aucune
nouvelle étude d’automatisme n’est nécessaire et le câblage exis-
tant peut être maintenu, ce qui est certainement une économie
d’investissement forte.
L’inconvénient est que ce type de remplacement ne permet pas de
bénéficier de la souplesse de programmation, de la richesse fonc-
tionnelle et du caractère évolutif des automates programmables
modernes.
L’effort de qualification se limite à la qualification de la nouvelle
technologie et du processus de transfert de l’automatisme d’une
technologie à l’autre.
5. Conclusion
Présentant des avantages évidents (modernité, fonctionnalité),
les systèmes programmés sont maintenant couramment utilisés
dans les centrales nucléaires.
Les techniques pour obtenir le niveau de qualité adéquat ayant
donné satisfaction, elles seront reconduites avec quelques évolu-
tions dans les années à venir.
Les systèmes programmés ont en tout cas remporté une bataille
significative qui n’était pas gagnée au départ, celle de leur possible
qualification. Les réticences initiales à qualifier des systèmes conte-
nant du logiciel, par nature complexe, ont été levées. Comme dans
d’autres secteurs (avionique, ferroviaire, médical), les systèmes pro-
grammés ont fait montre de leur bonne contribution à la sûreté.
BN 3 425 − 15